SYSVOL non si replica tra Domain Controller: guida completa a DFSR/FRS, errori gpupdate e ripristino non‑authoritative

Hai promosso un secondo Domain Controller e, dopo pochi giorni, i Criteri di gruppo non si applicano, gpupdate restituisce l’errore su gpt.ini e su quel DC le condivisioni SYSVOL e NETLOGON sono vuote o assenti. In questa guida trovi una procedura completa e verificata per ripristinare la replica di SYSVOL con DFSR o, se ancora presente, con FRS.

Indice

Scenario e sintomi

Ambiente con foresta a dominio singolo e due DC: un “principale” (Windows Server 2016 Datacenter, aggiornato da 2008 R2) e un DC aggiuntivo promosso di recente. Trascorsa circa una settimana dalla promozione del secondo DC:

Su DC‑2, gpupdate mostra: The processing of Group Policy failed… impossibile leggere \<dominio>\SYSVOL\…\gpt.ini.
Le cartelle SYSVOL e NETLOGON risultano vuote o non condivise; una modifica al Registro ha ricreato le cartelle, ma i criteri non si replicano.
In sostanza, la replica di SYSVOL non funziona e quindi i GPO non vengono applicati.

Perché accade

In un dominio Active Directory i file dei criteri (cartella Policies con i relativi gpt.ini) vengono distribuiti tramite la replica di SYSVOL. Storicamente la replica era gestita da FRS (File Replication Service), deprecato da Windows Server 2008 R2, e oggi dal DFSR (DFS Replication). Se il tuo ambiente è stato aggiornato nel tempo senza migrare, è possibile che alcuni DC usino ancora FRS o che la migrazione a DFSR non sia completa. Inoltre, interruzioni “sporche” del servizio, problemi DNS/secure channel o un database corrotto possono bloccare la replica di SYSVOL su un singolo membro.

Verifiche diagnostiche essenziali

Passaggio	Comandi/strumenti	Scopo
Controllo replica AD	`repadmin /showrepl`, `repadmin /replsummary` (o `/replsum`), `repadmin /showrepl * /csv`, `dcdiag /v`	Confermare che la replica AD tra i DC sia corretta: errori qui vanno risolti prima di SYSVOL.
Identificare il motore di replica SYSVOL	Registro: `HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState` (3 = DFSR); oppure `dfsrmig /getglobalstate`/`/getmigrationstate`	Capire se SYSVOL è sotto DFSR o FRS per applicare la procedura corretta.
Backup di sicurezza	Snapshot/backup dei DC + copia di `C:\Windows\SYSVOL`	Consentire il ripristino in caso di errori nei passaggi successivi.

Controlli preliminari (da non saltare)

DNS: su tutti i DC usa solo DNS interni autorevoli per il dominio. Verifica con ipconfig /all e correggi eventuali DNS pubblici.
Secure Channel: sul DC problematico esegui nltest /scquery:<dominio>. Se fallisce, ripristina con nltest /screset:<dominio> e riprova.
Servizi: assicurati che DFS Replication (o File Replication Service se usi FRS) e Netlogon siano in Automatico e In esecuzione.
Condivisioni: controlla con net share che SYSVOL e NETLOGON siano presenti sul DC principale. Sul DC aggiuntivo possono essere assenti se la replica non è a posto.
Event Viewer: ispeziona i registri DFS Replication o File Replication Service per ID evento tipici (vedi sotto).

Determinare se SYSVOL usa DFSR o FRS

Usa uno (o più) dei metodi seguenti:

Chiave Registro (rapida): su un DC, verifica HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState. Valore 3 = DFSR in uso. Chiave assente o valore diverso = sistema non migrato (probabile FRS).
dfsrmig: esegui dfsrmig /getglobalstate. Se lo stato è 3 (Eliminated), FRS è stato eliminato e il dominio usa DFSR per SYSVOL. Stati 0/1/2 indicano migrazione non completa.
Servizi: se su tutti i DC vedi il servizio File Replication Service attivo e DFS Replication non coinvolto per SYSVOL, stai usando FRS.

