De cómo ser IT Pro y no morir en el intento

Con Office 365, mal pensados  

Pues sí, niños y niñas, por fin tengo la oportunidad de trabajar con un cliente que quiere portar su infraestructura a la nube y, por supuesto, a la de nube de Microsoft y su Office 365.

De todos es sabido que la crisis actual afecta las finanzas y las empresas se plantean la reducción de costes así que algunos clientes de mi empresa han decidido migrar.

El caso que me va a aocupar estas semanas (no muchas) es la de migrar Exchange 2007 SP3 y Sharepoint además de configurar Lync Online. Y… estoy entusiasmado por varios motivos: porque ya era hora, porque es algo nuevo y porque es un pequeño reto personal.

Veremos como va que ya nos hemos encontrado con el primer escollo: los certificados necesarios para el AD FS y el AD FS Proxy y no porque sea complicado el montaje sino porque ya hay un AD FS implantado y funcionando con un certificado… autorfirmado que tiene vinculado el CRM de la empresa.

Así que el primer reto consiste en cambiar ese certificado por uno público sin romper el CRM .

Saludos,

Marc

Hola,

Llevo unos días (bueno, son unos meses con días alternos ) con un pequeño pero desesperante problema de registros DNS, un DHCP Server y cambios de comportamiento con “Name Protection” si lo activo o no.

Os detallo el entorno.

• Tres controladores de dominio Windows Server 2008 R2 con servicio de DNS
• Un servidor DHCP también con Windows Server 2008 R2 con usuario definido para registrar las entradas DNS de modo seguro y autorizado en el grupo “DNSProxyUpdate” del AD.
• El lease de los diferentes scopes del DHCP están configurados entre 1 y 4 horas.
• Un parque de clientes Windows XP SP3 y Windows 7, tanto físicos como en entorno VDI, que suman unos 1.500 equipos

El problema

Si se usa el servidor DHCP para realizar el registro, éste tarda de 15 a 30 minutos en generar la entrada “Host (A)” en la zona DNS . Esto provoca un problema cuando el bróker de los equipos VDI intenta resolver el nombre de los clientes (necesario para funcionar) dado que no los encuentra y falla.

Se ha intentado forzar el registro automático mediante una política para que sea el propio cliente VDI quien se registre, pero el registro es creado con la cuenta del cliente (el owner) y no con la del DHCP. Esto provoca que cuando se destruyen las máquinas VDI, los registros no son borrados de la zona DNS, lo que provoca que existan muchos registros obsoletos con los problemas de resolución de nombres que eso conlleva.

En el caso de equipos no-VDI esta problemática no se manifiesta (aunque siguen tardando 30 minutos en registrarse en su zona) y el owner del registro DNS es la cuenta definida en el server DHCP.

Para añadir más lío al tema, se habilita la funcionalidad “Name Protection” en el servidor DHCP con lo que se consigue que registro de los clientes (VID y no-VDI) se realice de forma casi instantánea pero sigue siendo el owner de la entrada del DNS la cuenta de máquina y no la definida en el servidor.

