Si tu controlador de dominio en Windows Server 2022 se queda en “Waiting NTDS” y a los ~30 s cae en DSRM/Modo con errores, esta guía práctica te ayuda a aislar la causa (DNS/tiempo, SYSVOL, servicios, base NTDS) y a aplicar soluciones, desde correcciones rápidas hasta reconstruir con seguridad un DC secundario.

Qué significa “Waiting NTDS” y por qué aparece

Durante el arranque, NTDS (Active Directory Domain Services) debe inicializar la base de datos ntds.dit, montar SYSVOL y publicar puntos de servicio vía Netlogon y DNS. Si algo impide esa inicialización (DNS incorrecto, reloj desfasado, SYSVOL/DFSR en pausa, corrupción de la base de datos, puertos bloqueados o un arranque forzado en DSRM), el sistema puede quedarse en la pantalla “Waiting NTDS” y después entrar en Modo de restauración de servicios de directorio (DSRM) o “modo con errores”.

Ruta rápida de diagnóstico (checklist prioritaria)

• Red/DNS/tiempo: IP estática, DNS solo a DCs internos, latencia razonable, tiempo sincronizado.
• Visor de eventos: registros Directory Service, System y DFS Replication en busca de errores NTDS/Netlogon/DFSR/disco.
• Disco y rutas: espacio libre suficiente y rutas de NTDS (DB+logs) intactas.
• Arranque: confirmar que no esté activado “Safe boot: Active Directory repair”.
• Replicación: salud general (dcdiag/repadmin) y estado de SYSVOL (DFSR).

Verificación de red, DNS y tiempo (imprescindible)

En un DC, el DNS no debe apuntar a servidores públicos. Usa PDC o DCs internos (a veces a sí mismo como secundario). Comprueba conectividad, descubrimiento de DC y registros SRV:

ipconfig /all
ping <PDC>
nltest /dsgetdc:<tu-dominio>
nslookup ldap.tcp.dc._msdcs.<tu-dominio>

Verifica hora/sincronización. Desviaciones de minutos rompen Kerberos:

w32tm /query /status
w32tm /config /syncfromflags:domhier /update
w32tm /resync /force

Si el PDC emulador está en otra sede o VM, asegúrate de que solo el PDC tenga origen horario externo confiable y que los demás DCs hereden del dominio. Evita la sincronización de hora del hipervisor en los DCs (excepto quizá en el PDC emulador con cuidado).

Revisar el Visor de eventos con intención

• Directory Service: errores de base de datos NTDS, inicialización o seguridad.
• System (Netlogon/Kerberos/LSA): fallos de descubrimiento/registro 2087/2088 (DNS), 5719 (Netlogon), problemas de KDC.
• DFS Replication: 2213 (replicación pausada por recuperación), 4012/4016 (inconsistencias), errores de journal.
• Disco/Controladores: advertencias de E/S, eventos disk/ntfs, problemas de NIC.

Espacio en disco y rutas NTDS/logs

Confirma que C:\Windows\NTDS y el volumen de logs tienen espacio. Reúne información precisa:

dir C:\Windows\NTDS
fsutil volume diskfree C:
sc query ntds

Extrae rutas exactas de base y logs:

ntdsutil "activate instance ntds" "files" "info" quit quit

Comprueba si el servidor se está forzando a DSRM

Una causa muy común del bucle “Waiting NTDS → DSRM” es haber dejado Safe boot activo (por MSConfig o BCD). Revisa y corrige:

bcdedit
REM Si ves "safeboot" o "safebootalternateshell", elimínalo:
bcdedit /deletevalue {current} safeboot
bcdedit /deletevalue {current} safebootalternateshell

Además, confirma en msconfig → Arranque que no esté marcado “Arranque a prueba de errores > Reparación de Active Directory”.

Arranca en DSRM para inspección y reparación

Si AD DS no levanta, inicia en DSRM (necesitas la contraseña de administrador DSRM). Desde allí:

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

REM Integridad de la base de datos
esentutl /g "C:\Windows\NTDS\ntds.dit" 

Si esentutl /g informa errores, documenta el detalle y decide: restaurar desde copia de seguridad (preferible) o reparación/compacción offline con ntdsutil (solo si no hay backup y asumiendo riesgo). Siempre crea un backup del volumen antes.

Salud integral una vez levante “normal”

dcdiag /v /c /e /fix > C:\Temp\dcdiag.txt
dcdiag /test:DNS /v > C:\Temp\dcdiag_dns.txt
repadmin /replsummary
repadmin /showrepl *
repadmin /queue
nltest /dsregdns

Puertos y firewall necesarios entre DCs

