Introduction

Le répertoire SYSVOL est répliqué entre tous les contrôleurs d’un domaine Active Directory. Celui-ci peut être répliqué par FRS (File Replication Service) ou DFS-R (Distributed File System Replication). FRS devient petit à petit obsolète et il convient de migrer vers DFS-R dès que tous les contrôleurs de domaine (DC) utilisent Windows 2008 ou supérieur. Il existe d’ailleurs une procédure fortement documenté par Microsoft pour effectuer cette bascule (https://technet.microsoft.com/en-us/library/dd640019(v=WS.10).aspx). En effet, DFS-R est beaucoup plus robuste et performant.

Cependant, celui-ci peut aussi rencontré des problèmes et la réplication peut se retrouver en erreur avec certains contrôleur de domaine. Lorsque cet incident survient, les stratégies de groupes (GPO) ou les scripts d’ouverture de session (ou de démarrage d’ordinateur) ne sont plus forcément en accord avec la dernière version mise en place. Pire, une stratégie de groupe récemment créée peut ne pas exister sur un contrôleur de domaine. On rencontre alors des erreurs d’application des GPOs sur des postes clients, serveurs ou utilisateurs. Pour pallier à ce problème, il existe une procédure permettant de resynchroniser la totalité (restaurer) du répertoire SYSVOL depuis un contrôleur de domaine valide.

Nous allons voir comment repérer les contrôleur de domaine dont la réplication DFS-R du SYSVOL est en erreur, puis nous aborderons le sujet de la restauration non autoritaire (principe expliqué ci-dessous) du répertoire SYSVOL.

Diagnostic

Pour repérer si un contrôleur de domaine ne réplique plus correctement le répertoire SYSVOL, il existe une multitude de méthodes. Tout d’abord, il suffit de comparer le contenu des dossiers SYSVOL de plusieurs contrôleurs de domaine. Si l’un d’entre eux est vide ou qu’il n’y a pas les mêmes objets alors il y a des problèmes de réplication DFS-R du répertoire SYSVOL.

Il existe aussi des techniques plus fiables. Tout d’abord, dans une invite de commande depuis un contrôleur de domaine, on peut exécuter le script ci-dessous :

Ce dernier affiche un statut de la réplication DFS-R pour chaque contrôleur de domaine. Le chiffre affiché pour chaque DC nous donne l’information. Lorsqu’il y a une erreur celui-ci possède la valeur 5 (une réplication sans erreur équivaut à un statut 4). Aussi, il peut arriver que la valeur soit “No instance avalaible”. Cette information indique qu’il n’y a donc pas de réplication du SYSVOL.

On peut confirmer une erreur de réplication DFS-R (ou même une absence de réplication du SYSVOL) via la recherche d’événements spécifiques dans l’observateur d’événements. Ceux-ci sont situés dans le journal “DFS Replication” et non dans les journaux Active Directory. Il faut rechercher les événements avec les IDs suivants :

• 2012

• 2013

• 4012

Event 2012

L’événement 2012 nous informe d’une erreur de réplication DFS lors d’un arrêt non prévu du serveur (coupure de courant). Si cet événement n’est pas accompagné d’un événement avec l’ID 2013 alors la réplication a repris son cours normal et ne nécessite pas d’action (vous devriez néanmoins obtenir un statut 4 avec la commande précédente pour confirmer cela).

Event 2013

Cet événement indique que la réplication n’a pas repris et qu’il convient de le faire manuellement via la commande suivante :

NB : Pensez à remplacer GUID_VOLUME par le votre. Pour cela, il suffit de copier coller la commande indiqué dans l’événement pour relancer la réplication du répertoire SYSVOL. Cependant, si celle-ci n’a pas été relancé depuis longtemps alors elle ne redémarre pas et on obtient l’événement 4012.

Pour information, les management packs SCOM AD ou DFS ne remontent pas ce type d’erreur.

Event 4012

En effet, lorsqu’une réplication DFS-R a été stoppé pendant plus de 60 jours (valeur par défaut du paramètre MaxOfflineTimeInDays) alors il est nécessaire de lancer une synchronisation complète du dossier répliqué. L’événement donne une procédure qui peut s’appliquer dans le cas où il s’agit d’une réplication DFS-R créé par un administrateur. Néanmoins celle-ci n’est pas applicable dans le cas du répertoire SYSVOL car nous n’avons tout simplement pas accès à cette réplication via la console DFS Management. Il faut alors réaliser une restauration du répertoire SYSVOL.

Procédure de restauration

Cette procédure n’est pas compliquée mais nécessite de la rigueur afin de rétablir la réplication Active Directory du répertoire SYSVOL. Toutefois, celle-ci ne s’applique que lorsque le nombre de contrôleurs de domaine en erreur est faible et que l’on est sûr que celui-ci répliquera le répertoire SYSVOL depuis un contrôleur de domaine sain. Par exemple, cela peut être le cas dans une topologie en étoile lorsque un ou plusieurs contrôleurs de domaine présent sur des sites distants ne répliquent plus le répertoire SYSVOL.

Dans le cas où l’on souhaiterait restaurer le dossier SYSVOL depuis un contrôleur de domaine précis et restaurer tous les autres DC alors il convient de réaliser une restauration autoritaire du SYSVOL (la restauration est forcé depuis un contrôleur de domaine précis et la réplication DFS-R est coupé temporairement sur les autres DC).

Lors de l’exécution du processus ci-dessous, on ne choisit pas un contrôleur de domaine comme source de la restauration, cette dernière est donc dite non autoritaire. Il n’existe pas véritablement de règle pour savoir s’il faut préférer une restauration autoritaire ou non. Cela dépendra donc des cas (pourcentage de DC en erreur, topologie Active Directory complexe). Microsoft recommande toutefois de réaliser une restauration autoritaire dès qu’il y a plus d’un DC qui rencontre ce type de problème (dans des gros environnements cela peut vite devenir compliqué à mettre en œuvre et une restauration non autoritaire peut rester une solution viable).

Pour réaliser une restauration non autoritaire, il faut lancer ADSIEdit avec un compte administrateur du domaine.

Il faut ensuite effectuer un clic droit sur ADSI Edit puis choisir l’option “Connect To”.

Dans les paramètres de connexion il faut choisir de se connecter au contexte d’attribution de noms par defaut (Default Naming Context) et valider.

Enfin, il faut naviguer jusqu’à l’objet du contrôleur de domaine posant problème (Exemple de chemin : CN=DC01,OU=Domain Controllers,DC=myenterprise,DC=com) puis se rendre dans le conteneur “DFSR-LocalSettings” puis “Domain System Volume”.

Sur ce dernier, il faut effectuer un clic droit puis choisir “Properties”. Il faut ensuite trouver l’attribut “msDFSR-Enabled” et passer la valeur à “False” (cette dernière doit être à “True” par défaut). Cela permet de rendre le contrôleur de domaine non authoritaire pour la réplication.

Par la suite, on force une réplication Active Directory depuis un DC sain via l’outil en ligne de commande repadmin :

Sur le DC en erreur, on exécute la commande ci-dessous qui aura pour effet de désactiver la réplication du répertoire SYSVOL :

Un événement avec l’ID 4114 doit être présent dans le journal “DFS Replication” de l’observateur d’événement du contrôleur de domaine en erreur dont voici le contenu :

Nous pouvons maintenant réinitialiser la réplication du répertoire SYSVOL. Dans ADSI Edit, il faut éditer de nouveau l’objet “Domain System Volume” du contrôleur de domaine en erreur et remettre la valeur de l’attribut “msDFSR-Enabled” à “True”.

Il suffit ensuite de forcer une réplication Active Directory depuis un DC sain via l’outil en ligne de commande repadmin :

Puis, on lance une réplication initiale du répertoire SYSVOL depuis le DC sur lequel on effecture une restauration via la commande :

Un premier événement de type avertissement doit être visible dans le journal “DFS Replication”. Celui-ci possède l’ID 4614. Il indique que la réplication Active Directory s’est lancée.

Lorsque la réplication est terminée, un second événement avec l’ID 4604 indique la bonne exécution de celle-ci.

Enfin, on peut vérifier le statut de la réplication du répertoire SYSVOL du contrôleur de domaine via la commande suivante :

NB : Pensez à changer NOM_DC par le nom du contrôleur de domaine à tester.