Error de gpupdate: no se puede leer gpt.ini desde \dominio\SYSVOL (DFSR/FRS) – diagnóstico y reparación

Si tras agregar un DC adicional tu gpupdate falla con “no se puede leer gpt.ini desde \\dominio\SYSVOL\...”, casi seguro hay un problema con la replicación de SYSVOL (DFSR/FRS) o con DNS/Kerberos. Aquí tienes un procedimiento claro para diagnosticar y reparar sin caer en “arreglos” que rompen más.

Índice

Síntomas y contexto

Escenario típico: dominio/forest único con un DC principal actualizado (por ejemplo, de 2008 R2 a 2016) y un DC adicional recién promovido. Durante unos días todo replica y, de repente, empiezan errores de directiva de grupo. El mensaje más visible:

The processing of Group Policy failed...
...\\Domain\SYSVOL\Domain\Policies\{6AC1786C-016F-11D2-945F-00C04FB984F9}\gpt.ini...

El GUID {6AC1786C-016F-11D2-945F-00C04FB984F9} es la Default Domain Controllers Policy, por eso falla la parte de equipo. En el DC adicional, además, pueden “desaparecer” los recursos compartidos SYSVOL y NETLOGON o aparecer vacíos. Forzar su aparición tocando el registro sólo “pinta” las comparticiones; no repara la causa.

Causa raíz (en la mayoría de casos)

Replicación de SYSVOL interrumpida: por DFSR (Windows Server 2016+ por defecto) o por FRS (antiguo) si el dominio nunca migró SYSVOL.
Problemas de DNS/Kerberos: si accedes por IP o hay desincronización horaria > 5 min, Kerberos no funcionará y verás peticiones de credenciales o errores de acceso a \\dominio\SYSVOL.

Diagnóstico rápido (mínimo viable)

Verifica la replicación de AD

En cualquier DC con permisos de administrador:

repadmin /showrepl &gt; C:\rep1.txt
repadmin /replsum  &gt; C:\rep2.txt
repadmin /showrepl * /csv &gt; C:\repsum.csv

Objetivo: que /replsum no muestre fallos. Si hay errores en el Naming Context DomainDnsZones, ForestDnsZones o DC=domain,DC=tld, corrige primero la replicación de AD.

(Opcional con más detalle) Ejecuta:

dcdiag /e /c /v &gt; C:\dcdiag.txt

DNS, conectividad y tiempo (Kerberos)

Ambos DCs deben resolver por nombre al otro DC (A y SRV). Evita IPs para recursos de dominio.
Puertos abiertos entre DCs: 135 (RPC), 389/636 (LDAP/LDAPS), 3268/3269 (GC), 445/139 (SMB), 53 (DNS), 88 (Kerberos), 5722 (DFSR si aplica).
Diferencia horaria < 5 minutos. Comprueba y corrige NTP:

w32tm /query /status
w32tm /query /peers
w32tm /resync /force

Prueba SMB y LDAP por nombre:

Test-NetConnection DC-Principal -Port 445
Test-NetConnection DC-Principal -Port 389

Determina si SYSVOL usa DFSR o FRS

En el DC con problemas, mira el registro:

HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState

Valor	Fase de migración DFSR	Significado
0	Start	Aún no migrado
1	Prepared	Preparado para redirigir
2	Redirected	Redirigido a DFSR
3	Eliminated	DFSR en uso (FRS eliminado)

Si no existe esta clave o indica un estado previo, probablemente sigues con FRS. En 2016 lo recomendado es DFSR; si vienes de 2008 R2 sin migrar, es común encontrar FRS.

Corrección cuando usas DFSR (recomendado)

Haz una sincronización no autoritativa de SYSVOL en el DC afectado (equivalente a D2 en FRS). La idea: el DC “malo” tira su copia y vuelve a consumir todo desde el DC sano (idealmente el que tiene el rol PDC Emulator).

Antes de empezar

Confirma cuál es el DC sano (de preferencia el PDC Emulator) y que en él \\dominio\SYSVOL\dominio\Policies contiene todas las GPOs.
Copia de seguridad de C:\Windows\SYSVOL (en ambos DCs) y, si puedes, una copia del estado del sistema.
Ventanas de mantenimiento y comunicación a usuarios: durante la reparación podría no haber nuevas GPOs aplicándose en el DC afectado.

Paso a paso (no autoritativo DFSR)

