Problema

En entornos con varios Domain Controllers (DC) basados en Windows Server 2019 (o versiones cercanas), es frecuente que, después de una operación de metadata cleanup o de cambios manuales en la configuración DNS, uno o más DC dejen de poder localizar el dominio. Los síntomas típicos son:

  • Mensaje “Naming information cannot be located because: The specified domain does not exist or could not be contacted”.
  • Fallos de Group Policy, errores 1054 y 1126 en el visor de eventos.
  • Replicación inter‑DC interrumpida (eventos 5012, 2921, 1003).
  • Herramientas como dcdiag y nltest reportan que no se encuentra un Global Catalog (GC) ni un DC disponible.

El problema no está limitado a un caso puntual; cualquier alteración que rompa la cadena de confianza DNS‑AD o que elimine objetos de la base de datos sin actualizar la topología de replicación puede desencadenar este patrón.

Causa

1. Metadatos incompletos o erróneos

Cuando se elimina un DC con metadata cleanup, los objetos de sitio, de servidor y de conexión de replicación deben desaparecer de todos los demás DC. Si quedan referencias huérfanas, el KCC (Knowledge Consistency Checker) genera objetos con atributos faltantes, lo que se refleja en eventos 2921 y 5012.

2. DNS desincronizado

Los DC actúan como servidores DNS autoritativos para la zona del dominio. Si la zona no se replica correctamente, o si los registros _ldap._tcp.dc._msdcs. desaparecen, los clientes (incluidos los propios DC) no pueden resolver el nombre del dominio. La configuración de encaminadores (forwarders) no afecta a la resolución interna, pero una zona dañada sí.

3. Falta de Global Catalog

Algunos servicios (por ejemplo, la autenticación de usuarios de otro sitio) requieren un GC. Si el GC está offline o la lista de GC está corrupta, el evento 1126 aparecerá y la replicación se detendrá.

4. Configuración de red estática inconsistente

Los DC con IP estática deben apuntarse mutuamente como servidores DNS preferidos. Un error tipográfico o una máscara de subred equivocada impide la resolución de nombres internos, provocando los mismos síntomas.

5. Replicación de SYSVOL / DFSR rota

Si la replicación de la carpeta SYSVOL falla, los controladores de dominio no pueden aplicar políticas ni compartir scripts, lo que genera los eventos 1054 y 1003.

Solución

Paso 1 – Verificar conectividad DNS básica

  1. Desde cada DC, ejecutar nslookup <domain> y nslookup _ldap._tcp.dc._msdcs.<domain>.
  2. Confirmar que los registros SRV aparecen y que la respuesta proviene del propio DC.

Si la consulta falla, procede a reparar la zona:

  • Abre DNS Manager en un DC que aún responda.
  • Revisa la zona Forward Lookup Zones → y verifica que existan los sub‑árboles _msdcs, _sites, _tcp, _udp.
  • Si falta algún contenedor, recrea manualmente los registros SRV usando dnscmd o la consola.

Paso 2 – Limpiar referencias huérfanas con repadmin

Ejecuta en cada DC operativo:

repadmin /showrepl *
repadmin /removelingeringobjects <DC-objetivo> <naming-context> /ADVisory

El primer comando muestra la topología actual; el segundo elimina objetos de replicación que ya no existen en el origen. Repite hasta que repadmin /showrepl muestre “No errors”.

Paso 3 – Forzar la reconstrucción de la topología KCC

En cada DC, corre:

nltest /dsgetsite
nltest /sc_reset:<domain>

Luego, reinicia el servicio NTDS (net stop ntds && net start ntds) o, si es posible, reinicia el servidor. El KCC recalculará los enlaces de replicación y eliminará los objetos con atributos faltantes.

Paso 4 – Verificar y, si es necesario, promover un nuevo GC

Si ninguno de los DC restantes actúa como GC, promueve uno:

ntdsutil
activate instance ntds
ifm
create full <ruta>
quit

Después, en Active Directory Sites and Services, clic derecho sobre el servidor → Properties → marca Global Catalog. Espera a que la replicación sincronice el catálogo.

Paso 5 – Revisar SYSVOL / DFSR

Comprueba el estado con:

dfsrdiag ReplicationState

Si aparecen errores, fuerza una sincronización:

dfsrdiag SyncNow /Partner:<partnerDC> /RGName:"Domain System Volume"

Si la carpeta SYSVOL sigue sin replicarse, revisa los registros de DFS Replication y, como último recurso, ejecuta ntfrsutl forcerepl.

Paso 6 – Validar la salud general con dcdiag

Ejecuta:

dcdiag /v /c /d /e > C:\dcdiag.txt

Revisa el archivo en busca de errores críticos. Si dcdiag ya no reporta “The specified domain does not exist”, la reparación está completa.

Cuándo aplicar esta solución

  • Síntomas: errores 1054, 1126, 5012, 2921; mensajes de “cannot locate domain”; fallos de GPO; incapacidad de iniciar sesión con cuentas de dominio.
  • Entorno: al menos dos DC en el mismo dominio, con DNS interno alojado en los propios DC, y con replicación de AD y SYSVOL habilitada.
  • No aplica: cuando el dominio está completamente offline y no hay ningún DC funcional; en ese caso la recuperación requiere una restauración desde backup o una reconstrucción completa del dominio.

Código

# Verificar replicación y limpiar objetos huérfanos
repadmin /showrepl *
repadmin /removelingeringobjects DC1 "DC=contoso,DC=com" /ADVisory

# Reiniciar servicios críticos
net stop ntds && net start ntds

# Forzar sincronización DFSR del SYSVOL
dfsrdiag SyncNow /Partner:DC2 /RGName:"Domain System Volume"

# Diagnóstico completo
dcdiag /v /c /d /e > C:\dcdiag.txt

Verificación

  1. DNS: nslookup _ldap._tcp.dc._msdcs.<domain> debe devolver al menos dos registros (uno por cada DC).
  2. Replicación: repadmin /replsummary muestra “0 failures” y “0 pending updates”.
  3. GC: nltest /dsgetgc:<domain> devuelve la lista de Global Catalogs activos.
  4. GPO: Ejecuta gpresult /r en un cliente; debe mostrar que la política se aplica sin errores 1054.
  5. Event Viewer: Busca los IDs 5012, 2921, 1054, 1126; todos deben estar ausentes o en nivel “Information”.

Notas adicionales

  • Siempre que realices una metadata cleanup, confirma primero que el DC eliminado no posee roles FSMO. Usa netdom query fsmo antes de proceder.
  • Mantén al menos un DC configurado como Global Catalog en cada sitio; esto evita que la pérdida de un GC provoque bloqueos de autenticación.
  • Después de cualquier cambio en DNS o replicación, permite al menos 15 minutos para que la zona se propague antes de volver a ejecutar diagnósticos.
  • Si la zona DNS está integrada en AD, evita editarla manualmente con la consola DNS; usa ADSIEdit o repadmin para cambios estructurales.
  • Documenta los cambios de IP estática y los servidores DNS preferidos en un registro de configuración; un simple error tipográfico suele ser la causa raíz de muchos de estos incidentes.