Servicio	Puerto/Protocolo	Uso
DNS	53/TCP, 53/UDP	Resolución y registros SRV
Kerberos	88/TCP, 88/UDP	Autenticación
Kerberos (kpasswd)	464/TCP, 464/UDP	Cambio de contraseña
LDAP	389/TCP, 389/UDP	Catálogo AD
LDAPS	636/TCP	LDAP con TLS
Global Catalog	3268/TCP, 3269/TCP	GC / GC sobre TLS
RPC EPM	135/TCP	Mapeador de puntos finales
RPC dinámico	49152–65535/TCP	Rango predeterminado en Windows modernos
SMB/Netlogon	445/TCP	Scripts/NETLOGON/SYSVOL
DFSR	5722/TCP	Replicación SYSVOL
NTP	123/UDP	Tiempo (w32time)

Tras corregir red/DNS/tiempo, reinicia Netlogon para republicar SRV:

net stop netlogon && net start netlogon
ipconfig /flushdns && ipconfig /registerdns

SYSVOL con DFSR pausado (tras apagado brusco)

Si ves en DFS Replication el evento 2213 (“replicación pausada por sobrerrecuperación”), reanuda:

dfsrdiag pollad
wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="<GUID>" call ResumeReplication

Confirma el backlog entre el PDC (origen) y el DC afectado (destino):

dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" ^
 /sendingmember:<PDC> /receivingmember:<EsteDC>

Si DFSR no converge o detectas inconsistencias persistentes, evalúa una reconstrucción del DC secundario (ver sección más abajo) o un procedimiento de restauración de SYSVOL acorde a tu topología (autoritaria/no autoritaria). Evita FRS (obsoleto) y no mezcles metodologías.

Corrupción o problemas de la base de datos NTDS

Resultados posibles de esentutl /g:

• Sin errores: el problema suele ser DNS/tiempo/DFSR/puertos.
• Errores leves: intenta compacción offline y reparación controlada:

REM Desde DSRM, con AD detenido
ntdsutil "activate instance ntds" "files" "compact to C:\NTDSCompact" quit quit
REM Copia manualmente los archivos compactados de vuelta (DB y logs) tras respaldar los actuales.

• Errores severos: restaura System State desde backup conocido (recomendado). Ejemplo:

wbadmin get versions -backuptarget:<Destino>
wbadmin start systemstaterecovery -version:<YYYY-MM-DD-HH:MM>

Si no tienes backup y el DC es secundario, la opción más segura y rápida es despromover y volver a promover. Evitarás riesgos de integridad del bosque.

Cuidados especiales en entornos virtualizados

• Prohibido revertir snapshots de DCs en producción: riesgo de USN rollback.
• Deshabilita sincronización de hora del hipervisor en DCs (y planifica el origen horario del PDC).
• Actualiza Integration Services/VM Tools y controladores NIC.

Vía de salida cuando el DC afectado es secundario

Con un PDC sano, la estrategia preferida suele ser reconstruir el DC problemático. Pasos:

1) Despromoción forzada (si no contacta al dominio)

