GPMC : corriger l’erreur « The system cannot find the path specified » après promotion d’un contrôleur de domaine (SYSVOL/DFSR)

Après la promotion d’un nouveau contrôleur de domaine, l’ouverture de la console GPMC affiche “The system cannot find the path specified” ? Ce guide pas‑à‑pas explique les causes (SYSVOL, DFSR, réplication AD) et fournit une méthode fiable pour corriger le problème sans recréer vos GPO.

Sommaire

Vue d’ensemble de la situation

Le scénario typique est le suivant : un nouveau contrôleur de domaine (souvent titulaire du rôle PDC Emulator) a été promu, l’ancien DC a été rétrogradé puis mis hors service, et depuis, l’ouverture de Gestion des stratégies de groupe (GPMC) échoue avec l’erreur “The system cannot find the path specified”. Le même message peut apparaître lors de la modification d’un objet de stratégie de groupe (GPO) ou lors de l’accès au dossier des stratégies depuis l’Explorateur Windows.

Dans l’immense majorité des cas, la GPMC ne parvient pas à atteindre le chemin UNC attendu pour les modèles de stratégie : \\<domaine>\SYSVOL\<domaine>\Policies\<GUID>\gpt.ini. Cela pointe vers un problème de réplication SYSVOL, de DFS Replication (DFSR), ou de résolution de noms/permissions.

Arbre de décision rapide (réparation express)

La GPMC s’ouvre mais n’affiche aucun GPO → Testez \\<domaine>\SYSVOL depuis la machine locale. Si le chemin échoue : ciblez la réplication/partage SYSVOL.
Le chemin SYSVOL s’ouvre mais certains GPO manquent → Suspicion de GPO orphelins (répertoire absent) ou d’ACL corrompues.
Des erreurs DFSR/FRS dans l’Observateur d’événements → Traitez d’abord l’état DFSR : reprise de la réplication, rattrapage, migration FRS→DFSR si applicable.
Après retrait de l’ancien DC → Vérifiez metadata cleanup, DNS et enregistrements SRV, puis forcez la réplication AD.

Causes probables et mécanismes sous-jacents

Piste	Explication
SYSVOL/NETLOGON indisponibles	Si la réplication n’a pas encore créé les partages SYSVOL et NETLOGON sur le nouveau DC, la console ne trouve pas les chemins `\\<domaine>\SYSVOL\…` nécessaires.
Réplication Active Directory incomplète	La rétrogradation de l’ancien DC peut laisser des objets orphelins ou des références à l’ancien serveur dans la partition Configuration, empêchant la convergence des informations de site/serveur.
Échec ou retard FRS/DFSR	Sur les versions récentes de Windows Server, SYSVOL doit être répliqué par DFSR, mais un ancien DC pouvait encore utiliser FRS. Un état « Preparing », « Initializing », « Auto Recovery Disabled » ou « Disabled » bloque l’accès cohérent aux GPO.
Permissions/ACL ou namespace DFS corrompus	Des ACL incorrectes ou un namespace DFS mal répliqué entraînent une recherche infructueuse du fichier `gpt.ini` de chaque GPO.
DNS/SRV non à jour	Des enregistrements SRV (`_ldap._tcp.dc._msdcs`) obsolètes vers l’ancien DC ou un client connecté au mauvais site AD (nltest) mènent à un chemin SYSVOL inaccessible.
Heure/Kerberos	Un décalage d’horloge > 5 minutes entre machine et DC peut fausser l’authentification SMB ; l’accès au partage SYSVOL échoue et la GPMC renvoie le message « path specified ».
Filtrage SMB/antivirus	Des politiques de sécurité, un pare‑feu ou un antivirus verrouillant `%systemroot%\SYSVOL` ou le port 445 peuvent provoquer des “chemins introuvables” intermitents.

Diagnostic détaillé (séquence recommandée)

Vérifier la réplication Active Directory

