Réparer une réplication SYSVOL DFSR bloquée entre contrôleurs de domaine

par | Sep 28, 2025 | AdminSys

La réplication SYSVOL est un composant critique d’Active Directory : elle assure la disponibilité des stratégies de groupe (GPO) et des scripts sur l’ensemble des contrôleurs de domaine (DC). Dans un environnement multi-DC, tout décalage ou blocage de DFSR peut provoquer des incohérences graves (GPO absentes, versions différentes, erreurs de sécurité).

Récemment, nous avons rencontré un cas complexe où la réplication DFSR de SYSVOL était bloquée sans erreurs visibles dans l’Observateur d’événements, mais avec des incohérences majeures entre DC. Voici comment nous avons diagnostiqué et corrigé le problème.

Symptômes rencontrés

  • Les GPO apparaissaient bien dans la console GPMC (partie AD répliquée),
  • mais le contenu du dossier SYSVOL n’était pas identique selon les DC.
  • Les événements DFSR montraient uniquement des erreurs 5002 (1753 – aucun point de terminaison disponible) et 4612 (en attente d’une réplication initiale).
  • Le backlog restait figé (plus de 1000 fichiers en attente).

En clair : Active Directory répliquait correctement les métadonnées des GPO, mais DFSR n’arrivait jamais à aligner les fichiers SYSVOL.

Causes possibles

Plusieurs facteurs peuvent provoquer ce blocage :

  • Problèmes RPC (port dynamique non accessible, firewall trop restrictif).
  • Base DFSR locale corrompue sur un ou plusieurs DC.
  • Abandon d’une réplication initiale (événement 4612 non résolu).
  • Environnements hétérogènes (Windows Server 2019, 2022, 2025) où DFSR se montre plus strict.

Prérequis avant intervention

⚠️ Attention : la manipulation est intrusive. Si elle est mal réalisée, elle peut mener à la perte de l’ensemble du SYSVOL.

Avant toute action, nous avons effectué :

  • Plusieurs sauvegardes complètes du dossier SYSVOL_DFSR du DC principal.
  • Snapshots/Checkpoints des VM DC.
  • Export des GPO via GPMC (fonction de sauvegarde intégrée).

Méthode de résolution

La solution a consisté à réinitialiser proprement DFSR via ADSIEdit, en désignant un contrôleur de domaine comme “référence” (authoritative), et en forçant les autres à se resynchroniser (non-authoritative).

Étape 1 : Identifier le DC maître

Nous avons choisi le DC contenant la copie SYSVOL la plus complète et à jour (appelons-le DC-Maître).

Étape 2 : Désactiver DFSR

Sur tous les DC :

net stop dfsr

Étape 3 : Modifier les attributs ADSI

Via ADSIEdit, sur chaque DC, chemin :

CN=SYSVOL Subscription,
CN=Domain System Volume,
CN=DFSR-LocalSettings,
CN=<Nom_DC>,
OU=Domain Controllers,
DC=<domaine>
  • Sur le DC-Maître :
    • msDFSR-Options = 1 (authoritative)
    • msDFSR-Enabled = FALSE
  • Sur les autres DC :
    • msDFSR-Options = 0
    • msDFSR-Enabled = FALSE (non-authoritative par défaut)

Étape 4 : Réactiver le DC-Maître

  • Redémarrer DFSR sur le DC-Maître.
  • Repasser msDFSR-Enabled = TRUE.
  • Forcer la réplication AD : repadmin /syncall /AdeP dfsrdiag pollad
  • Observer l’event 4604/4602 : SYSVOL authoritative prêt.

Étape 5 : Réactiver les autres DC

  • Sur chaque autre DC :
    • Remettre msDFSR-Enabled = TRUE.
    • Redémarrer DFSR et exécuter dfsrdiag pollad.
  • Observer les events 4114 → 4614 → 4602 confirmant la resynchronisation.

Étape 6 : Vérification

  • Contrôler que \\<DC>\SYSVOL\<domaine>\Policies est identique partout.
  • Vérifier dans GPMC que l’état de réplication des GPO est synchronisé.
  • Exécuter un test de propagation DFSR si besoin : dfsrdiag propagationtest /rgname:"Domain System Volume" /rfname:"SYSVOL Share" dfsrdiag propagationreport /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /report:C:\DFSR-Report.html

Résultat

Après réactivation :

  • Tous les DC ont reçu une copie identique du SYSVOL depuis le DC-Maître.
  • Les événements 4602 ont confirmé l’initialisation réussie.
  • Les GPO sont redevenues cohérentes sur l’ensemble du domaine.

Leçons apprises

  1. Ne jamais copier-coller manuellement le SYSVOL d’un DC à l’autre → DFSR ne le reconnaît pas, et cela génère des conflits.
  2. Toujours vérifier la connectivité RPC avant de conclure à une corruption DFSR (ports dynamiques ou port statique forcé).
  3. Sauvegardes obligatoires (checkpoints, exports GPO, copie du SYSVOL) avant manipulation.
  4. Surveiller les bons événements :
    • 4114 → arrêt journalisation
    • 4614 → reprise
    • 4602 → SYSVOL prêt

⚠️ Mises en garde

  • Cette procédure n’est pas anodine : elle modifie la topologie DFSR dans Active Directory.
  • Toute erreur (désigner plusieurs DC comme authoritative, oublier une étape) peut causer la perte totale du SYSVOL.
  • Toujours effectuer ces opérations en maintenance planifiée et avec sauvegardes testées.

Conclusion

Dans notre cas, la réplication SYSVOL DFSR était bloquée sans erreur explicite, et seule une réinitialisation via ADSI a permis de restaurer une réplication saine.
Cette expérience rappelle que même dans un environnement moderne (Windows Server 2019/2022/2025, niveau fonctionnel 2016), DFSR reste sensible aux problèmes de RPC et de cohérence interne.

Une approche méthodique (diagnostic, backups, réinit authoritative/non-authoritative) est la clé pour restaurer la stabilité sans perte de GPO.