gpupdate échoue, SYSVOL/NETLOGON absents sur un second contrôleur de domaine : diagnostic et réparation DFSR/FRS

gpupdate échoue et les partages SYSVOL/NETLOGON ont disparu sur un deuxième contrôleur de domaine ? Voici une procédure pas‑à‑pas, concrète et vérifiable, pour diagnostiquer la réplication, distinguer DFSR de FRS, et rétablir un SYSVOL complet et fonctionnel.

Sommaire

Symptômes et contexte

Forêt et domaine uniques, deux contrôleurs de domaine (DC). Le DC principal (migré de 2008 R2 vers Windows Server 2016) fonctionne, un DC additionnel a d’abord répliqué puis a cessé de le faire.
gpupdate échoue avec l’erreur : impossible de lire \\<domaine>\sysvol\<domaine>\Policies\{6AC1786C-016F-11D2-945F-00C04FB984F9}\gpt.ini — ce GUID correspond à la Default Domain Controllers Policy.
Sur le DC additionnel, les partages SYSVOL et NETLOGON ont disparu, puis réapparaissent après un forçage côté Netlogon, mais le dossier Policies est vide.
L’accès à \\192.168.1.1\SYSVOL depuis ce DC déclenche une demande d’identifiants.

Diagnostic éclair

Avant toute réparation, validez la santé d’Active Directory, du DNS et du temps, car toute incohérence ici bloque la réplication SYSVOL.

Vérification	Commande	Résultat attendu	Action si KO
Etat réplication AD	`repadmin /replsum`	Erreurs < 0, retards faibles	Corriger la réplication (DNS, réseau, sites/liaisons)
Détails par partenaire	`repadmin /showrepl * /csv > C:\repsum.csv`	Succès sur tous les naming contexts	Identifier le DC fautif et l’orientation
Diagnostic DC	`dcdiag /e /v > C:\dcdiag.txt`	Advertising & SysVolCheck OK	Corriger tests échoués (DNS, Netlogon, KDC)
Advertising & SYSVOL	`dcdiag /test:Advertising /test:SysVolCheck`	OK	Si SysVolCheck échoue, passer aux réparations SYSVOL
Enregistrements SRV	`nslookup -type=srv _ldap._tcp.dc._msdcs.<domaine>`	Tous les DC listés	Corriger l’inscription DNS des DC
Sources DNS sur DC	Interface réseau → IPv4 DNS	Uniquement des DNS AD (DC de la forêt)	Supprimer DNS publics sur les cartes des DC
Temps/Kerberos	`w32tm /query /status` puis `w32tm /resync`	Écart < 5 min	Corriger NTP, source de temps PDC, pare‑feu UDP 123

Vérifier la santé AD et la réplication

Exécutez ces commandes depuis le DC détenteur du rôle PDC Emulator (ou un DC sain) :

repadmin /replsum
repadmin /showrepl * /csv &gt; C:\repsum.csv
dcdiag /e /v &gt; C:\dcdiag.txt
dcdiag /test:Advertising /test:SysVolCheck

Analysez :

Naming contexts en erreur (Schema, Configuration, Domain, DNS zones) ;
Partenaires en backlog ou injoignables ;
Événements Netlogon/KDC/DNS dans l’Observateur d’événements.

Identifier le moteur de réplication de SYSVOL

Selon votre historique, SYSVOL peut être répliqué par FRS (ancien) ou DFSR (recommandé). La procédure de réparation diffère.

reg query "HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols" /v LocalState

Résultat	Interprétation	Action
Valeur `LocalState` = `3` (ELIMINATED)	SYSVOL est en DFSR	Suivre la réparation non‑autorisative DFSR ci‑dessous
Clé absente ou autre valeur	SYSVOL utilise encore FRS	Suivre la réparation FRS (D2/D4) puis planifier une migration vers DFSR

Vous pouvez aussi interroger l’état global SYSVOL :

dfsrmig /getglobalstate
dfsrmig /getmigrationstate

Réparer SYSVOL sur le DC affecté en DFSR (resynchronisation non‑autorisative)

Objectif : faire re‑télécharger au DC problématique le contenu de C:\Windows\SYSVOL\domain depuis le DC sain, sans impacter le DC de référence.