Commencez par vérifier la santé globale de la réplication entre les contrôleurs de domaine. Relevez les échecs et les latences, puis forcez une synchronisation si nécessaire.

repadmin /showrepl             # États de réplication sur le DC local
repadmin /replsum              # Résumé des échecs et retards
repadmin /syncall /APeD        # Réplication forcée tous partenaires/toutes partitions

Interprétez les résultats : un retard > 15 minutes (ou des échecs répétés) indique une anomalie sous‑jacente à résoudre avant tout.

Contrôler la santé du DC

Un diagnostic approfondi des rôles, des services NetLogon/DFSR et de la configuration DNS vous donnera des indices immédiats.

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

Parcourez C:\dcdiag.txt à la recherche de sections contenant FrsEvent, DfsrEvent, SysVolReady et NetLogon. Les rôles FSMO doivent être identifiés correctement, en particulier le rôle PDC Emulator (important pour GPMC et mot de passe).

Valider la présence des partages SYSVOL/NETLOGON

Sur le nouveau DC (idéalement le PDC), vérifiez que les partages sont publiés et pointent au bon endroit.

net share
# Les partages SYSVOL et NETLOGON doivent exister et viser %systemroot%\SYSVOL\sysvol et %systemroot%\SYSVOL\sysvol\&lt;domaine&gt;\scripts

Si un des partages est manquant, relancez la réplication DFSR ou le service concerné :

net stop dfsr
net start dfsr
# Ou via Services.msc : redémarrer "DFS Replication"

Examiner l’état DFSR / (FRS le cas échéant)

Déterminez si SYSVOL est géré par DFSR (recommandé) ou FRS (héritage). Ensuite, inspectez l’état de la réplication et le backlog.

dfsrdiag pollad
dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /smem:&lt;DC_source&gt; /rmem:&lt;DC_cible&gt;
dfsrdiag replicationstate

Événements courants indiquant un blocage : DFSR 2213 (Auto-Recovery disabled), 4012/4002 (retard ou initialisation), FRS 13508/13568 (connexion ou journal USN).

Valider DNS/SRV et Netlogon

Confirmez que les enregistrements SRV pointent vers des DC valides et que le poste choisit le bon site AD.

ipconfig /all
nslookup -type=SRV _ldap._tcp.dc._msdcs.&lt;domaine&gt;
nltest /dclist:&lt;domaine&gt;
nltest /dsgetsite
nltest /dsregdns

Si vous voyez encore l’ancien DC dans les SRV : patientez le temps de réplication ou déclenchez l’enregistrement dynamique via nltest /dsregdns sur les DC restants.

Tester depuis un poste client

Vérifiez que le chemin UNC vers les stratégies est accessible en SMB depuis un poste standard :

\\&lt;domaine&gt;\SYSVOL\&lt;domaine&gt;\Policies

Si l’explorateur ouvre le chemin sans erreur et que vous voyez les sous‑dossiers {GUID}, la partie « chemin » est rétablie. Poursuivez avec la validation GPO.

Corrections ciblées

Relancer et réparer la réplication DFSR

Quand DFSR est bloqué (p. ex. après un arrêt brutal), l’événement 2213 impose une reprise explicite. Les commandes suivantes relancent la synchronisation :

# Sur chaque DC impacté (exécuter en tant qu’administrateur)
wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="<GUID_volume>" call ResumeReplication

# Relire la config AD et rafraîchir la topologie

dfsrdiag pollad
repadmin /syncall /APeD

Vérifiez ensuite le backlog jusqu’à retour à 0. Tant que le backlog n’est pas à 0, certains GPO peuvent rester inaccessibles.

Rétablir les partages SYSVOL/NETLOGON

Si net share ne liste pas SYSVOL/NETLOGON, contrôlez la clé d’état SYSVOL et la valeur SysVolReady. Un redémarrage du service DFSR après résolution du backlog recrée souvent les partages de manière automatique.

