Comment supprimer correctement les objets persistants lorsque -strict a été défini sur un grand nombre de contrôleurs de domaine depuis longtemps?

J'étais récemment dans un environnement où il y avait 120 contrôleurs de domaine dans plus de 100 sites à travers le monde. Ce domaine a commencé à l'ère de Windows 2000 et a été mis à niveau au fil du temps, de sorte que la cohérence de réplication stricte n'a jamais été définie comme valeur par défaut pour les nouveaux contrôleurs de domaine et n'a jamais été activée sur aucun contrôleur de domaine. Il y a des objets persistants dans le répertoire et vous voyez régulièrement un nombre décent d'objets en conflit à cause de cela.

Utiliser repadmin /removelingeringobjectsnécessite de connaître deux choses:

1. Quels contrôleurs de domaine ont des objets en attente dans la base de données

2. Un DC qui n'a aucun objet en attente à utiliser comme DC de référence.

Évidemment, à l'avenir, cet environnement devrait être défini de sorte que tous les nouveaux contrôleurs de domaine aient une cohérence de réplication stricte appliquée et repadmin /options * +strictdevrait être exécuté pour que tous les contrôleurs de domaine actuels utilisent une cohérence de réplication stricte, mais cela interrompra la réplication maintenant sans nettoyer les objets .

Donc, ma question est la suivante: dans un environnement aussi massif où je n'aurais aucune idée quels contrôleurs de domaine ont des objets en attente et lesquels ne le font pas, comment puis-je identifier un bon contrôleur de référence repadmin /removelingeringobjectsà utiliser et comment puis-je m'assurer que tous les 120+ Les contrôleurs de domaine sont débarrassés des objets en attente avant d'appliquer une cohérence de réplication stricte et d'interrompre la réplication? Ou, est-il simplement plus facile d'activer le mode strict et de regarder repadmin /replsumpour voir ce qui se casse et y faire face?

Cela prendra un certain temps à corriger.

Pour arrêter toute réplication, exécutez:

repadmin /options +DISABLE_OUTBOUND_REPL

Sur tous les DC. N'oubliez pas que le paramètre ci-dessus n'empêche pas les actions de réplication manuelle telles qu'un administrateur (vous) en cours d'exécution repadmin /syncall /APed, etc.

Repadmin détermine qu'il s'agit d'un objet en attente si l'objet existe sur ServerA mais pas sur ServerB, où ServerB est le contrôleur de domaine de référence. La différence entre la réplication des objets nouvellement créés et la réplication des mises à jour sur des objets déjà existants est la clé. Réplication des objets nouvellement créés = bon. Réplication des mises à jour sur des objets déjà existants = bonne. Réplication des mises à jour des objets qui n'existent pas sur le DC de destination = mauvais.

Vous n'avez qu'à faire mousser, rincer, répéter jusqu'à ce que tous les DC correspondent à votre seul DC de référence. Activez ensuite la cohérence stricte partout, puis réactivez la réplication. Oui, vous courez le risque de supprimer des objets légitimes créés sur d'autres contrôleurs de domaine distants qui n'ont pas été répliqués sur votre contrôleur de domaine de référence.

Extrait du grand article « Fonctionnement du modèle de réplication Active Directory »:

Paramètre de cohérence de la réplication

Si les attributs d'un objet en attente ne changent jamais, l'objet n'est jamais pris en compte pour la réplication. Cependant, si un attribut change, l'attribut est pris en compte pour la réplication sortante. Étant donné que le contrôleur de domaine de destination ne contient pas l'objet pour l'attribut qui est répliqué, une mise à jour ne peut pas être effectuée. La résolution de cette condition dépend du paramètre de cohérence de la réplication sur le contrôleur de domaine.

Un paramètre de Registre sur les contrôleurs de domaine qui exécutent Windows Server 2003 ou Windows 2000 Server avec SP3 fournit une valeur de cohérence qui détermine si un contrôleur de domaine réplique et réanime un objet mis à jour qui a été supprimé de toutes les autres répliques, ou si la réplication de ces objets est bloqué. Les paramètres par défaut sont différents sur les contrôleurs de domaine qui exécutent Windows 2000 Server avec SP3 et Windows Server 2003.