Pré‑requis et garde‑fous

Disposer d’une sauvegarde (ou snapshot) du DC affecté.
Confirmer que la réplication AD (Active Directory) est saine entre les DC.
Vérifier l’espace disque et l’intégrité NTFS (droits hérités par défaut).
Ne pas forcer SysVolReady=1 : cela masque le problème et publie un SYSVOL vide.

Arrêter la réplication DFSR sur le DC affecté :
net stop dfsr
Désactiver l’abonnement SYSVOL de ce DC via ADSI Edit :
- Ouvrir adsiedit.msc → Configuration → CN=Services → CN=DFSR-GlobalSettings → CN=Domain System Volume → CN=Topology → CN=<NomDC> → CN=Content → CN=SYSVOL Subscription.
- Passer l’attribut msDFSR-Enabled à FALSE.
Renommer le contenu local pour forcer une resynchronisation complète :
ren "C:\Windows\SYSVOL\domain" domain.old
Réactiver l’abonnement (toujours via ADSI Edit) : msDFSR-Enabled=TRUE.
Redémarrer DFSR et demander un poll AD :
net start dfsr dfsrdiag pollad
Surveiller les évènements DFSR :
- 4614 : SYSVOL est en phase de remontée (initializing).
- 4602 : initialisation terminée, SYSVOL prêt.
- Vérifier aussi l’absence de 2213 (arrêt dû au journal USN) et 4012 (attente de synchronisation initiale).
Valider les partages :
net share Les partages SYSVOL et NETLOGON doivent s’afficher. Le dossier C:\Windows\SYSVOL\domain\Policies doit contenir les GUID, notamment {6AC1786C-016F-11D2-945F-00C04FB984F9}.

Alternative PowerShell (contrôles)

# Lister l'état de réplication DFSR (nécessite RSAT)
dfsrdiag replicationstate

# Compter les GPO et repérer ceux manquants localement

Import-Module GroupPolicy
(Get-GPO -All).Count
(Get-GPO -All | Select-Object -ExpandProperty Id)

Réparer SYSVOL en FRS (D2/D4) si l’environnement n’est pas encore migré

Si votre domaine utilise encore FRS, réalisez une restauration non‑autorisée (D2) sur le DC vide pour qu’il se resynchronise depuis un partenaire sain. Si nécessaire, effectuez une restauration autoritative (D4) sur le DC de référence (celui qui possède un SYSVOL complet et à jour).

Type	Clé/valeur	Effet	Quand l’utiliser
Non‑autorisée (D2)	`HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore/Process at Startup\BurFlags=0x000000D2`	Le DC consomme la base FRS depuis ses partenaires	Sur le DC affecté (SYSVOL vide)
Autorisée (D4)	`HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore/Process at Startup\BurFlags=0x000000D4`	Le DC pousse son contenu comme source autoritative	Sur le DC sain si aucun autre partenaire ne peut servir de référence

Procédure résumée FRS :

Sur le DC affecté : arrêter NtFrs, positionner BurFlags=D2, démarrer NtFrs.
Si aucun partenaire ne peut fournir un SYSVOL correct : sur le DC sain, utiliser BurFlags=D4 (puis remettre la valeur par défaut après stabilisation).
Surveiller les journaux FRS et vérifier la reconstitution de SYSVOL\Policies.

Important : FRS est obsolète. Planifiez la migration vers DFSR (dfsrmig) dès que possible.

Contrôles post‑réparation

gpupdate /force
gpresult /h C:\GPReport.html
dfsrdiag replicationstate

Les évènements 1058/1030 (Stratégie de groupe) doivent cesser.
Depuis tous les DC et postes membres : accès lisible à \\<domaine>\SYSVOL\<domaine>\Policies\{6AC1786C-...}\gpt.ini.
Les GPO s’appliquent à nouveau ; le rapport GPReport.html doit montrer les GPO requis sans erreurs d’accès.

Pourquoi l’accès `\\IP\SYSVOL` demande des identifiants

L’accès par adresse IP contourne Kerberos (absence de SPN pour l’IP) et force une négociation NTLM, d’où la demande d’identifiants. Utilisez toujours un nom :