Get-SmbShare | Where-Object Name -in @("SYSVOL","NETLOGON")

Lorsque les partages réapparaissent, validez immédiatement l’accès depuis un poste client.

Nettoyer les métadonnées de l’ancien DC

Si la rétrogradation de l’ancien DC n’a pas été propre (panne matérielle, déconnexion réseau), certaines références persistent. Procédez au « metadata cleanup », puis forcez la réplication.

ntdsutil
metadata cleanup
# (suivre les invites pour supprimer le DC orphelin de la configuration du site et des services)
repadmin /syncall /APeD

Après nettoyage, vérifiez que l’ancien DC n’apparaît plus dans la liste des DC (nltest /dclist) et que les SRV ne le référencent plus.

Migrer FRS vers DFSR (si encore en FRS)

Si votre environnement tournait encore avec FRS pour SYSVOL, migrez vers DFSR. Les états de migration : 0 (Start), 1 (Prepared), 2 (Redirected), 3 (Eliminated).

dfsrmig /setglobalstate 3
dfsrmig /getmigrationstate

Attendez “Global state achieved” avant de continuer. Durant la phase, évitez les changements massifs de GPO.

Réparer les GPO orphelins ou incohérents

Un GPO valide comporte toujours un objet AD (dans la partition Domain) et un dossier de modèle (GPT) dans SYSVOL. Lorsqu’un GUID existe d’un côté mais pas de l’autre, GPMC peut échouer ou masquer le GPO.

# Audit : rapprocher l’AD (GPC) et le SYSVOL (GPT)
gpotool /verbose

Si gpotool n’est pas disponible, utilisez PowerShell :

$domain = (Get-ADDomain).DNSRoot
$gpos   = Get-GPO -All
$missing = foreach ($g in $gpos) {
  $p = "\\$domain\SYSVOL\$domain\Policies\{$($g.Id)}\gpt.ini"
  if (-not (Test-Path $p)) { [PSCustomObject]@{DisplayName=$g.DisplayName; Id=$g.Id; Path=$p} }
}
$missing | Format-Table -Auto

Pour les GPO orphelins côté AD (GPC sans GPT), restaurez depuis une sauvegarde (Restore-GPO) ou recréez le GPO. Pour les GPT orphelins (dossier présent sans objet AD), supprimez le dossier après vérification et sauvegarde.

Corriger les ACL de SYSVOL (si nécessaires)

Des ACL trop restrictives sur SYSVOL empêchent de lire gpt.ini. En règle générale, les groupes Authenticated Users doivent disposer d’un accès lecture, et les administrateurs du domaine d’un accès complet. Évitez les modifications hasardeuses : préférez réappliquer les ACL par héritage à partir des modèles par défaut si vous les avez exportées, ou répliquer depuis un DC sain (DFSR se chargera d’aligner les ACL NTFS).

Jeu d’outils : commandes utiles et exemples

Objectif	Commande	Interprétation
État réplication AD	`repadmin /replsum`	Échecs=0, retards faibles attendus. Sinon, corriger avant la couche GPO.
Forcer synchro AD	`repadmin /syncall /APeD`	Propulse la convergence ; surveillez l’Observateur d’événements.
Santé DC	`dcdiag /v`	Sections Netlogon/DFSR/SYSVOL doivent être OK.
Partages SYSVOL	`net share`	Présence obligatoire de SYSVOL et NETLOGON.
Backlog DFSR	`dfsrdiag backlog ...`	Retour à 0 nécessaire pour la cohérence GPO.
État migration DFSR	`dfsrmig /getmigrationstate`	Doit afficher Global state achieved à l’état 3.
DNS SRV	`nslookup -type=SRV _ldap._tcp.dc._msdcs.<domaine>`	Ne doit pas référencer un DC supprimé.
Site AD du poste	`nltest /dsgetsite`	Doit correspondre au site attendu pour la latence la plus faible.
Tester GPO côté client	`gpupdate /force` et `gpresult /r`	Confirme l’application des GPO et l’absence d’erreurs.

