carlo.yznardo
lang=|
← Back to blog
WindowsOctober 16, 2024/reconstruction-manuelle-dun-groupe-dfsr-defectueux.mdx

$ cat Reconstruction manuelle d’un groupe DFSR défectueux

Récemment, j’ai été confronté à un défi impliquant un ancien contrôleur de domaine (AD) toujours en service dans notre infrastructure. Ce serveur gérait non seulement le domaine, mais fournissait également des services d’impression, de partage de fichiers et d…

Récemment, j’ai été confronté à un défi impliquant un ancien contrôleur de domaine (AD) toujours en service dans notre infrastructure. Ce serveur gérait non seulement le domaine, mais fournissait également des services d’impression, de partage de fichiers et des services RDS pour un logiciel de comptabilité. Remplacer ce serveur ou réinstaller l’application sur un autre aurait probablement entraîné des coûts supplémentaires pour notre client, ce que nous souhaitions éviter.

La problématique

La solution la plus logique était donc de mettre en place un nouveau contrôleur de domaine propre, de lui transférer tous les rôles FSMO, ainsi que les services d’impression et de fichiers. L’ancien serveur pourrait alors être dédié exclusivement aux connexions RDS pour le logiciel de comptabilité.

Cependant, après avoir migré avec succès tous les rôles FSMO vers le nouveau serveur, et malgré des résultats positifs aux tests DCDIAG et de réplication, j’ai constaté que les dossiers SYSVOL et NETLOGON ne se répliquaient pas sur le nouveau contrôleur de domaine.

Le Gestionnaire de serveur et le Visualiseur d’événements indiquaient une défaillance de la réplication DFSR, le nouveau DC ne parvenant pas à contacter l’ancien pour la réplication. Pourtant, toutes les modifications apportées à l’Active Directory étaient bien reflétées sur les deux serveurs, et les tests de connectivité (ping) étaient concluants.

Déclasser l’ancien serveur sans résoudre ce problème aurait entraîné des erreurs critiques et un crash du domaine.

Ma démarche

Pour résoudre ce problème sans risquer l’environnement de production,mes colleagues ont créé un environnement de test sur l’un de nos hyperviseurs en utilisant des copies des machines virtuelles en production. Les services d’impression, DHCP, DNS, serveur de fichiers et AD étaient déjà installés sur la nouvelle VM, ainsi que les droits FSMO.

Diagnostic

Lors des tests, j’ai remarqué que l’objet CN=Dfsr-LocalSettings manquait sur l’ancien DC. Cela confirmait que le problème provenait d’un groupe DFSR corrompu ou inexistant.

Étapes pour reconstruire le groupe DFSR

Voici les étapes détaillées que j’ai suivies pour résoudre le problème de réplication DFSR :

Préambule : Sauvegarder l’Active Directory

Avant toute manipulation, il est essentiel de sauvegarder l’Active Directory pour prévenir tout risque de perte de données.

1. Supprimer les objets DFSR défectueux

Utilisez l’Éditeur ADSI pour supprimer les objets défectueux sur chaque contrôleur de domaine :

  • Emplacement :

  • Objet 1 : CN=Domain System Volume

  • Emplacement :

  • Objet 2 : CN=Dfsr-LocalSettings

Remarque : Assurez-vous de bien cibler les objets exacts pour éviter toute suppression accidentelle.

2. Arrêter le service DFSR sur tous les DC

Sur chaque contrôleur de domaine, exécutez la commande suivante dans une invite de commande avec privilèges administrateur :

net stop dfsr

3. Créer les clés et valeurs de registre sur le PDC

Sur le contrôleur de domaine principal (PDC) :

  • Ouvrir l’Éditeur de Registre

  • Tapez regedit dans la boîte de dialogue Exécuter (Win + R).

  • Naviguer vers la clé suivante :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Promoting SysVols
  • Créer une nouvelle valeur DWORD :

  • Nom : Sysvol Information is Committed

  • Valeur : 1

  • Créer une nouvelle clé sous Promoting SysVols :

  • Nom de la clé : domain.local (Remplacez par le nom réel de votre domaine)

  • À l’intérieur de la nouvelle clé domain.local, créer les valeurs suivantes :

4. Redémarrer le service DFSR sur le PDC

Dans l’invite de commande avec privilèges administrateur, exécutez :

net start dfsr

Résultat attendu :

  • L’objet CN=Domain System Volume est recréé sous :
CN=DFSR-GlobalSettings,CN=System,DC=domain,DC=local
  • Les clés et valeurs de registre créées sont automatiquement supprimées.

  • Un événement DFSR 4602 est enregistré dans le Journal des événements, indiquant la création réussie du groupe de réplication.

5. Créer les clés et valeurs de registre sur les autres DC

Sur chaque autre contrôleur de domaine (non RODC) :

  • Ouvrir l’Éditeur de Registre

  • Tapez regedit dans la boîte de dialogue Exécuter (Win + R).

  • Naviguer vers la clé :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Promoting SysVols
  • Créer une nouvelle valeur DWORD :

  • Nom : Sysvol Information is Committed

  • Valeur : 1

  • Créer une nouvelle clé sous Promoting SysVols :

  • Nom de la clé : domain.local (Remplacez par le nom réel de votre domaine

6. Redémarrer le service DFSR sur les autres DC

Dans l’invite de commande avec privilèges administrateur, exécutez sur chaque DC :

net start dfsr

Résultat attendu :

  • L’objet CN=Domain System Volume est recréé sous :
CN=DFSR-GlobalSettings,CN=System,DC=domain,DC=local
  • Les clés et valeurs de registre créées sont automatiquement supprimées.

  • Les événements DFSR 4614, 6805 et 4804 sont enregistrés, indiquant que la réplication SYSVOL est en cours et fonctionne correctement.

7. Vérification de la réplication

  • Sur chaque DC, vérifiez que les dossiers SYSVOL et NETLOGON sont présents et contiennent les mêmes données.

  • Utilisez la commande suivante pour vérifier l’état de la réplication DFSR :

dfsrdiag pollad
  • Consultez les journaux d’événements pour tout message d’erreur ou avertissement.

Remarque : La réplication peut prendre quelques minutes pour se propager complètement. Soyez patient et assurez-vous que tous les DC sont synchronisés avant de considérer l’opération comme réussie.

Résultat

Après avoir suivi ces étapes, la réplication des dossiers SYSVOL et NETLOGON a été rétablie sur le nouveau contrôleur de domaine. Cela m’a permis de déclasser l’ancien serveur en toute sécurité, sans perturber le domaine ni les services essentiels pour le client.