Problema

En entornos con controladores de dominio (DC) mixtos – por ejemplo, un DC antiguo en Windows Server 2012 y uno nuevo en Windows Server 2022 – es frecuente que la promoción del nuevo servidor finalice sin errores aparentes, pero el recurso compartido SYSVOL quede sin los archivos habituales (Policies, Scripts, NETLOGON).

Los síntomas típicos son:

  • El share SYSVOL aparece, pero dentro solo existe la carpeta DfsrPrivate.
  • La carpeta NETLOGON no se crea y los tests dcdiag /test:netlogons fallan.
  • repadmin /replsummary muestra cero fallos, y dfsrdiag indica estado Normal (4) y “initial synchronization completed”.
  • Los clientes no pueden aplicar GPOs ni ejecutar scripts de inicio de sesión.

A primera vista parece un problema de replicación resuelto, pero la ausencia de contenido en SYSVOL impide que el DC participe plenamente en el dominio.

Causa

El motor DFSR tiene dos fases distintas para SYSVOL:

  1. Inicialización – crea la estructura de carpetas y sincroniza el contenido.
  2. Publicación – una vez completada la sincronización, el servicio Netlogon expone los shares.

Cuando la fase de publicación no se dispara, el estado de DFSR sigue reportando “Normal” porque no hay backlog que replicar. Las causas más habituales son:

1. Estado de SYSVOL bloqueado por una referencia a la versión anterior (FRS)

Si el DC original nunca migró de FRS a DFSR, la clave de registro HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\SysvolReady puede quedar en 0. DFSR termina la replicación, pero Netlogon no habilita los shares.

2. Permisos insuficientes en la carpeta raíz

El proceso System necesita control total sobre C:\Windows\SYSVOL\domain. Si la ACL está dañada (por ejemplo, después de una restauración de VM) DFSR escribe DfsrPrivate pero Netlogon rechaza la publicación.

3. Desincronización de la base de datos de DFSR

Una base de datos corrupta o un journal incompleto impide que el agente marque la replicación como “eliminada”. El evento 4604 se genera, pero el flag interno que indica “SYSVOL ready” nunca se actualiza.

4. Configuración de “Sysvol” en la política de sitio

Un Site sin conexión directa al DC antiguo puede hacer que el nuevo DC sea considerado “inbound replication only”. En ese caso, DFSR recibe los cambios pero Netlogon no los publica porque la topología no permite escritura.

5. Actualizaciones de Windows Server 2022 que alteran el comportamiento de DFSR

En algunos builds, una actualización de seguridad modifica la forma en que DFSR verifica la integridad del directorio SYSVOL. Si la versión del parche no está alineada entre los DCs, el proceso de publicación se queda en espera.

Solución

El objetivo es forzar a Netlogon a reconocer que la replicación está completa y habilitar los shares. El proceso se divide en tres pasos: validar permisos, resetear el estado de SYSVOL y forzar una replicación autoritativa.

Paso 1 – Verificar y reparar ACLs

icacls "C:\Windows\SYSVOL\domain" /reset /t
icacls "C:\Windows\SYSVOL\domain" /grant "SYSTEM:(OI)(CI)F" /inheritance:e

Esto asegura que el contexto de seguridad del sistema tenga control total y que la herencia esté habilitada. Después de aplicar, reinicie el servicio Netlogon:

net stop netlogon && net start netlogon

Paso 2 – Resetear la señal de “SYSVOL listo”

  1. Detenga los servicios DFSR y Netlogon:
net stop dfsr
net stop netlogon
  1. Elimine la marca de “incompleto” del registro:
reg delete "HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" /v SysvolReady /f
  1. Borre el contenido temporal de DfsrPrivate (solo la carpeta, no la raíz):
rd /s /q "C:\Windows\SYSVOL\domain\DfsrPrivate"
mkdir "C:\Windows\SYSVOL\domain\DfsrPrivate"
  1. Reinicie los servicios:
net start dfsr
net start netlogon