\\<domaine.fqdn>\SYSVOL (chemin DFS recommandé), ou
\\<NomDC>\SYSVOL (résolution DNS correcte requise).

Chemin	Authentification	Comportement	Remède
`\\IP\SYSVOL`	NTLM	Invite d’identifiants possible, échec Kerberos	Utiliser le FQDN du domaine ou le nom du DC
`\\<domaine.fqdn>\SYSVOL`	Kerberos	Accès transparent si horloge et SPN OK	Assurer DNS, temps et SPN Netlogon corrects
`\\<NomDC>\SYSVOL`	Kerberos	Accès direct au DC ciblé	Résolution A/AAAA et enregistrements SRV fonctionnels

Points à valider également :

Client DFS actif : la valeur HKLM\SYSTEM\CurrentControlSet\Services\Mup\DisableDFS doit être 0 (ou absente).
Horloge synchronisée (sinon Kerberos échoue).
Droits par défaut sur les DC : la Default Domain Controllers Policy accorde « Accéder à cet ordinateur depuis le réseau » aux Authenticated Users.
Pare‑feu : activer File and Printer Sharing et le trafic AD/DFSR.

Erreurs et évènements utiles à interpréter

Source	ID	Signification	Action
GroupPolicy	1058 / 1030	Lecture GPO impossible (souvent SYSVOL inaccessible)	Réparer SYSVOL/DFSR, vérifier DNS/temps
DFSR	2213	Service bloqué suite à journal USN	Réparer USN, autoriser la reprise, surveiller le backlog
DFSR	4012	Attente de synchronisation initiale	Vérifier connectivité/AD, patienter jusqu’à 4602
DFSR	4614	SYSVOL en cours d’initialisation	OK, attendre la fin de l’initialisation
DFSR	4602	Initialisation SYSVOL terminée	Contrôles post‑réparation
Netlogon	5719 / 5783	Problèmes d’établissement de session sécurisée	DNS/temps/réseau, SPN et canaux sécurisés

Bonnes pratiques pour éviter la rechute

DNS des DC : configurez uniquement des DNS AD sur les interfaces des contrôleurs de domaine (lui‑même et/ou l’autre DC). Pour Internet, utilisez des Redirecteurs dans le rôle DNS AD plutôt que des DNS publics sur les cartes réseau.
Temps : source unique et fiable (PDC Emulator pointe vers une source NTP externe approuvée, les autres DC/clients se synchronisent hiérarchiquement).
Surveillance : alertez sur les évènements DFSR (2213, 4012) et la santé repadmin. Exportez périodiquement dcdiag et comparez.
Migration FRS → DFSR : si FRS est encore présent, planifiez dfsrmig (préparation, redirection, élimination) avec fenêtres de maintenance et sauvegardes.
Sites et services AD : définissez correctement les sous‑réseaux et liaisons pour éviter des chemins de réplication exotiques.
Sauvegardes : testez la restauration SYSVOL et la restauration AD authoritative/non‑authoritative.

Procédures détaillées pas‑à‑pas

Contrôle des dépendances réseau et DNS

# Sur chaque DC
ipconfig /all
ipconfig /flushdns
nltest /dsgetdc:&lt;domaine&gt;
nltest /dclist:&lt;domaine&gt;
nslookup -type=SRV _kerberos._tcp.dc._msdcs.&lt;domaine&gt;

Contrôle Kerberos et temps

w32tm /query /status
w32tm /query /peers
w32tm /config /update
w32tm /resync
klist purge

Validation SYSVOL/NETLOGON publiés

net share
dir "C:\Windows\SYSVOL\domain\Policies"
icacls "C:\Windows\SYSVOL\domain\Policies\{6AC1786C-016F-11D2-945F-00C04FB984F9}" /verify

Contrôle de cohérence des GPO

gpupdate /force
gpresult /r
gpresult /h "C:\GPReport.html"

Notes d’ingénierie

Le GUID {6AC1786C-016F-11D2-945F-00C04FB984F9} est la Default Domain Controllers Policy. Son absence dans SYSVOL\Policies révèle une rupture de réplication SYSVOL.
Sur des environnements récemment upgradés, il est fréquent que DFSR soit en place sur le DC 2016, alors que des traces historiques FRS subsistent : vérifiez soigneusement l’état de migration (dfsrmig).
Forcer la ré‑apparition des partages par SysVolReady ou par trucage Netlogon n’est pas une solution : vous publiez un partage vide qui casse les GPO.

