Migración de roles FSMO a Windows Server 2016: solución completa a fallos de inicio de sesión

Tras transferir los roles FSMO a un nuevo Windows Server 2016 muchos administradores descubren que los usuarios ya no pueden iniciar sesión si apuntan su DNS a ese controlador de dominio. El problema suele estar en registros SRV, replicación incompleta o sincronización de hora: todos tienen arreglo con una metodología sistemática.

Índice

Por qué aparecen fallos tras mover FSMO a Windows Server 2016

Aunque la consola confirme que el PDC Emulator reside en el 2016, los clientes siguen buscando un PDC “antiguo” porque:

El servicio Netlogon del nuevo DC no registró (o actualizó) los registros SRV en DNS.
Persisten errores de replicación que impiden copiar los objetos del naming context Configuration y Domain.
SYSVOL no está disponible (por DFS‑R «Eliminated») y las políticas de dominio no se distribuyen.
El rol PDC Emulator aún sincroniza la hora con un DC que ya no es titular del rol.

En la práctica, basta un solo fallo para desencadenar la pérdida de autenticación Kerberos. La buena noticia es que todos los síntomas se detectan con las herramientas nativas de Windows.

Prerrequisitos antes de mover roles

Antes de transferir o aprovechar la opción Seize sobre un rol FSMO, asegúrate de:

Tener al menos dos controladores de dominio operativos y replicando sin errores.
Contar con una copia de seguridad del sistema de estado (system state) reciente de cada DC.
Validar que el nivel funcional de bosque y dominio admita el nuevo sistema operativo.
Ejecutar adprep /forestprep y adprep /domainprep si aparece un nuevo mayor de versión (por ejemplo, cuando prepares Windows Server 2022).

Comprobaciones de DNS

El 90 % de los problemas post‑migración proviene de un DNS mal configurado. Sigue este guion:

Revisa las zonas directa e inversa. Cada DC debe tener un registro A y un PTR correctos.
Verifica los SRV críticos:

nslookup
set type=SRV
ldap.tcp.pdc._msdcs.&lt;dominio&gt;
kerberos.tcp.dc._msdcs.&lt;dominio&gt;

Configura los adaptadores de red: Preferido = 127.0.0.1 o la IP del propio DC; alternativo = IP de otro DC del mismo dominio. Nunca apuntes a DNS externos en un DC.
Fuerza re‑registro: ipconfig /registerdns seguido de net stop netlogon && net start netlogon.

Verificar replicación AD y SYSVOL

La replicación correcta es condición indispensable antes de mover cualquier FSMO. Compruébala así:

repadmin /replsummary
repadmin /showrepl *

En el resultado, los contadores % Error y Fails deben ser 0. Si hay errores, aborda primero la conectividad (puertos 135, 389, 445, rango RPC dinámico) y la resolución DNS antes de seguir.

Después revisa SYSVOL con:

dfsrdiag pollad
dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /partner:&lt;OtroDC&gt; /smember:&lt;DC 2016&gt;

Ambos comandos deben mostrar 0 files pendientes.

Confirmar y, si es necesario, corregir la asignación de FSMO

Para corroborar la ubicación real de cada rol:

netdom query fsmo

Truco: la consola “Active Directory Users and Computers → Operations Masters” muestra la información en caché; usa netdom para ver el dato en directo.

Si el PDC Emulator figura en el 2016 pero dcdiag todavía señala al 2008 R2, es que los SRV no se propagaron. Reinicia Netlogon, re‑registra DNS y espera la replicación o fuerza una transferencia manifiesta con:

ntdsutil
roles
connections
connect to server &lt;DC 2016&gt;
quit
transfer pdc
quit
quit

Diagnóstico exhaustivo con DCDiag

Ejecuta en el DC 2016:

dcdiag /c /v /f:dcdiag2016.log

Repasa los apartados:

Connectivity: debe indicar passed en todas las pruebas de LDAP y RPC.
DNS: sin errores de delegación ni advertencias sobre registros faltantes.
LocatorCheck y Advertising: confirman que el DC anuncia los servicios de inicio de sesión.

Corrige cualquier fallo y repite hasta obtener un informe limpio.

Sincronización horaria correcta

Kerberos es extremadamente sensible a la diferencia de tiempo; tres minutos pueden bastar para invalidar un ticket‑granting ticket. Configura el PDC Emulator (ahora el 2016) para tomar hora de una fuente NTP externa:

w32tm /config /syncfromflags:manual /manualpeerlist:"time.windows.com,0x1" /reliable:YES /update
net stop w32time &amp;&amp; net start w32time

En los demás DC y en los clientes usa:

w32tm /config /syncfromflags:domhier /update
w32tm /resync /nowait

Recomendaciones sobre firewall y puertos

Autoriza los puertos 53 TCP/UDP, 389/636 LDAP/LDAPS, 445 SMB y 135 + RPC dinámico (49152‑65535 en Windows Server 2016) entre DCs y con las subredes de clientes.
Deshabilita firewalls de terceros o crea reglas específicas para las aplicaciones NTDS, DFS‑R y DNS Server.
Comprueba la apertura con Test‑NetConnection –ComputerName <Destino> –Port 389 desde PowerShell.

Democión y repromoción del DC 2016

Si los pasos anteriores no resuelven el problema y el DC 2016 sigue sin anunciar el PDC Emulator de forma fiable, demótalo y vuélvelo a promover:

Quita el rol Active Directory Domain Services desde Server Manager.
Comprueba en el DC 2008 R2 que los roles FSMO vuelven automáticamente (o haz un Seize).
Reinicia el equipo, limpia metadatos con ntdsutil metadata cleanup, borra las entradas del servidor en Sites and Services.
Agrega de nuevo el rol AD DS, promuévelo como DC existente y deja que la replicación termine antes de devolver el PDC Emulator.

Pasos futuros: preparar la llegada de Windows Server 2022

Antes de introducir controladores 2022 conviene:

Ejecutar adprep con el binario del medio de instalación 2022.
Revisar políticas de grupo obsoletas y GPOs heredadas de versiones anteriores.
Actualizar controladores de red y firmware de los equipos físicos o hipervisores; algunos adaptadores más antiguos presentan problemas con el modo criptográfico de TLS 1.2 obligatorio en 2022.
Aprovechar para pasar de FRS a DFS‑R si aún no lo habías hecho.

Checklist rápido post‑migración

Elemento	Comando o herramienta	Resultado esperado
SRV de PDC Emulator	`nslookup`	Apunta al DC 2016
Replicación AD	`repadmin /replsummary`	Errores 0 %
SYSVOL	`dfsrdiag backlog`	0 files
Hora del dominio	`w32tm /query /status`	< 3 min de desviación
DCDiag completo	`dcdiag /c`	Todos los tests passed
Inicio de sesión cliente	Ctrl+Alt+Del	Autenticación instantánea

Conclusiones

La migración de roles FSMO a Windows Server 2016 es un proceso seguro siempre que se respete el orden lógico de DNS → replicación → rol FSMO → hora. Cuando la autenticación falla inmediatamente después del traslado, la causa suele ser un simple registro SRV huérfano o un retardo de replicación. Con las herramientas incluidas —dcdiag, repadmin, w32tm y netdom— puedes identificar y corregir el origen en minutos, garantizando un entorno preparado para futuros controladores basados en Windows Server 2022 y posteriores.