Al iniciar, DFSR recreará la base de datos y Netlogon volverá a evaluar el estado. El evento 4616 (“SYSVOL shared”) aparecerá en el visor de eventos.

Paso 3 – Replicación autoritativa (si el contenido sigue vacío)

Ejecute en el DC problemático:

dfsrdiag pollad /partner:<NombreDCAnterior>
dfsrdiag syncnow /partner:<NombreDCAnterior> /RGName:"Domain System Volume"

Si la replicación no trae los objetos, realice un authoritative restore de SYSVOL:

ntfrsutl authoritative /sysvol

Luego, fuerce la sincronización completa:

repadmin /syncall /AdeP

Este comando obliga a todos los partners a aceptar el estado actual del DC como la fuente de verdad, lo que repuebla Policies y Scripts.

Cuándo aplicar esta solución

Aplica cuando:

  • La promoción del DC finaliza sin errores, pero el share NETLOGON no aparece.
  • dfsrdiag muestra estado Normal (4) y cero backlog, mientras que SYSVOL contiene solo DfsrPrivate.
  • Los tests de dcdiag /test:netlogons fallan y los clientes no reciben GPOs.

No aplica si:

  • El DC muestra errores de conexión de red (DNS, firewalls) que impiden cualquier replicación.
  • El registro de eventos indica fallos de DFSR (código 5000‑5010) que requieren reparación de la base de datos antes de tocar SYSVOL.
  • La infraestructura usa FRS en lugar de DFSR; en ese caso el procedimiento de migración a DFSR es diferente.

Código

# Paso 1: reparar ACLs y reiniciar Netlogon
icacls "C:\Windows\SYSVOL\domain" /reset /t
icacls "C:\Windows\SYSVOL\domain" /grant "SYSTEM:(OI)(CI)F" /inheritance:e
net stop netlogon && net start netlogon

# Paso 2: resetear señal de SYSVOL listo
net stop dfsr
net stop netlogon
reg delete "HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" /v SysvolReady /f
rd /s /q "C:\Windows\SYSVOL\domain\DfsrPrivate"
mkdir "C:\Windows\SYSVOL\domain\DfsrPrivate"
net start dfsr
net start netlogon

# Paso 3: forzar replicación autoritativa si es necesario
dfsrdiag pollad /partner:DC-ANTERIOR
dfsrdiag syncnow /partner:DC-ANTERIOR /RGName:"Domain System Volume"
ntfrsutl authoritative /sysvol
repadmin /syncall /AdeP

Verificación

  1. Comprobar shares

    net share

    Deberían aparecer SYSVOL y NETLOGON con rutas correctas.

  2. Validar contenido
    Navegue a C:\Windows\SYSVOL\domain\Policies y confirme la presencia de los GUID de GPO.

  3. Ejecutar pruebas de diagnóstico

    dcdiag /test:netlogons /v /c /d
repadmin /replsummary
dfsrdiag backlog /RGName:"Domain System Volume"

    Todos deben devolver “0” o “No backlog”.

  4. Forzar aplicación de GPO en un cliente

    gpupdate /force

    El cliente debe actualizar sin errores y reflejar los cambios de política.

Notas adicionales

  • Después de cualquier manipulación del registro, haga una copia de seguridad del mismo. Un error tipográfico puede dejar el DC sin capacidad de iniciar sesión.
  • Si el entorno tiene varios DCs, repita el paso de ACLs en cada uno antes de forzar la replicación autoritativa; de lo contrario, los partners pueden sobrescribir el contenido recién creado.
  • En versiones de Windows Server 2022 posteriores a la build 20348.1500, Microsoft introdujo una verificación de “SysvolReady” más estricta. Mantenga los servidores alineados con el mismo nivel de parche para evitar inconsistencias.
  • Siempre revise el visor de eventos bajo DFS Replication y Netlogon después de cada paso; los códigos 4616 y 4618 indican que el proceso de publicación se completó con éxito.