Servidor virtual con Windows 2008 no acepta IP estática

Alguna vez me he encontrado con comportamientos extraños en cuanto a conservar la dirección IP v.4 en Windows Server 2008. 

Concretamente, el último caso ha sido en un proceso V2V (de Vmware Server 2.0 a Vsphere 5), al migrar de Host y de hipervisor un servidor virtual Exchange 2007 montado sobre Windows Server 2008.

Al arrancar en el nuevo hipervisor, el servidor virtual no mantiene la IP estática que le ponemos. Al hacer un IPCONFIG, nos da como dirección IP una APIPA. Si, en cambio, lo configuramos por DHCP y hacemos la reserva correspondiente en el servidor DHCP para que le asigne la dirección que nos interese, lo hace sin ningún problema. Pero, cada vez que volvemos a poner la dirección IP como fija, vuelve a tomar una dirección APIPA y, por consiguiente, a perder la conectividad con el resto de servidores de la red.

Primero pensé que podía ser problema de una tarjeta de red oculta (para eliminarla, consultar aquí), pero no, no había tarjetas de red ocultas. Tras investigar un poco descubrí la solución.

La solución pasa por resetear completamente la pila TCP/IP con el siguiente comando, que debe ejecutarse desde una cuenta con derechos administrativos:

netsh int ip reset c:\resetlog.txt

Después debemos reiniciar el equipo. El parámetro c:\resetlog.txt es simplemente para registrar los cambios hechos en un fichero, lo que sucede es que, si no lo ponemos, no funciona.

Este comando equivale a eliminar y reinstalar el protocolo TCP/IP, puesto que reescribe dos claves del registro, a saber:

SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
SYSTEM\CurrentControlSet\Services\DHCP\Parameters\

Haciendo esto el sistema vuelve a funcionar perfectamente y a mantener la IP estática que le pongamos.

Windows 2008: Parte 4: Controladores de Dominio de sólo lectura (RODC) y DHCP

Una prestación nueva e interesante de Windows 2008 son los Controladores de Dominio de Sólo Lectura (Read Only Domain Controller). Este tipo de Controlador de Dominio tiene dos particularidades básicas:

• No pueden ser origen de replicación, por tanto, no podemos usarlos para tareas de administración porque sólo pueden recibir cambios del Active Directory.
• Permiten definir que sólo se repliquen las contraseñas de una parte del Active Directory. Esta funcionalidad es interesante para sedes remotas que necesiten un DC, pero éste no esté debidamente securizado y no haya administrador local. Así, si nos comprometen el servidor y se llevan los archivos de AD para un ataque de fuerza bruta, sólo tendrán acceso a una parte de las contraseñas.

Sin embargo, los RODC sí pueden tener el resto de funciones habituales de un DC: servidor DNS, servidor DHCP, e incluso Servidor de ficheros. El típico escenario donde encajarían los RODC sería el siguiente:


Tenemos la infraestructura principal de servidores en un Data Center/Hub: el primer DC y FSMO, servidor Exchange Hub, Sharepoint, etc.
En cada sede/Branch Office tenemos un RODC contra el que se autentican los clientes locales, un servidor de ficheros, un servidor Mailbox de Exchange, etc.

Implementando una infraestructura similar a la del gráfico me he encontrado el siguiente problema con el servicio DHCP:

Si el primer servidor DHCP del dominio lo instalamos en un RODC, la instalación se desarrolla normalmente, pero falla al final y el servicio DHCP no arranca, obteniéndose el siguiente y críptico mensaje de error:

"Attempt to configure DHCP Server failed. The DHCP Server service could not be started in a timely manner".

La explicación es que al hacer la instalación del primer servidor DHCP de un dominio se modifica el esquema del Active Directory y se crean una serie de grupos. Posteriormente, cuando añadamos más servidores DHCP en el dominio, tendremos que realizar la autorización del servidor DHCP dentro del Active Directory: Todo servidor perteneciente a un dominio que queramos configurar como servidor DHCP debe estar autorizado para serlo, porque, entre otras cosas, un servidor DHCP está autorizado para crear registros en el DNS (las IP's que va otorgando a los clientes que la solicitan).

Al hacer la instalación del primer DHCP Server del dominio en un RODC, éste intenta realizar las modificaciones antes comentadas sobre su copia local de AD y, al no poder escribir sobre ella, la instalación falla al final.

La solución es instalar el rol de DHCP server primero en un servidor miembro o en un Controlador de Dominio de Lectura/Escritura (un servidor del Data Center en el escenario anterior). De esta manera, al hacer esta primera instalación se crean los grupos necesarios y se modifica el esquema y, al añadir el rol de DHCP a un RODC, éste ya se encuentra el Active Directory preparado para albergar su nueva función sin problemas.