Risoluzione con DFSR: ripristino non‑authoritative del DC problematico

Questa procedura (equivalente al vecchio D2 di FRS) forza il DC aggiuntivo a risincronizzare il proprio SYSVOL dal partner sano. Non tocca i GPO sul DC “buono”.

Playbook passo‑passo (PowerShell/ADSIEdit)

Fermare DFSR sul DC problematico
Stop-Service DFSR In alternativa da CMD: net stop dfsr.
Disabilitare temporaneamente la membership SYSVOL su quel DC
Con ADSIEdit, vai in: Configuration → CN=Sites → CN=<Sito> → CN=Servers → CN=<DC-problematico> → CN=DFSR-LocalSettings → CN=Domain System Volume (SYSVOL share) e imposta msDFSR-Enabled a FALSE.
In PowerShell (modulo AD), sostituisci DN e nome server: $server = "DC-2" $dn = "CN=Domain System Volume (SYSVOL share),CN=DFSR-LocalSettings,CN=$server,OU=Domain Controllers,DC=contoso,DC=local" Set-ADObject -Identity $dn -Replace @{'msDFSR-Enabled'=$false}
Forzare la replica AD e far “leggere” la modifica a DFSR
repadmin /syncall /APeD dfsrdiag PollAD Attendi l’evento 4114 nel log DFS Replication del DC problematico (indica che SYSVOL non è più replicato su quel membro).
Riabilitare la membership SYSVOL
Con ADSIEdit rimetti msDFSR-Enabled a TRUE (o PowerShell): Set-ADObject -Identity $dn -Replace @{'msDFSR-Enabled'=$true} repadmin /syncall /APeD dfsrdiag PollAD Ora il DC dovrebbe avviare una initial sync di SYSVOL dal partner.
Monitorare la convergenza
- Eventi attesi: 4012 (in attesa della replica iniziale), 4602 (inizializzazione completata), eventuale 4604/4612 a conferma della condivisione creata.
- Backlog: dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /smem:DC-1 /rmem:DC-2 Il backlog deve scendere a 0.
- Condivisioni: net share Dovresti vedere SYSVOL e NETLOGON.
Verifica contenuti e GPO
Controlla che su DC‑2 siano presenti gpt.ini e le cartelle Policy GUID in: C:\Windows\SYSVOL\sysvol<dominio>\Policies Esegui quindi: gpupdate /force gpresult /r L’errore su gpt.ini deve sparire.

Se vedi l’evento DFSR 2213 (arresto “sporco”)

DFSR può sospendere l’auto‑recupero dopo uno spegnimento anomalo. In quel caso, oltre al playbook sopra, sblocca l’auto‑recupero:

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set StopReplicationOnAutoRecovery=0
net start dfsr

Controlla che la replica riparta e prosegui con i passaggi di non‑authoritative sync.

Alternative “di banco” (solo se necessario)

Rigenerare il database DFSR (ultima spiaggia): Stop‑Service DFSR, rinomina la cartella C:\System Volume Information\DFSR, quindi riattiva la membership come sopra e riavvia DFSR. Questo forza la risincronizzazione completa. Usare solo se il metodo standard non funziona.

Risoluzione con FRS: reset D4/D2

Se l’ambiente usa ancora FRS per SYSVOL (vecchi domini non migrati), procedi così. Nota: su Windows Server 2019 e successivi FRS non è più supportato; su 2016 è deprecato. Appena risolto, pianifica la migrazione a DFSR (vedi sezione dedicata).

Reset autorevole (D4) sul DC principale

Ferma FRS: net stop ntfrs
Imposta BurFlags a D4 sul DC “buono”: reg add "HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup" ^ /v BurFlags /t REG_DWORD /d 0x000000D4 /f
Riavvia FRS: net start ntfrs

Reset non‑autorevole (D2) sul DC aggiuntivo

Ferma FRS: net stop ntfrs
Imposta BurFlags a D2: reg add "HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup" ^ /v BurFlags /t REG_DWORD /d 0x000000D2 /f
Avvia FRS: net start ntfrs

