Exécution d’une synchronisation faisant autorité des données SYSVOL à l’aide de la réplication de système de fichiers distribué (DFSR)

Important : Cet article s’applique uniquement si les données SYSVOL sont répliquées à l’aide de la réplication de système de fichiers distribué (DFSR). Il s’agit de la méthode privilégiée de réplication des données SYSVOL depuis Windows Server 2008. Toutefois, il est possible que l’ancienne méthode, FRS (File Replication Service), soit toujours utilisée si le domaine existe depuis longtemps. Pour déterminer si DFSR est utilisé, exécutez dfsrmig /getmigrationstate à partir d’une invite de commande avec élévation de privilèges sur un contrôleur de domaine (DC). Si l’état de la migration est « Éliminé », cela signifie que DFSR est en cours d’utilisation.

La hiérarchie de dossiers SYSVOL, présente sur tous les contrôleurs de domaine Active Directory, est utilisée pour stocker deux ensembles de données importants :

• Fichiers de modèle de stratégie de groupe : Celles-ci sont stockées dans des dossiers distincts sous \\SYSVOL\<domain>\Policies.
• Scripts de connexion, de déconnexion, de démarrage et d’arrêt utilisés par les machines du domaine : Ils sont stockés dans \\SYSVOL\<domain>\scripts. Le dossier scripts est lui-même partagé en tant que NETLOGON.

Ces données sont répliquées entre les contrôleurs de domaine, mais la réplication SYSVOL a lieu séparément de la réplication Active Directory. Il est possible que l’un échoue alors que l’autre est pleinement fonctionnel. Dans certaines situations, la réplication SYSVOL peut échouer et ne pas pouvoir reprendre sans intervention manuelle. Les étapes suivantes effectuent une synchronisation faisant autorité de SYSVOL. Dans une synchronisation faisant autorité, DFSR initialise SYSVOL à l’aide de la copie du contrôleur de domaine des données SYSVOL. Il s’agit de la copie source de SYSVOL pour le domaine. Une synchronisation faisant autorité est nécessaire si le contrôleur de domaine disposant de la copie la plus récente des données SYSVOL est le contrôleur de domaine sur lequel DFSR a cessé de fonctionner. Cela est implicitement vrai s’il n’y a qu’un seul contrôleur de domaine dans le domaine.

Vous trouverez des instructions pour effectuer une synchronisation non forcée des données SYSVOL à l’aide de DFSR dans Comment effectuer une synchronisation non forcée des données SYSVOL à l’aide de la réplication du système de fichiers distribué (DFSR).

Note: Cet article ne précise pas quel contrôleur de domaine doit être choisi comme faisant autorité. Cette opération peut prendre un certain temps, en particulier dans un domaine volumineux. Il s’agit d’examiner les données SYSVOL sur chaque DC et de déterminer lequel dispose des données les plus complètes et les plus récentes. Le processus ci-dessous commence une fois qu’un contrôleur de domaine faisant autorité a été choisi.

Pour effectuer une synchronisation faisant autorité des données SYSVOL à l’aide de DFSR, procédez comme suit :

1. Sur le contrôleur de domaine faisant autorité, lancez la console de modification ADSI (adsiedit.msc).
2. Si le contexte de dénomination par défaut est déjà répertorié dans le volet de gauche, passez à l’étape suivante. Sinon, procédez comme suit pour vous connecter au contexte de dénomination par défaut :
   1. Cliquez avec le bouton droit de la souris sur l’en-tête ADSI Edit dans le volet de gauche et sélectionnez Se connecter à...
   2. Sélectionnez le bouton radio intitulé Sélectionner un contexte de dénomination bien connu , puis sélectionnez Contexte de dénomination par défaut dans la liste déroulante.
   3. Cliquez sur OK. Le contexte de dénomination par défaut doit désormais s’afficher dans le volet de gauche de la console.