Cohérence de réplication stricte

Pour éviter les problèmes de réanimation des objets supprimés, un contrôleur de domaine qui exécute Windows Server 2003 dans une forêt Windows Server 2003 nouvellement créée (non mise à niveau) bloque la réplication entrante par défaut lorsqu'il reçoit une mise à jour d'un objet qu'il ne possède pas .

Remarque • La réplication Active Directory utilise le suivi des mises à jour pour faire la différence entre la réplication d'un objet nouvellement créé et la mise à jour d'un attribut pour un objet existant. La réplication d'un objet en attente est une tentative de mise à jour d'un attribut ou des attributs d'un objet que le contrôleur de domaine de destination ne peut pas mettre à jour car l'objet n'existe pas.

La réplication est arrêtée dans la partition d'annuaire de l'objet jusqu'à ce que l'objet en attente soit supprimé du contrôleur de domaine source ou que le paramètre de cohérence de réplication stricte soit désactivé.

Lorsque ServerB dit à ServerA: "Hé, certaines mises à jour ont été apportées à objectA existant." Puis ServerA dit: "Attendez quoi? Je n'ai même pas d'objet A du tout. Envoyez-moi tout l'objet!" Si aucune cohérence stricte. Si la cohérence est stricte, ServerA dit: "Attendez quoi? Comment voulez-vous que je mette à jour un objet qui n'existe pas? Allez vous plier!"

Pour savoir si vous avez des objets en attente sur un contrôleur de domaine:

repadmin /removelingeringobjects ServerName ServerGUID DirectoryPartition /advisory_mode 

ServerGUID est le bon DC de référence connu. Je sais que vous le savez déjà ... et comment écrire la ligne ci-dessus pour l'exécuter sur tous les DC ... ( foreach ($DC In $(Get-ADDomain).ReplicaDirectoryServers) { }) ...

Vous avez besoin d'une bonne source DC pour comparer, en bout de ligne. Si vous ne disposez pas d'une bonne source DC connue ou si vous ne savez pas, il vous suffit d'en choisir une. Il doit bien sûr s'agir d'un GC inscriptible. C'est relatif - si tous les contrôleurs de domaine s'accordent sur l'existence d'un objet et les attributs de cet objet ... alors ce n'est pas un objet persistant.

foreach($GC In $(Get-ADForest).GlobalCatalogs) { repadmin /removelingeringobjects $_.name 85d158d2-a006-4fff-b1e5-f9b6eaabab2b '$directoryPartition'

Cela resynchronise cette partition d'annuaire de chaque GC de la forêt avec la bonne source connue que vous devez spécifier comme GUID.

Ensuite, une fois que tous vos contrôleurs de domaine sont à nouveau tous d'accord, et que la réplication est heureuse ... alors vous allez commencer à basculer sur une cohérence stricte sur chacun d'eux.

Edit: Ceci est la ligne du parti de Microsoft sur le problème, et ce qu'ils vous parleront probablement si vous les appeliez.

Enfin, cela peut être plus difficile à résoudre que cela ne vaut, à moins que cela ne vous cause des problèmes. Je déteste le dire, mais AD peut toujours fonctionner normalement avec des objets persistants.

Le principe général dans un cas où vous ne pouvez pas identifier un DC propre est le suivant:

for each $sourceDC in $allDCs
    for each $targetDC in $allDCs
        if ($targetDC <> $sourceDC) then
            run repadmin with $sourceDC and $targetDC
        end if
    next
next

Ce processus est décrit ici: http://blogs.technet.com/b/glennl/archive/2007/07/26/clean-that-active-directory-forest-of-lingering-objects.aspx

Cependant, jetez un œil à ReplDiag . Il automatise le processus en s'exécutant repadminpour vous contre toutes les combinaisons de contrôleurs de domaine source et cible. Il effectue ensuite un suivi /advisory_onlypour vérifier la présence d'autres objets persistants.