Uninstall-ADDSDomainController -ForceRemoval `
  -LocalAdministratorPassword (Read-Host -AsSecureString)

Si aún puede contactar, usa el asistente normal de “Quitar Active Directory Domain Services”.

2) Limpieza de metadatos y DNS

• En un DC sano, elimina el objeto NTDS Settings y el servidor del sitio en Active Directory Sites and Services.
• Borra los registros DNS A/AAAA, PTR y SRV del DC antiguo.
• Opcional (PowerShell):

# Eliminar objeto de equipo (si aún existe) tras la despromoción forzada
Remove-ADComputer -Identity "DC-Afectado$" -Confirm:$false

Ver FSMO (por seguridad, no debería tenerlos)

netdom query fsmo 

3) Volver a unir y promover

Add-Computer -DomainName <tu-dominio> -Credential <Dom\Administrador> -Restart

Instalar rol y volver a promover como DC (y DNS si procede)

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Install-ADDSDomainController -DomainName \<tu-dominio> -InstallDns

Si era Catálogo Global:

(Marcar GC en NTDS Settings o usar interfaz gráfica)

Tras la promoción, espera la convergencia de replicación y verifica SYSVOL/NETLOGON.

Diagnóstico y solución de DNS/Netlogon

Ejecuta pruebas dirigidas a DNS y republicación de SRV:

dcdiag /test:DNS /e /v
ipconfig /flushdns
ipconfig /registerdns
nltest /dsregdns

Comprueba que las zonas integradas en AD (<tu-dominio> y _msdcs.<tu-dominio>) están presentes y replicando. Si detectas zonas huérfanas o inconsistentes, corrige la topología de replicación y los ámbitos (ForestDnsZones/DomainDnsZones) antes de volver a probar.

Revisión de servicios y dependencias

Asegura que los servicios críticos estén en Automatic y Running tras el arranque:

• Active Directory Domain Services (NTDS)
• Netlogon
• Kerberos Key Distribution Center
• DNS Server (si hospeda DNS)
• DFS Replication

Control rápido:

sc query ntds
sc query netlogon
sc query kdc
sc query dns
sc query dfsr

Árbol de decisión express

• ¿Safe boot activo? Sí → Quita safeboot y reinicia. No → Siguiente.
• ¿DNS externo configurado? Sí → Corrige a DCs internos, reinicia Netlogon. No → Siguiente.
• ¿Hora desfasada > 5 min? Sí → Repara w32time, resincroniza. No → Siguiente.
• ¿DFSR 2213/4012? Sí → Reanuda DFSR y espera convergencia. No → Siguiente.
• esentutl /g con errores? Sí → Restaurar/compactar o reconstruir DC secundario. No → Siguiente.
• ¿Puertos/firewall? Bloqueados → Abrir según tabla. Todo OK → Revisión de hardware/controladores.

Validación final (criterios de éxito)

• Servicios Active Directory Domain Services y Netlogon en Running.
• Comparte SYSVOL y NETLOGON accesibles: \\EsteDC\SYSVOL y \\EsteDC\NETLOGON.
• dcdiag sin errores críticos y repadmin /replsummary sin fallos ni latencias anómalas.
• El arranque ya no muestra “Waiting NTDS”.

Buenas prácticas para evitar reincidencias

• Backups de System State verificados y con rotación adecuada.
• Monitoreo proactivo de eventos críticos (DFSR 2213/4012; Netlogon 5719; DNS 4013).
• Revisión mensual de dcdiag/repadmin y del espacio en NTDS.
• Política de no revertir snapshots de DCs.
• Topología de replicación coherente y puertos documentados en firewall.

Playbook reutilizable (comandos resumidos)

:: Conectividad y descubrimiento
ping <PDC>
nltest /dsgetdc:<tu-dominio>
nslookup ldap.tcp.dc._msdcs.<tu-dominio>
w32tm /query /status

\:: DNS/Netlogon
dcdiag /test\:DNS /e /v
ipconfig /flushdns
ipconfig /registerdns
net stop netlogon && net start netlogon

\:: Salud de AD
dcdiag /v /c /e /fix > C:\Temp\dcdiag.txt
repadmin /replsummary
repadmin /showrepl \*
repadmin /queue
nltest /dsregdns

\:: DFSR / SYSVOL
dfsrdiag pollad
dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" ^
/sendingmember:\ /receivingmember:\

\:: NTDS en DSRM
esentutl /g "C:\Windows\NTDS\ntds.dit"
ntdsutil "activate instance ntds" "files" "info" quit quit

\:: Sistema
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

\:: Arranque/DSRM
bcdedit
bcdedit /deletevalue {current} safeboot
bcdedit /deletevalue {current} safebootalternateshell

\:: Re-promoción (DC secundario)
Uninstall-ADDSDomainController -ForceRemoval -LocalAdministratorPassword (Read-Host -AsSecureString)
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Install-ADDSDomainController -DomainName \ -InstallDns 

Plantilla de registro durante la intervención

Ítem	Resultado/Notas
DNS configurado	Solo DCs internos: Sí/No
Tiempo sincronizado	Desvío (ms):
Eventos críticos	IDs/Descripción
Espacio en NTDS/logs	Libre:
DFSR estado	2213/4012/OK
esentutl /g	OK/Errores
Puertos/firewall	OK/Corregido
Acción aplicada	Reparar/Rebuild
Validación	dcdiag/repadmin OK

Resumen ejecutivo (causa–efecto–acción)

Causa típica	Indicios	Acción correctiva
DNS externo/incorrecto	dcdiag DNS falla; Netlogon 5719; 2087/2088	Apuntar a DCs internos, reiniciar Netlogon, registrar SRV
Desfase de tiempo	Kerberos fallos; tickets inválidos	w32tm domhier, resync, ajustar NTP del PDC
DFSR en pausa (2213)	SYSVOL no compartido; backlog alto	ResumeReplication, dfsrdiag backlog hasta 0
Corrupción NTDS	esentutl /g falla; errores LSASS	Restaurar System State o reconstruir DC secundario
Puertos/firewall bloqueados	repadmin errores RPC; EPM 135	Abrir puertos tabla; validar RPC dinámico
Safe boot DSRM activo	Siempre entra a DSRM	Eliminar safeboot del BCD y reiniciar

Conclusión

“Waiting NTDS” casi siempre apunta a un problema de infraestructura (DNS/tiempo/puertos) o de orquestación (DFSR/SYSVOL) y, con menor frecuencia, a corrupción de la base de datos. Atajar primero red/DNS/tiempo y DFSR acelera el retorno a la normalidad. Si el servidor afectado es un DC secundario y no hay backup limpio, despromover + limpiar metadatos + re-promover suele ser la vía más rápida y segura para restablecer el servicio sin comprometer la integridad del bosque.