Eventi FRS attesi nel Visualizzatore eventi del DC aggiuntivo:

13565: Pre‑esistente SYSVOL: preparazione alla replica.
13566/13520: Avanzamento della replica iniziale.
13516: Il servizio FRS è in esecuzione correttamente (replica pronta).
13508 → 13509: Problemi/recupero connettività di replica, se presenti.

Quando la replica finisce, su DC‑2 ricompaiono SYSVOL/NETLOGON e i GPO sotto ...\Policies. Esegui gpupdate /force per confermare.

Domande correlate (FAQ) e risposte rapide

Domanda	Risposta sintetica
Perché su DC‑2 mi chiede utente/password quando apro `\\IP-DC1\SYSVOL`?	Probabile assenza di secure channel o credenziali memorizzate. Verifica con `nltest /scquery:<dominio>`; se fallisce, ripristina con `nltest /screset:<dominio>`. In alternativa accedi con un account Domain Admin: `net use \\192.168.1.1\SYSVOL /u:DOMINIO\Admin`.
Come accedere a SYSVOL localmente?	Esegui logon sul DC e apri `C:\Windows\SYSVOL\sysvol` oppure digita in Esplora risorse `\<dominio>.local\SYSVOL`.
Quali errori DFSR/FRS cercare?	DFSR: 2213 (auto‑recupero bloccato), 4012 (in attesa inizializzazione), 4114 (SYSVOL non replicato su membro), 4602 (inizializzazione completata). FRS: 13565, 13566, 13516, 13508/13509.
Il DC è appena promosso: devo aspettare?	Sì, la initial sync può richiedere tempo e dipende dalla connettività. Ma se dopo ore/giorni vedi SYSVOL assente, applica la procedura di non‑authoritative sync.

Buone pratiche per evitare che ricapiti

Servizi in esecuzione: DFS Replication (o File Replication Service) e Netlogon in Automatico su tutti i DC.
DNS e connettività: tutti i DC devono utilizzare solo DNS interni con la zona AD‑integrata. Evita DNS pubblici sui DC.
Sincronizzazione oraria: il PDC Emulator deve puntare a una fonte NTP affidabile; gli altri DC a lui. Orari incoerenti rompono Kerberos e quindi la replica.
Monitoraggio proattivo:
- dcdiag /v – salute complessiva del DC;
- repadmin /replsummary – stato della replica AD;
- dfsrdiag ReplicationState /all – stato DFSR; dfsrdiag backlog – code di replica.
Documenta i ruoli FSMO e lo stato del PDC Emulator: netdom query fsmo.
Migra definitivamente a DFSR (se non già fatto): vedi la sezione seguente.

Migrazione definitiva da FRS a DFSR (se necessario)

Se dopo le verifiche hai accertato che SYSVOL usa ancora FRS, pianifica la migrazione in finestra di manutenzione. Requisiti: livello funzionale di dominio/foresta ≥ Windows Server 2008, tutti i DC almeno 2008 R2.

Preparazione: dfsrmig /setglobalstate 1 # Prepared dfsrmig /getmigrationstate # Attendi "consistency achieved" su tutti i DC
Redirected: dfsrmig /setglobalstate 2 dfsrmig /getmigrationstate
Eliminated: dfsrmig /setglobalstate 3 dfsrmig /getmigrationstate A fine processo, FRS non verrà più usato per SYSVOL e tutte le future correzioni seguiranno la procedura DFSR.

Checklist “pronta all’uso”

✔ Replica AD sana (repadmin /showrepl, /replsummary)
✔ DNS interni corretti su tutti i DC
✔ Secure channel OK (nltest /scquery)
✔ Identificato il motore: DFSR o FRS
✔ DFSR: eseguita non‑authoritative sync su DC‑2 (disabilita membership → 4114 → abilita → 4602)
✔ FRS: eseguiti D4 su DC‑1 e D2 su DC‑2, controllando eventi 13565/13516
✔ Presenza di gpt.ini e cartelle GPO in SYSVOL\Policies
✔ gpupdate /force senza errori e gpresult /r corretto