También mencionar que se tiene habilitado aging en la zona, pero no scavenging por temas de carga en los DCs (aunque sería factible activarlo.

La solución

Qué solución hemos aplicado para tener lo que queremos como es que el DHCP registre en el DNS de modo casi instantáneo las entradas correspondientes a cada equipo?

Sencillo: abrir un caso con Microsoft 

Saludos,

Marc

P.D: Seguiremos informando…

Hola a todos,

Hoy, una entrada sencilla pero no por ello menos interesante. Vamos a explicar, paso a paso, cómo migrar un servicio DHCP desde un Windows Server 2003 R2 de 32 bits a un flamamente Windows Server 2008 R2.

Para poder migrar correctamente el servicio DHCP desde un 2003 a un 2008 R2, se deben cumplir unos pasos previos para hacer que los cmdlets de PowerShell sean compatibles entre ambos sistemas.

1. Por tanto, el primer paso es instal·lar Microsoft PowerShell 1.0 o superior en nuestro servidor origen Windows Server 2003 R2
2. En el servidor destino, esto es, nuestro Windows Server 2008 R2 debemos añadir la Feature “Windows Server Migration Tools”
3. Una vez instaladas estas herramientas, generaremos el paquete de instalación para las mismas herramientas pero para ser usadas en 2003 R2.
1. El cmdlet a usar es “PS C:\Windows\System32\ServerMigrationTools\ .\SmigDeploy.exe /package /architecture x86 /os WS03 C:\temp”
4. Instalamos el paquete generado en el servidor origen.
5. Realizamos unb backup del actual DHCP, desde la propia consola
6. Abrimos la consola de PowerShell del servidor origen y ejecutarmos la orden “.\Servermigration.psc1” que abrirá una nueva consola con los módulos para ejecutar la exportación de los datos del servicio DHCP
7. Llegados a este punto, empieza el lío con el cmdlet Export-SmigServerSetting –FeatureID DHCP, el cual tardará un poco y nos pedirá una ruta y un password para almacenar los datos en un fichero.
8. Copiamos el fichero generado al servidor destino, nuestro Windows Server 2008 R2
9. E iniciamos la importación desde una ventana de PowerShell con privilegios elevados. El cmdlet que usaremos es Import-SmigServerSetting -FeatureID DHCP -Verbose –Force
10. Dado que este proceso requiere de mantener la IP del servidor origen, paramos el viejo (o mejor le ponemos otra IP) y la “trasladamos” al nuevo.
11. Iniciamos la consola de DHCP, y desde ella arrancamos el servicio. Autorizamos el servidor y… hemos acabado
12. Basta validar que nuestros equipos renuevan las IPs y listo, a otra cosa.

Todas estas acciones se han realizado siguiendo la guia oficial de Microsoft: DHCP Server Migration Guide (http://technet.microsoft.com/en-us/library/dd379535(v=ws.10).aspx)

Saludos,

Marc

Finalmente, Microsoft en un alarde de imaginación y coherencia, ha decidido llamar a Windows Server 8 como Windows Server 2012.

Nada del otro mundo, no? La parte de la imaginación era presumible viendo la historia reciente de la compañía y lo de la coherencia es para mantener un mismo nombre con los recientes productos de la suite System Center 2012.

De todos modos, lo que más espero yo es la salida de una RC o directamente la RTM dado que estoy encantado con el producto y sólo puede mejorar.

Saludos,

Marc

Hace días que me venía pregutando qué tal sería esto de tener un Windows Server 8 “completo” y transformarlo en un “core”

Pues bien, aprofechando que tengo poca carga de trabajo, me he decidido a probarlo. Para ello, he cogido un member server de mi dominio de pruebas con un Windows Server 8 “normal” y le he ejecutado el cmdlet

Uninstall-WindowsFeature Server-Gui-Mgmt-Infra –Restart

Después de finalizar el proceso, reiniciado del servidor (lleva todo unos 20 minutos) he arrancado el servidor y… bueno, mirad la imagen

Queda algo desangelado, no? Eso sí, sólo consume 512 MB de RAM con todo levantado…

Como no soy de jugar al teletexto, he ido a mi DC del dominio y le he instalado una parte del interfaz gráfico desde el nuevo Server Manager para conseguir un server con un Minimal Server Interface, aka MinShell

Así, después de otros 20 minutos, el resultado ya es más… de mi gusto

Y si os fijais en la consola del DOS, veréis que un “explorer.exe” da error… porque sencillamente no existe en esta versión…

Por cierto, si queréis pasar directamente a una versión MinShell sin pasar por el “core”, el cmdlet es

Uninstall-WindowsFeature Server-Gui-Shell –Restart

Saludos,

Marc