3. Dans le contexte de dénomination par défaut, accédez à DC=domain > OU=Domain Controllers > CN=servername > CN=DFSR-LocalSettings > CN=Domain System Volume. Dans cette étape, nom_serveur représente le nom du contrôleur de domaine qui a été choisi comme faisant autorité.
4. Cliquez avec le bouton droit de la souris sur CN=SYSVOL Subscription et sélectionnez Properties.
5. Double-cliquez sur l’attribut msDFSR-Enabled et définissez sa valeur sur FALSE.
6. Double-cliquez sur l’attribut msDFSR-Options et définissez sa valeur sur 1.
7. Cliquez sur OK pour fermer la fenêtre des propriétés.
8. Répétez les étapes 3 à 5, mais pas l’étape 6, en remplaçant servername par le nom de tous les autres contrôleurs de domaine du domaine. En d’autres termes, accédez à l’objet Abonnement CN=SYSVOL de chacun des autres contrôleurs de domaine et définissez son attribut msDFSR-Enabled sur FALSE. Ne modifiez pas la valeur de l’attribut msDFSR-Options .
9. Force la réplication Active Directory dans l’ensemble du domaine. Cette opération peut prendre un certain temps, en fonction de la taille et de la topologie de réplication du domaine.
10. Sur chaque contrôleur de domaine du domaine, exécutez dfsrdiag pollad à partir d’une invite de commande avec élévation de privilèges.
11. Sur le contrôleur de domaine faisant autorité, lancez l’Observateur d’événements et vérifiez que le journal des événements de réplication DFS contient l’événement 4114. Cet événement indique que SYSVOL n’est plus répliqué. (Cet événement est présent sur tous les contrôleurs de domaine, mais il n’est pas nécessaire de tous les vérifier.)
12. Dans Modification ADSI, accédez à l’emplacement de l’étape 3 et définissez l’attribut msDFSR-Enabled sur TRUE.
13. Sur le contrôleur de domaine faisant autorité, exécutez dfsrdiag pollad à partir d’une invite de commande avec élévation de privilèges.
14. Vérifiez le journal des événements de réplication DFS sur le contrôleur de domaine faisant autorité pour l’événement 4602. Cet événement confirme qu’une synchronisation faisant autorité de SYSVOL s’est produite sur ce contrôleur de domaine.
15. Répétez l’étape 8, mais définissez l’attribut msDFSR-Enabled de chaque contrôleur de domaine sur TRUE cette fois-ci. Comme précédemment, ne modifiez pas la valeur de l’attribut msDFSR-Options .
16. Force la réplication Active Directory dans l’ensemble du domaine.
17. Sur chaque contrôleur de domaine, à l’exception de celui qui fait autorité, exécutez dfsrdiag pollad une dernière fois.
18. Sur au moins un des contrôleurs de domaine ne faisant pas autorité, vérifiez que les événements 4614 et 4604 apparaissent dans le journal des événements de réplication DFS. Ces événements indiquent que ces contrôleurs de domaine ont effectué une synchronisation SYSVOL ne faisant pas autorité.

Les étapes ci-dessus garantissent qu’une synchronisation non forcée de SYSVOL est effectuée sur tous les autres contrôleurs de domaine après la synchronisation faisant autorité sur le contrôleur de domaine faisant autorité. Cela permet d’éviter d’éventuels conflits dans les données SYSVOL.

Reportez-vous à cette vidéo :


Vous pouvez également visionner cette vidéo sur YouTube.

Si la demande dfsrdiag pollad commande n’est pas reconnue, vous avez deux options :

• Redémarrez le service de réplication DFS au lieu d’exécuter la commande. Si d’autres données (non SYSVOL) sont répliquées par DFSR, cela peut entraîner de brèves interruptions.
• Installez les outils de gestion DFS en sélectionnant Ajouter des rôles et des fonctionnalités dans le menu Gérer de Server Manager. Les outils de gestion DFS sont disponibles à l’emplacement indiqué ci-dessous.

Microsoft Windows Server 2016, Microsoft Windows Server 2019, Microsoft Windows Server 2022, Microsoft Windows Small Business Server 2011 Essentials, Microsoft Windows Small Business Server 2008, Microsoft Windows 2008 Server R2 , Microsoft Windows 2008 Server Service Pack 2, Microsoft Windows 2012 Server, Microsoft Windows 2012 Server R2 ... View More about warranties View Less about warranties