Detén DFSR en el DC afectado: net stop dfsr
Deshabilita la suscripción SYSVOL mediante ADSI Edit en el DC afectado:
1. Abre “ADSI Edit” → Conectar a “Default naming context”.
2. Navega a: CN=DFSR-LocalSettings,CN=<Nombre-DC>,OU=Domain Controllers,DC=dominio,DC=tld.
3. Dentro, abre CN=Domain System Volume → CN=SYSVOL Subscription.
4. Edita el atributo msDFSR-Enabled a FALSE y aplica cambios.
Propaga y confirma (espera replicación de AD). Luego fuerza una lectura de AD: dfsrdiag pollad Revisa el Visor de eventos → “DFS Replication”: busca Evento 4114 indicando que la carpeta dejó de replicar.
Vuelve a habilitar la suscripción:
1. En el mismo objeto CN=SYSVOL Subscription, cambia msDFSR-Enabled a TRUE.
Inicia DFSR y fuerza lectura de AD: net start dfsr dfsrdiag pollad En eventos, deberías ver 4614 (“inicializando SYSVOL desde otro DC”).
Espera la sincronización inicial hasta ver Evento 4604 (“SYSVOL inicializado correctamente”). Esto restaura las comparticiones SYSVOL y NETLOGON.
Valida estado y backlog: dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" ^ /smem:DC-Sano.dominio.tld /rmem:DC-Afectado.dominio.tld net share | findstr /I "SYSVOL NETLOGON"

Señales de éxito

Existen y están pobladas: C:\Windows\SYSVOL\domain\Policies y C:\Windows\SYSVOL\domain\Scripts en el DC afectado.
La ruta de red \\dominio.tld\SYSVOL abre sin pedir credenciales (sesión de dominio) y ves las mismas GPOs desde ambos DCs.
gpupdate /force finaliza sin errores y gpresult muestra la DDC Policy aplicada.

Corrección si sigues con FRS

Si tu SYSVOL aún usa FRS (común en dominios antiguos no migrados):

Realiza una restauración no autoritativa (D2) en el DC afectado. En FRS se hacía con BURFLAGS en el registro (D2) para el servidor “malo”, y autoritaria (D4) en el servidor bueno sólo si es la única copia válida. Si no dominas FRS, evita D4 salvo que no exista otra opción.
Mejor: migra a DFSR (fases Prepared → Redirected → Eliminated) y repite la reparación con el método anterior. DFSR es más robusto y FRS está retirado en versiones modernas.

Lo que no debes hacer

No “fabriques” SYSVOL/NETLOGON cambiando claves de Netlogon para que las comparticiones aparezcan. Eso sólo expone una carpeta, no repara la replicación ni recrea las GPOs.
No copies a mano carpetas Policies entre DCs sin entender el estado de AD. Una GPO tiene componentes en AD (CN=Policies) y en SYSVOL; deben mantenerse consistentes.
No uses IP para recursos de dominio. Sin SPN Kerberos para la IP, caerás en NTLM y pedirán credenciales.

Validación posterior a la reparación

Fuerza actualización de directivas: gpupdate /force
Confirma GPOs aplicadas: gpresult /h C:\GPReport.html start C:\GPReport.html
Comprueba consistencia de GPOs (conteo de GPOs vs. carpetas en SYSVOL): dir \\dominio.tld\SYSVOL\dominio.tld\Policies y compara con lo que ves en “Group Policy Management”.

¿Cómo acceder a SYSVOL?

En local (DC): C:\Windows\SYSVOL\sysvol
Por red (recomendado): \\tudominio.com\SYSVOL (sustituye por el FQDN real). Esta ruta usa Kerberos y DNS correctamente.

¿Por qué me pide credenciales al abrir `\\IP-DC\SYSVOL`?

Porque acceder por IP evita Kerberos. No hay SPN para la IP del servidor, y Windows cae a NTLM, que suele pedir credenciales aunque ya estés logueado en el dominio. Para evitarlo:

Usa nombre o FQDN: \\DC-Principal\SYSVOL o \\tudominio.com\SYSVOL.
Inicia sesión con una cuenta de dominio y confirma que la hora está sincronizada (w32tm /resync).
Verifica DNS (A y SRV), SMB por 445, y limpia credenciales en conflicto: cmdkey /list cmdkey /delete:<target> (si procede) klist purge (si cambiaste contraseñas/SPN)
Usa rutas con nombre para recursos de dominio; las IPs déjalas para pruebas puntuales.

Comandos de referencia

Comando	Para qué sirve
`repadmin /replsum`	Resumen rápido de salud de replicación de AD entre DCs.
`repadmin /showrepl`	Detalle por Naming Context y partners.
`dcdiag /e /c /v`	Diagnóstico integral de servicios de DC.
`dfsrdiag backlog`	Backlog de replicación DFSR entre miembros.
`dfsrdiag pollad`	Fuerza a DFSR a releer configuración desde AD.
`net share`	Confirma que SYSVOL y NETLOGON están compartidos.
`w32tm /query /status`	Estado de sincronización horaria (clave para Kerberos).
`Test-NetConnection DC -Port 445`	Prueba conectividad SMB.
`Get-ADDomainController -Filter *`	Lista DCs y roles (PowerShell RSAT/AD).

