Partager via

Apprendre à forcer la synchronisation faisant autorité et ne faisant pas autorité pour la réplication Sysvol répliquée par DFSR

  • Article

Cet article explique comment forcer une synchronisation faisant autorité et ne faisant pas autorité pour la réplication sysvol répliquée par DFSR.

Numéro de l’article d’origine dans la base de connaissances : 2218556

Résumé

Prenons l’exemple du scénario suivant :

Vous souhaitez forcer la synchronisation ne faisant pas autorité de la réplication sysvol sur un contrôleur de domaine. Dans le service de réplication de fichiers (FRS), elle a été contrôlée par le biais des valeurs de données D2 et D4 pour les valeurs de Registre Bur Flags, mais ces valeurs n’existent pas pour le service de réplication du système de fichiers (DFSR). Pour ce faire, vous ne pouvez pas utiliser le composant logiciel enfichable DFS Management (Dfsmgmt.msc) ou l’outil en ligne de commande Dfsradmin.exe. Contrairement aux dossiers répliqués DFSR personnalisés, la réplication sysvol est intentionnellement protégée contre toute modification via ses interfaces de gestion pour éviter les accidents.

Comment effectuer une synchronisation ne faisant pas autorité de la réplication sysvol répliquée par DFSR (comme D2 pour FRS)

  1. Dans l’outil ADSIEDIT. MSC, modifiez la valeur et l’attribut de nom unique (DN) suivants sur chacun des contrôleurs de domaine que vous souhaitez rendre comme ne faisant pas autorité :

    CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>

msDFSR-Enabled=FALSE

  2. Forcez la réplication Active Directory dans l’ensemble du domaine.

  3. Exécutez la commande suivante à partir d’une invite de commandes avec élévation de privilèges sur les serveurs que vous avez définis comme ne faisant pas autorité :

    DFSRDIAG POLLAD

  4. L’ID d’événement 4114 s’affiche dans le journal des événements DFSR, indiquant que la réplication SYSVOL n’est plus en cours de réplication.

  5. Sur le même nom unique qu’à l’étape 1, définissez msDFSR-Enabled=TRUE.

  6. Forcez la réplication Active Directory dans l’ensemble du domaine.

  7. Exécutez la commande suivante à partir d’une invite de commandes avec élévation de privilèges sur les serveurs que vous avez définis comme ne faisant pas autorité :

    DFSRDIAG POLLAD

  8. Les ID d’événement 4614 et 4604 s’affichent dans le journal des événements DFSR, indiquant que la réplication SYSVOL a été initialisée. Ce contrôleur de domaine a maintenant effectué une D2 de réplication SYSVOL.

Comment effectuer une synchronisation faisant autorité de la réplication SYSVOL répliquée par DFSR (comme D4 pour FRS)

  1. Définissez le type de démarrage du service de réplication DFS sur Manuel et arrêtez le service sur tous les contrôleurs de domaine du domaine.

  2. Dans l’outil ADSIEDIT.MSC, modifiez le nom unique et les deux attributs suivants sur le contrôleur de domaine que vous souhaitez définir comme faisant autorité (de préférence l’émulateur de contrôleur de domaine principal, qui est généralement le plus à jour pour le contenu de réplication SYSVOL) :

    CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>

msDFSR-Enabled=FALSE
msDFSR-options=1

  3. Modifiez le nom unique et l’attribut unique suivants sur tous les autres contrôleurs de domaine de ce domaine :

    CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain>

msDFSR-Enabled=FALSE

  4. Forcez la réplication Active Directory dans l’ensemble du domaine et validez sa réussite sur tous les contrôleurs de domaine.

  5. Démarrez le service DFSR sur le contrôleur de domaine défini comme faisant autorité à l’étape 2.

  6. L’ID d’événement 4114 s’affiche dans le journal des événements DFSR, indiquant que la réplication SYSVOL n’est plus en cours de réplication.

  7. Sur le même nom unique qu’à l’étape 2, définissez msDFSR-Enabled=TRUE.

  8. Forcez la réplication Active Directory dans l’ensemble du domaine et validez sa réussite sur tous les contrôleurs de domaine.

  9. Exécutez la commande suivante à partir d’une invite de commandes avec élévation de privilèges sur le serveur que vous avez défini comme faisant autorité :

    DFSRDIAG POLLAD

  10. L’ID d’événement 4602 s’affiche dans le journal des événements DFSR, indiquant que la réplication SYSVOL a été initialisée. Ce contrôleur de domaine a maintenant effectué une D4 de réplication SYSVOL.

  11. Démarrez le service DFSR sur les autres contrôleurs de domaine ne faisant pas autorité. L’ID d’événement 4114 s’affiche dans le journal des événements DFSR, indiquant que la réplication SYSVOL n’est plus en cours de réplication sur chacun d’eux.

  12. Modifiez le nom unique et l’attribut unique suivants sur tous les autres contrôleurs de domaine de ce domaine :

    CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain>

msDFSR-Enabled=TRUE

  13. Exécutez la commande suivante à partir d’une invite de commandes avec élévation de privilèges sur tous les contrôleurs de domaine ne faisant pas autorité (c’est-à-dire, tous sauf celui défini précédemment comme faisant autorité) :

    DFSRDIAG POLLAD

  14. Renvoyez le service DFSR vers son type de démarrage d’origine (automatique) sur tous les contrôleurs de domaine.

Plus d’informations

Si vous définissez l’indicateur d’autorité sur un contrôleur de domaine, vous devez synchroniser tous les autres contrôleurs de domaine du domaine en ne faisant pas autorité. Dans le cas contraire, des conflits apparaîtront sur les contrôleurs de domaine, provenant des contrôleurs de domaine que vous n’avez pas définis comme faisant ou ne faisant pas autorité avant de redémarrer le service DFSR. Par exemple, si tous les scripts d’ouverture de session ont été accidentellement supprimés et qu’une copie manuelle de ces scripts a été replacée sur le détenteur du rôle d’émulateur de contrôleur de domaine principal, définir ce serveur comme faisant autorité et tous les autres comme ne faisant pas autorité garantirait la réussite et empêcherait les conflits.

S’il faut définir un contrôleur de domaine comme faisant autorité, il est préférable de choisir l’émulateur de contrôleur de domaine principal, car son contenu de réplication SYSVOL est le plus à jour.

L’utilisation de l’indicateur d’autorité n’est nécessaire que si vous devez forcer la synchronisation de tous les contrôleurs de domaine. Si vous ne réparez qu’un contrôleur de domaine, définissez-le comme ne faisant pas autorité et ne touchez pas aux autres serveurs.

Cet article est conçu avec un environnement à deux contrôleurs de domaine à l’esprit, par souci de simplicité de description. Si plusieurs contrôleurs de domaine sont affectés, développez les étapes pour tous les inclure également. Il suppose également que vous avez la possibilité de restaurer des données qui ont été supprimées, écrasées, endommagées, etc. précédemment s’il s’agit d’un scénario de reprise après sinistre sur tous les contrôleurs de domaine du domaine.