Detener replicación DC restaurado y sincronizar solo desde PDC en Active Directory

Al restaurar un controlador de dominio (DC) desde una copia de seguridad desfasada, se arriesga la coherencia del bosque. Este artículo detalla cómo aislar un DC restaurado, impedir que distribuya cambios obsoletos y forzar su actualización exclusivamente desde el Primary Domain Controller (PDC) sin interrumpir el servicio.

Comprender el riesgo de USN rollback

Active Directory replica cambios identificados por su Update Sequence Number (USN). Si un DC vuelve atrás en el tiempo, sus USN ya aplicados por los demás se repiten. El resto de los controladores puede interpretarlos como nuevos, provocando divergencias en atributos críticos (miembros de grupos, contraseñas, objetos eliminados) y, en el peor de los casos, corrupción del catálogo global.

Para minimizar el peligro:

• Verifique que la copia de seguridad sea más reciente que la tombstone lifetime (valor predeterminado 180 días desde Windows Server 2003 SP1).
• Use siempre una copia de System State; las instantáneas de volumen carecen de metadatos NTDS completos.
• Si desconoce la integridad de la copia, demote el DC y promuévalo de nuevo en lugar de arriesgar un rollback masivo.

Evaluar la antigüedad de la copia restaurada

Después de arrancar el servidor recuperado —con la tarjeta de red desconectada o en una VLAN de cuarentena— compruebe:

Get-ADObject "cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=contoso,dc=com" `
  -Properties tombstonelifetime | Select-Object tombstonelifetime

Compare la fecha actual con la marca de tiempo de backup. Si supera la tombstone, el DC contendrá objetos que ya fueron purgados en los demás sitios.

Preparar el entorno: bloquear replicación saliente

Con el DC restaurado aún aislado o antes de reconectarlo a la red:

repadmin /options <DC-Restaurado> +DISABLEOUTBOUNDREPL

Opcionalmente, bloquee la replicación entrante en sus partners directos si existieran conexiones estáticas que el KCC no podría recalcular por sí solo:

repadmin /options <Otro-DC> +DISABLEINBOUNDREPL

Aislar topológicamente el DC restaurado

Abra Active Directory Sites and Services con una cuenta Enterprise Admin:

1. Borre los Connection Objects donde el DC restaurado aparezca como origen hacia cualesquiera socios intersite o intrasite salvo el PDC.
2. Si hay muchos enlaces generados automáticamente, muévalo temporalmente a un Sitio de cuarentena sin vínculos de replicación, para impedir que el KCC lo regenere.
3. Fuerce un repadmin /kcc en los demás DC para recalcular la topología sin él.

Restauración no autoritativa versus despromoción

Cuando la copia esté dentro de la tombstone lifetime y provenga de un Windows Server Backup de System State, puede declararse non‑authoritative. Desde la consola de recuperación o con ntdsutil:

ntdsutil
activate instance ntds
authoritative restore
? (para ver las opciones)
quit

Este modo reinicia los objetos con el Invocation ID cambiado, de modo que los demás DC reenviarán todos los cambios. Si, en cambio, la copia es incompleta, demasiado antigua o sospecha de corrupción, resulta más seguro:

• Despromover el servidor mediante dcpromo /forceremoval.
• Limpiar los metadatos en otro DC (ntdsutil metadata cleanup).
• Volver a promoverlo como un DC fresco.

Sincronizar exclusivamente desde el PDC

Una vez aislado el DC restaurado, vuelva a conectarlo a la red en su sitio original y continúe:

Comprobar el estado del PDC

repadmin /showrepl <PDC>

No debería mostrar errores de Last Attempt @ yyyy-mm-dd hh:mm:ss failed.

Crear una conexión manual unidireccional

1. En AD Sites and Services, en el árbol del sitio del PDC, clic derecho en NTDS Settings > New Active Directory Connection.
2. Seleccione el DC restaurado como destino (To Server).
3. Marque Replicate from this server only y desactive Enable Intersite Messaging si no es necesario.

Forzar la puesta al día

Desde el símbolo de sistema del PDC:

repadmin /syncall /d /e /A /P <DC-Restaurado>

El modificador /A incluye todas las particiones (Schema, Configuration, Domain, etc.) y /P empuja la sincronización incluso si no había cambios aparentes.

Supervisión en tiempo real

Herramienta	Qué vigilar
repadmin /replsummary	Columna %Error debe permanecer en 0.
Visor de eventos – Directory Service (ID 1988)	Indica intentos de replicar USN anteriores a la copia.
DFSR (ID 2213)	Bloqueo SYSVOL tras restauración; desbloquear con dfsrmig /sysvol:restore tras verificar consistencia.

Rehabilitar la replicación normal

Cuando repadmin /showrepl <DC-Restaurado> muestre todas las particiones sincronizadas y ningún retraso significativo (Delta menor que el ciclo normal de KCC), revierta las opciones:

repadmin /options <DC-Restaurado> -DISABLEOUTBOUNDREPL
repadmin /options <Otros-DC> -DISABLEINBOUNDREPL

Elimine cualquier conexión manual utilizada para la recuperación de emergencia y permita que el KCC regenere la topología.

Validar SYSVOL y políticas GPO

• Compruebe el dfsrmig /getglobalstate; debe estar en estado 3 (Eliminated).
• Ejecute dcdiag /v /test:frssysvol en el DC restaurado; la prueba debe ser Successful.
• Abra gpmc.msc y ejecute Group Policy Results contra un equipo del dominio; las GPO deberían venir de cualquier DC disponible.

Lecciones aprendidas y mejores prácticas

• Automatice respaldos de System State diarios o al menos semanales en todos los DC.
• Implemente notificaciones de fallo de disco; muchos BSOD FLTMGR.sys se derivan de errores de almacenamiento.
• Habilite Recycle Bin de AD para disponer de restauraciones a nivel de objeto sin afectar USN.
• Documente el inventario de Invocation ID tras cada mantenimiento; acelera la detección de rollbacks.
• Use laboratorios de prueba con copias sanitizadas del bosque, practicando escenarios de recuperación con Hyper‑V Checkpoint o Azure Site Recovery.

Preguntas frecuentes

¿Puedo usar ntfrsutl en lugar de DFSR?
Solo en controladores que aún utilicen FRS para SYSVOL (actualizaciones in‑place de 2003/2008). En 2025, Microsoft marca FRS como no admitido; actualice a DFSR.

¿Qué ocurre si omito el bloqueo de replicación saliente?
Los objetos modificados durante los 10 días de desfase se propagarán inmediatamente, requiriendo reanimaciones autoritativas o restauraciones adicionales en todos los DC.

¿El PDC debe estar en el mismo sitio físico?
No, pero una latencia de red alta prolongará la convergencia. Si el ancho de banda es limitado, use compresión de RPC o programe la sincronización en horas valle.

Conclusión

Un BSOD no tiene por qué convertirse en una crisis de directorio. Bloqueando la replicación saliente, ajustando la topología y dirigiendo la sincronización desde el PDC, se restablece un DC restaurado sin exponer al resto del dominio a datos obsoletos. Adopte copias de System State frecuentes y ensaye este procedimiento: la preparación es la mejor defensa contra la corrupción de Active Directory.