Appendice: comandi utili (blocchi pronti da incollare)

Replica AD & salute DC

repadmin /replsummary
repadmin /showrepl
repadmin /syncall /APeD
dcdiag /v
netdom query fsmo
nltest /scquery:<dominio>
nltest /screset:<dominio>

DFSR – diagnostica e stato

dfsrdiag PollAD
dfsrdiag ReplicationState /all
dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /smem:DC-1 /rmem:DC-2
wevtutil qe "Microsoft-Windows-DFSR/Operational" /f:text /c:50

FRS – diagnostica

wevtutil qe "File Replication Service" /f:text /c:50
ntfrsutl ds
ntfrsutl sets

Controllo condivisioni e percorsi

net share
dir C:\Windows\SYSVOL\sysvol<dominio>\Policies
dir C:\Windows\SYSVOL\sysvol<dominio>\Scripts

Forzare aggiornamento GPO

gpupdate /force
gpresult /r /scope:computer

Conclusione

Quando SYSVOL smette di replicare su un DC appena introdotto è (quasi sempre) un problema di membership DFSR sospesa, database bloccato o una migrazione FRS→DFSR incompleta. Con la verifica della replica AD, l’identificazione del motore e un non‑authoritative sync mirato, ripristini rapidamente la condivisione di SYSVOL/NETLOGON e l’applicazione dei Criteri di gruppo. Se nel tuo dominio è ancora presente FRS, sfrutta l’occasione per pianificare la migrazione a DFSR: ridurrà drasticamente la probabilità di ricadute e semplificherà i futuri troubleshooting.

Riepilogo operativo compatto

Conferma che la replica AD sia OK (repadmin, dcdiag).
Individua se SYSVOL usa DFSR o FRS (Registro o dfsrmig).
DFSR: esegui il ripristino non‑authoritative sul DC aggiuntivo (disabilita membership → Event 4114 → abilita → Event 4602).
FRS: D4 sul DC principale e D2 sul DC aggiuntivo; verifica eventi 13565 → 13516.
Controlla SYSVOL\Policies & gpt.ini, quindi gpupdate /force.

Risultato atteso: il DC aggiuntivo torna a replicare correttamente SYSVOL; i Criteri di gruppo si applicano senza errori.

Appendice: tabella di decisione rapida

Sintomo	Possibile causa	Azioni immediate	Verifica
`gpupdate` fallisce con `gpt.ini`	SYSVOL non condiviso o non replicato	Identifica DFSR/FRS, avvia procedura specifica	Presenza `SYSVOL`/`NETLOGON` in `net share`
Eventi DFSR 2213	Arresto “sporco” del database DFSR	Abilita auto‑recupero, riavvia DFSR, poi non‑authoritative sync	Eventi 4012 → 4602, backlog a 0
Eventi FRS 13508 persistenti	Connettività/DNS o partner non raggiungibile	Correggi DNS, verifica secure channel, poi D4/D2	Evento 13516 “in esecuzione correttamente”
SYSVOL vuoto su DC‑2	Membership DFSR disabilitata/inceppata	msDFSR‑Enabled → FALSE → TRUE (con PollAD)	Cartelle Policy GUID e `gpt.ini` presenti

Note operative importanti

Ordine delle operazioni: non tentare un D4/D2 se usi DFSR e viceversa. Prima identifica il motore di replica in uso.
Non cancellare manualmente file/cartelle in SYSVOL se non indicato: rischi divergenze e tombstoning.
AD è prerequisito: risolvi prima errori di replica AD (repadmin) e di DNS, poi affronta SYSVOL.
Finestra di manutenzione: per FRS e per ricostruzioni DFSR estese, pianifica una finestra con impatto comunicato.

Seguendo questo percorso, dal controllo di base alla correzione specifica (DFSR o FRS), riporti in salute la replica di SYSVOL e ristabilisci l’applicazione dei Criteri di gruppo sull’intero dominio.