Plan d’action synthétique

Corriger DNS/temps/réseau si nécessaire.
Contrôler AD (repadmin, dcdiag).
Identifier le moteur SYSVOL (DFSR ou FRS).
Resynchroniser SYSVOL sur le DC vide : non‑autorisative DFSR ou FRS D2 (et D4 sur le DC de référence si vraiment indispensable).
Valider la présence des dossiers Policies et des partages SYSVOL/NETLOGON.
Tester gpupdate et l’accès via \\<domaine>\SYSVOL.

FAQ rapide

Faut‑il exécuter la réparation DFSR sur tous les DC ?
Non. Exécutez la resynchronisation non‑autorisative uniquement sur le DC affecté, après avoir confirmé qu’au moins un DC possède un SYSVOL complet et à jour.

Puis‑je purger manuellement le dossier Policies ?
Évitez toute suppression manuelle. Renommez le dossier local (domain → domain.old) pour forcer la resynchronisation ; laissez DFSR ou FRS reconstruire le contenu.

Pourquoi gpupdate échoue encore après la réparation ?
Vérifiez la latence de réplication AD, les caches DFS/SMB côté client (klist purge, ipconfig /flushdns), et la résolution du chemin DFS \\<domaine>\SYSVOL. Assurez‑vous que la Default Domain Controllers Policy est lisible.

Accéder à \\IP\SYSVOL peut‑il fonctionner ?
Oui, mais cela utilise NTLM et peut déclencher des invites, voire échouer selon les politiques. Préférez le FQDN et Kerberos pour des accès stables et sécurisés.

Exemple de session de remise en service (DFSR)

:: Sur DC affecté
net stop dfsr

\:: ADSI Edit > msDFSR-Enabled = FALSE (SYSVOL Subscription)
ren "C:\Windows\SYSVOL\domain" domain.old

\:: ADSI Edit > msDFSR-Enabled = TRUE
net start dfsr
dfsrdiag pollad

\:: Surveiller l'Observateur d'événements > DFS Replication
\:: Attendre 4614 puis 4602

net share
dir "C:\Windows\SYSVOL\domain\Policies"
gpupdate /force
gpresult /h C:\GPReport.html

Checklist finale de validation

Point	OK	KO → Action
`repadmin /replsum` sans erreurs bloquantes	✔︎	Corriger DNS/réseau/sites
`dcdiag` Advertising & SysVolCheck OK	✔︎	Réparer Netlogon/KDC/DNS
SYSVOL et NETLOGON visibles dans `net share`	✔︎	Relancer réparation DFSR/FRS
`Policies` contient les GUID (dont `{6AC1786C-...}`)	✔︎	Vérifier réplication DFSR/FRS
Accès `\\<domaine>\SYSVOL` sans invite	✔︎	Corriger Kerberos, temps, DNS
`gpupdate /force` et rapport `GPReport.html` OK	✔︎	Analyser GPO défectueuses, droits NTFS

Récapitulatif essentiel

Un gpupdate qui échoue avec un gpt.ini introuvable sur la Default Domain Controllers Policy, couplé à des partages SYSVOL/NETLOGON absents ou vides, signe une rupture de réplication SYSVOL. Éliminez d’abord les causes racines (DNS, temps, réseau, réplication AD). Identifiez ensuite le moteur de réplication (DFSR ou FRS) et appliquez la bonne stratégie : resynchronisation non‑autorisative DFSR sur le DC « vide », ou restauration FRS D2 (et D4 sur la source de vérité si indispensable). Ne forcez pas SysVolReady. Terminez par des contrôles outillés (repadmin, dcdiag, dfsrdiag, gpresult) et par des tests d’accès via le chemin DFS \\<domaine>\SYSVOL. Enfin, prévenez la récidive en verrouillant la configuration DNS/NTP et, si besoin, en migrant définitivement vers DFSR.

Rappel : l’accès \\IP\SYSVOL déclenche souvent NTLM et des invites. Utilisez le nom DNS du domaine ou du DC pour rester en Kerberos et éviter les surprises.