Réparer la synchronisation DFS du dossier SYSVOL

Bonjour à tous,

Après une migration, il se trouve qu’on a découvert que le sysvol ne se répliquait plus sur 7 des 7 contrôleurs de domaines des 3 sites.

Autant vous dire que dans cet article (et peut-être un deuxième selon si je me flingue d’ici là), on va voir comment j’ai pu récupérer, pour l’instant, une synchronisation DFSR du dossier SYSVOL fonctionnelle après 5 ans d’absence de la bonne marche du service.

Pour vous mettre dans le bain directement, voici le premier message d’erreur que j’ai trouvé lorsque j’ai voulu diagnostiquer le souci :

Voici donc ce que j’ai du faire pour réparer cette situation compliquée.

Isolation du contrôleur de domaine primaire

Premièrement, il vous faudra isoler le contrôleur de domaine primaire.

Rien de plus simple, lancez la commande suivante depuis tous vos contrôleurs de domaines en powershell (ou cmd) :

netdom query pdc

Si je dis de la lancer depuis tous les controlleurs de domaines, c’est pour vérifier qu’ils renvoient bien tous la même information.
Si votre DFS est aux fraises, il y’a des risques que l’AD le soit aussi et que ça vous sorte deux PDC différents. Et la ça deviendrait beaucoup plus compliqué.

Ensuite, installez directement les outils DFS qui nous serviront pour la suite en powershell (à faire sur chaque contrôleur de domaine) :

Install-WindowsFeature RSAT-DFS-Mgmt-Con

Initialisation de la synchronisation d’autorité

Votre PDC va devoir servir de base à la restauration, car, c’est normalement lui qui dispose du dossier sysvol le plus à jour.

Dans un premier temps, faites une copie de votre dossier sysvol sur le bureau.

Ensuite, stoppez le service DFSR sur tous les contrôleurs de domaine.

Ouvrez maintenant « ADSIEDIT.MSC » sur votre PDC. Ouvrez le « Default naming context ».

Maintenant, ouvrez la configuration suivante :

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<SERVEUR PDC>,OU=Domain Controllers,DC=<domain>,DC=<domain>

Changez les options suivantes :

msDFSR-Enabled=FALSE
msDFSR-options=1

Maintenant, modifiez tous les autres AD du domaine :

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<Autres AD>,OU=Domain Controllers,DC=<domain>,DC=<domain>

Changez l’option suivante :

msDFSR-Enabled=FALSE

Forcez une synchronisation AD depuis le PDC :

repadmin /syncall NOMDUPDC /APed

Redémarrez DFSR sur le PDC.

Ouvrez l’Event Viewer et allez dans « Applications and Services Logs -> DFS Replication ».

Vérifiez que vous trouvez l’événement 4114 après 5 minutes.

Si vous n’avez pas de bol, comme moi, vous tomberez sur l’événement 2212 indiquant une corruption de la base DFSR.

Dans le log de cet évent, vous trouverez une commande à lancer sous la forme suivante pour reconstruire la base :

wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid=<GUID> call ResumeReplication

Lancez-la dans un CMD administrateur et redémarrez DFSR.

Si vous avez finalement l’évent 4114, vérifiez que les fichiers du SYSVOL sont à jour et continuez.

Synchronisation des autres contrôleurs de domaines :

Nettoyer d’abord les dossiers sysvol des autres contrôleurs de domaines :

%WINDIR%\SYSVOL\domain\Policies
%WINDIR%\SYSVOL\domain\Scripts

Réactivez DFSR sur le PDC depuis l’ADSI :

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<SERVEUR PDC>,OU=Domain Controllers,DC=<domain>,DC=<domain>

Changez l’option suivante :

msDFSR-Enabled=TRUE

Ensuite, resynchronisez l’AD et le DFSR depuis la ligne de commande :

DFSRDIAG POLLAD
repadmin /syncall NOMDUPDC /APed

Vous devriez voir les événements 2002 et 4602 sur le PDC.

Si c’est bon, réactivez la synchronisation sur tous les autres contrôleurs de domaine :

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<Autres AD>,OU=Domain Controllers,DC=<domain>,DC=<domain>

Changez l’option suivante :

msDFSR-Enabled=TRUE

Relancez la commande suivante (vous pouvez le faire sur chaque AD séparément):

DFSRDIAG POLLAD

Vous devriez (enfin) voir les événements  2002 et 4602 sur les autres contrôleurs de domaines.

Si vous faites comme moi, et que vous enchainez les coups de bol par contre, vous pourriez découvrir l’événement 4012.

« The DFS Replication service stopped replication on the folder with the following local path: C:\Windows\SYSVOL\domain. This server has been disconnected from other partners for 1821 days, which is longer than the time allowed by the MaxOfflineTimeInDays parameter (60). DFS Replication considers the data in this folder to be stale, and this server will not replicate the folder until this error is corrected. »

Bon, après 5 ans il y’avait peu de chance que ça reparte.

Vous pouvez truander et changer le paramètre bloquant sur chaque AD posant le souci :

wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=2000

Redémarrez le service DFSR et relancez les synchros.

Dès que ça passe, remettez la valeur par défaut :

wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=60

Et voici comment on répare une synchronisation DFS ayant quitté ce monde il y’a bien longtemps.

Sources :

• https://support.microsoft.com/en-us/help/2218556/how-to-force-an-authoritative-and-non-authoritative-synchronization-fo
• https://social.technet.microsoft.com/Forums/ie/en-US/c57791e6-c4f4-4e8f-9a74-eab985ecf614/event-id-4012-the-dfs-replication-service-stopped-replication?forum=winserverDS