Eventos y estados que debes conocer

Origen	ID	Descripción (resumen)	Qué esperar
DFS Replication	4114	El miembro dejó de replicar la carpeta.	Aparece cuando deshabilitas `msDFSR-Enabled`. Es normal en D2.
DFS Replication	4614	Inicializando SYSVOL desde otro DC.	Inicio de la sincronización no autoritativa.
DFS Replication	4604	SYSVOL inicializado correctamente.	Listo: vuelve a compartirse SYSVOL/NETLOGON.
GroupPolicy	1058/1030	No se pudo leer `gpt.ini` / error de procesamiento.	Desaparecen cuando SYSVOL vuelve a estar accesible y consistente.
Kerberos	4/5/7	Problemas de autenticación/tiempo.	Revisa NTP y DNS si aparecen.

Tabla rápida: FRS vs DFSR en SYSVOL

Característica	FRS	DFSR
Estado en versiones modernas	Antiguo/retirado	Actual/recomendado
Rendimiento/Eficiencia	Inferior	Superior (compresión, staging)
Recuperación	D2 (no autoritativo), D4 (autoritativo)	No autoritativo habilitando/rehabilitando la suscripción SYSVOL
Eventos clave	135xx	4114, 4614, 4604
Cómo saber si lo usas	Servicio `NtFrs` activo y sin migración a DFSR	Registro `LocalState=3` (Eliminated)

Checklist final

☐ Replicación de AD sana (repadmin /replsum sin errores).
☐ DNS/Kerberos correctos (resuelves por FQDN, hora sincronizada, sin usar IP).
☐ Identificado el motor de SYSVOL (DFSR/FRS) y su estado.
☐ SYSVOL/NETLOGON compartidos y ...\Policies con GPOs presentes en el DC afectado.
☐ Eventos 4614→4604 vistos en DFSR (o D2 finalizado en FRS).
☐ gpupdate /force y gpresult sin errores.
☐ Acceso a \\tudominio.com\SYSVOL sin solicitud de credenciales.

Plan B (último recurso)

Si el DC adicional no tiene roles FSMO ni cargas únicas (DNS secundario crítico, CA, etc.) y ya verificaste que AD/DNS/DFSR en el resto del dominio están sanos, considera:

Degradar el DC afectado (dcpromo / Server Manager) limpiando su metadato si es necesario.
Eliminar referencias residuales (sitios, replication connections) si quedaron.
Reprometer el servidor como DC, comprobando durante el asistente que elija correctamente el origen de SYSVOL.

Esta vía suele ser más rápida y menos riesgosa que pelear contra un SYSVOL muy roto, siempre que el DC no albergue servicios adicionales.

Buenas prácticas para no volver a caer

Supervisión: habilita alertas sobre los eventos 4114/4614/4604 y sobre GroupPolicy 1058/1030.
Backups: estado del sistema de todos los DCs y copia de SYSVOL periódica.
Evita IP para recursos de dominio; usa FQDN. Mantén la hora con NTP confiable (PDC Emulator).
Documenta quién es tu DC de referencia (normalmente el PDC) antes de hacer cualquier acción autoritativa.
Migra a DFSR si aún usas FRS.

FAQ express

¿Por qué el error cita siempre gpt.ini? Porque es el archivo mínimo que valida si una GPO es legible. Si SYSVOL no está, o no replica, la ruta al gpt.ini falla.

¿Puedo copiar a mano las carpetas de Policies? Sólo para recuperación muy controlada y sabiendo lo que haces. Lo normal es permitir que DFSR repare desde el DC sano.

¿Cuál DC uso como “bueno”? El más consistente (idealmente PDC Emulator). Valida que su \\dominio\SYSVOL contenga todas las GPOs y que repadmin esté limpio.

¿Cuánto tarda la inicialización? Depende del tamaño de SYSVOL y del ancho de banda. Revisa el backlog con dfsrdiag backlog y los eventos 4614 → 4604.

Resumen operativo: diagnostica AD/DNS/tiempo, identifica si usas DFSR o FRS, y si es DFSR haz una no autoritativa en el DC roto (deshabilitar/rehabilitar la suscripción SYSVOL, dfsrdiag pollad, eventos 4614→4604). Valida con gpupdate y accede a \\dominio\SYSVOL por FQDN, nunca por IP.