Tableau des événements fréquents à surveiller

Source	ID	Symptôme	Action recommandée
DFSR	2213	Récupération automatique désactivée	Reprendre manuellement la réplication (WMIC / ResumeReplication), puis `dfsrdiag pollad`.
DFSR	4012/4002	Initialisation/retard de réplication	Vérifier connectivité, backlog, topologie AD, espace disque, antivirus.
FRS	13508/13568	Connexion perdue / journal USN	Évaluer migration vers DFSR ; sinon corriger la réplication FRS.
GroupPolicy	1058/1030	Échec d’accès à `gpt.ini`	Contrôler `\\<domaine>\SYSVOL`, DNS/SRV, ACL et réplication DFSR.
Netlogon	5719	Échec d’établissement d’une connexion sécurisée	Vérifier réseau, DNS, horloge/NT5DS, droits d’ordinateur.
SceCli	1202	Échec de traitement de la stratégie	Souvent lié à un GPO introuvable ou à des ACL insuffisantes.

Procédure complète : du diagnostic à la correction

Stabiliser AD : corriger tous les échecs repadmin. Sans AD convergent, SYSVOL divergera.
Vérifier DFSR : reprendre la réplication si 2213, s’assurer que le backlog retombe à 0.
Confirmer SYSVOL : présence des partages sur chaque DC, accès depuis un poste non‑administrateur.
Assainir les métadonnées : supprimer toute trace de l’ancien DC (ntdsutil), actualiser SRV et sites.
Nettoyer les GPO orphelins : aligner GPT/GPC, restaurer depuis sauvegarde si nécessaire.
Tester GPMC : ouvrir la console, basculer vers le DC souhaité (Change Domain Controller), modifier un GPO de test.
Valider côté client : gpupdate /force, puis gpresult /r. Contrôler l’absence d’erreurs 1058/1030.

Scripts prêts à l’emploi

Audit express de cohérence GPO (PowerShell)

Import-Module GroupPolicy, ActiveDirectory
$domain = (Get-ADDomain).DNSRoot
$gpos = Get-GPO -All
$result = foreach ($g in $gpos) {
  $gpt = "\\$domain\SYSVOL\$domain\Policies\{$($g.Id)}\gpt.ini"
  [PSCustomObject]@{
    DisplayName = $g.DisplayName
    Id          = $g.Id
    HasGPT      = Test-Path $gpt
    Path        = $gpt
  }
}
$result | Sort-Object HasGPT, DisplayName | Format-Table -Auto

Mini‑bilan AD/DFSR

repadmin /replsum
dfsrdiag replicationstate
dfsrmig /getmigrationstate

Cas particuliers et pièges

Plusieurs sites AD, liaisons lentes : la GPMC ouverte depuis un site « lent » peut interroger un DC sans SYSVOL prêt. Forcez la console à utiliser un DC précis (menu GPMC → Modifier le contrôleur de domaine).
Antivirus avec analyse en temps réel sur SYSVOL : excluez %systemroot%\SYSVOL (lecture/écriture) selon vos politiques de sécurité.
SMB durci : certaines durcissements (signing, NTLM désactivé) peuvent bloquer l’accès SYSVOL pour d’anciennes machines. Assurez une compatibilité minimale ou mettez à jour les postes.
Autorisations de sécurité : ne remplacez pas les ACL de SYSVOL à l’aveugle ; préférez un DC de référence sain et laissez DFSR propager.
Restauration d’urgence : évitez les restaurations « authoritative » DFSR sans procédure. Un mauvais marquage peut entraîner une divergence durable des GPO.

Validation finale (critères d’acceptation)

repadmin : échecs = 0, latence raisonnable.
dfsrdiag backlog : 0 sur tous les couples DC.
Partages : SYSVOL et NETLOGON présents sur tous les DC actifs.
GPMC : s’ouvre sans message d’erreur, liste les GPO, permet l’édition/sauvegarde.
Client : gpupdate /force réussi, pas d’événements 1058/1030/1202.

