Cómo migrar Domain Controllers a un Hyper‑V Cluster y gestionar FSMO roles

Problema

En entornos con varios controladores de dominio (DC) virtualizados, es frecuente que algunos residan en almacenamiento local mientras otros están en un cluster de alta disponibilidad. Cuando se migra una infraestructura de VMware a Hyper‑V, aparecen preguntas recurrentes:

• ¿Es seguro mover los DC que están en discos locales a los discos del cluster?
• ¿Debe el nuevo host Hyper‑V formar parte del dominio antes de alojar un DC?
• ¿Se pueden migrar los DC en vivo sin interrumpir la replicación?
• ¿Dónde es más apropiado colocar los roles FSMO al añadir un nuevo DC?

El problema central es garantizar que la disponibilidad del directorio activo no se vea comprometida mientras se consolida la infraestructura en un cluster Hyper‑V.

Causa

Los fallos más habituales en este tipo de migraciones provienen de tres áreas:

1. Almacenamiento no clusterizado
   Los discos locales no participan en el mecanismo de failover. Si el host falla, el DC desaparece y la replicación se interrumpe. Además, los procesos de actualización del cluster pueden intentar apagar la VM sin coordinación, generando apagados bruscos.

2. Host Hyper‑V aislado del dominio
   Un host que no está unido al dominio no puede recibir políticas de seguridad ni participar en la replicación automática de los DC. Cuando se crea un nuevo DC en ese host, la falta de confianza inicial puede producir errores de sincronización.

3. Roles FSMO concentrados en un único DC
   Si todos los roles críticos (Schema, Domain Naming, RID, PDC Emulator, Infrastructure) están en un DC que se va a mover, cualquier error durante la migración afecta a toda la zona. La ausencia de un DC secundario con roles FSMO aumenta el riesgo.

Solución

1. Preparar el cluster y el almacenamiento

• Verificar que el cluster Hyper‑V esté saludable (Get-Cluster).
• Confirmar que el LUN iSCSI (por ejemplo, Dell ME5024) está configurado como Cluster Shared Volume (CSV) y que tiene suficiente espacio para los archivos de la VM y los snapshots.
• Habilitar la guardia de VM (VM protection) para que el cluster pueda reiniciar automáticamente la VM en caso de caída del nodo.

2. Decidir la unión del nuevo host al dominio

Un host que va a alojar un DC debe estar unido al dominio antes de crear la VM. Esto permite:

• Aplicar políticas de auditoría y seguridad.
• Utilizar la cuenta de Computer Object del host para registrar la VM en el AD.
• Evitar problemas de “orphaned” VM cuando el DC se registra en un dominio diferente.

Procedimiento rápido:

Add-Computer -DomainName contoso.local -Credential (Get-Credential) -Restart

3. Migrar los DC existentes al cluster

a) Preparar la VM

• Apagar la VM de forma controlada (Stop-VM -Name DC01 -Force), solo si la replicación está al día y los controladores de tiempo están sincronizados.
• Cambiar el tipo de disco a SCSI si aún está en IDE, ya que solo los discos SCSI pueden ser migrados entre nodos sin interrupción.

b) Ejecutar live migration

Hyper‑V permite mover una VM en vivo siempre que:

• La VM tenga Integration Services actualizados.
• El storage sea CSV.
• No haya dispositivos que dependan de la placa base física (por ejemplo, NIC con MAC estático que no sea “Dynamic”).

Comando:

Move-VM -Name DC01 -DestinationNode HVNode02 -IncludeStorage -Confirm:$false

Repetir para cada DC que se quiera trasladar. La replicación de AD sigue operando porque el controlador sigue activo durante la migración.

c) Verificar la integridad post‑migración

• Ejecutar dcdiag /v en cada DC.
• Confirmar que la replicación funciona (repadmin /replsummary).
• Revisar que los registros de eventos no muestren errores de SYSVOL o de Netlogon.

4. Redistribuir los roles FSMO

Una práctica recomendada es dispersar los roles FSMO entre al menos dos DC. Con tres DC (dos en el cluster y uno externo) la distribución típica es:

Para mover un rol:

Move-ADDirectoryServerOperationMasterRole -Identity "DC02" -OperationMasterRole PDCEmulator, RIDMaster

5. Configurar el nuevo host Hyper‑V con su propio DC

• Crear la VM del nuevo DC en el CSV.
• Instalar el rol de AD DS y promoverla como Additional Domain Controller.
• Después de la promoción, validar la replicación y, si se desea, transferir un rol FSMO adicional.

Cuándo aplicar esta solución

• Entorno mixto: al menos un DC está fuera del cluster y se planea consolidar la infraestructura en Hyper‑V.
• Actualizaciones de hardware: el nuevo host tiene hardware diferente y no puede unirse al cluster existente.
• Problemas de apagado inesperado: los DC en discos locales se ven forzados a apagarse durante actualizaciones del cluster.
• Requerimientos de alta disponibilidad: se necesita que todos los DC estén protegidos por failover automático.

No aplicar si:

• El cluster no tiene CSV configurado; la migración en vivo no será posible.
• Los DC están en versiones de Windows Server que no soportan la integración con Hyper‑V (por ejemplo, versiones muy antiguas sin Integration Services).
• La red iSCSI muestra latencias altas (>5 ms) que puedan afectar la consistencia del almacenamiento compartido.

Código

# Unir host Hyper-V al dominio
Add-Computer -DomainName contoso.local -Credential (Get-Credential) -Restart

# Mover VM de DC al nodo del cluster (live migration)
Move-VM -Name DC01 -DestinationNode HVNode02 -IncludeStorage -Confirm:$false

# Transferir roles FSMO a otro DC
Move-ADDirectoryServerOperationMasterRole -Identity "DC02" -OperationMasterRole PDCEmulator,RIDMaster

Verificación

1. Estado del cluster: Get-ClusterGroup | Where-Object {$_.State -ne 'Online'} – debe devolver nada.
2. Replicación AD: repadmin /replsummary – todos los contadores deben estar en 0 errores.
3. Roles FSMO: netdom query fsmo – confirma la ubicación esperada de cada rol.
4. Prueba de failover: simular la caída del nodo que aloja un DC (Stop-ClusterNode -Name HVNode01 -Force) y comprobar que el DC sigue activo en el otro nodo.

Notas adicionales

• Siempre realiza una copia de seguridad de los System State de cada DC antes de moverlos; una restauración rápida evita sorpresas.
• Si utilizas NIC con direcciones MAC estáticas, habilita MAC address spoofing en la configuración de la VM para que el cambio de nodo no cause conflictos.
• Después de la migración, revisa los Group Policy Objects que hacen referencia a rutas de almacenamiento local; pueden quedar obsoletos al pasar a CSV.
• Mantén al menos un DC fuera del cluster (por ejemplo, en una plataforma diferente) como medida de resiliencia frente a fallos totales del cluster Hyper‑V.