Check‑list de prévention (avant de retirer un DC)

Au moins deux DC opérationnels et répliqués (vérifier repadmin /replsum).
Migration SYSVOL en DFSR finalisée (dfsrmig /getmigrationstate = 3).
Partages SYSVOL/NETLOGON présents et accessibles depuis un poste client.
DNS/SRV propres : pas d’entrées obsolètes vers l’ancien DC.
Sauvegarde récente de l’état système et Backup-GPO des stratégies critiques.
Surveillance planifiée : journal DFSR, alerte sur backlog, tâche de contrôle gpresult hebdomadaire.

FAQ

Pourquoi l’erreur apparaît‑elle uniquement sur certaines machines ?
Parce que ces machines résolvent le domaine vers un DC différent (sites AD, DNS, cache SRV) ou subissent un décalage horaire/pare‑feu. Vérifiez nltest /dsgetsite et l’accessibilité SMB.

Peut‑on forcer la GPMC à utiliser un DC donné ?
Oui. Dans GPMC, clic droit sur le domaine → Modifier le contrôleur de domaine et sélectionnez un DC sain (idéalement celui avec SYSVOL confirmé).

Faut‑il recréer tous les GPO ?
Non. Dans la plupart des cas, la résolution passe par la réparation réplication/partages/permissions. On ne recrée un GPO qu’en dernier recours et avec sauvegarde préalable.

Combien de temps attendre après correction ?
Le temps de convergence dépend du nombre de DC/sites et de la taille de SYSVOL. Contrôlez objectivement avec repadmin et dfsrdiag backlog plutôt que d’attendre « à l’aveugle ».

Exemples de diagnostics et commandes (récapitulatif)

# 1) Réplication AD
repadmin /replsum
repadmin /showrepl

# 2) Santé DC et services

dcdiag /v

# 3) Partages SYSVOL/NETLOGON

net share

# 4) DFSR

dfsrdiag replicationstate
dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /smem: /rmem:

# 5) Migration FRS→DFSR (si FRS encore présent)

dfsrmig /setglobalstate 3
dfsrmig /getmigrationstate

# 6) GPO orphelins

gpotool /verbose

# 7) Tests côté client

\\SYSVOL<domaine>\Policies
gpupdate /force
gpresult /r

Conclusion

L’erreur “The system cannot find the path specified” dans la GPMC n’est presque jamais un mystère : elle reflète un chaînon manquant entre AD et SYSVOL. En appliquant la séquence diagnostic → nettoyage → réplication décrite ci‑dessus — repadmin propre, DFSR à jour, partages SYSVOL/NETLOGON présents, GPO alignés — vous rétablissez l’accès sans devoir reconstruire vos stratégies. Conservez au moins deux DC, surveillez la réplication et sauvegardez régulièrement l’état système : ces bonnes pratiques rendent ce type d’incident bien plus rare… et beaucoup plus rapide à corriger.

Annexe : pas-à-pas détaillé proposé

Sur le nouveau DC : repadmin /replsum → corriger tout échec réseau/DNS.
DFSR 2213 ? : ResumeReplication via WMIC, puis dfsrdiag pollad.
Backlog > 0 : patienter et surveiller jusqu’à 0, investiguer antivirus/pare‑feu si ça stagne.
Partages absents : redémarrer le service DFSR, vérifier SysVolReady.
DNS/SRV : nettoyer références à l’ancien DC, nltest /dsregdns sur les DC actifs.
Metadata cleanup : supprimer l’ancien DC via ntdsutil si la rétrogradation a échoué.
GPO : auditer les GUID orphelins, restaurer ou supprimer les entrées incohérentes.
Valider : ouvrir GPMC, modifier un GPO de test, exécuter gpupdate sur un poste.