Les objets persistants peuvent rester après la remise en ligne d’un serveur de catalogue global obsolète

Cet article décrit les procédures de nettoyage des objets réintroduits dans AD après la remise en ligne d’un contrôleur de domaine hors connexion.

Produits concernés : Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 314282

Symptômes

Vous mettez un contrôleur de domaine (DC) ou un serveur de catalogue global en ligne après qu’il a été hors connexion pendant une longue période. Une fois qu’il est en ligne, vous observez un ou plusieurs des problèmes suivants :

  • Les messages électroniques ne sont pas remis à un utilisateur dont l’objet utilisateur a été déplacé d’un domaine à l’autre. Une fois que vous avez remis en ligne le contrôleur de domaine ou le serveur de catalogue global obsolète, les deux instances de l’objet utilisateur apparaissent dans le catalogue global. Les deux objets ayant la même adresse de messagerie, les messages électroniques ne peuvent pas être remis.
  • Un compte d’utilisateur qui n’existe plus apparaît toujours dans la liste d’adresses globale.
  • Un groupe universel qui n’existe plus apparaît toujours dans le jeton d’accès d’un utilisateur.
  • D’autres contrôleurs de domaine ou serveurs de catalogue globaux journalisent des événements tels que EventID 1084, Il n’existe aucun objet de ce type sur le serveur. La réplication supplémentaire est bloquée sur les contrôleurs de domaine ou les serveurs de catalogue globaux affectés.

Cause

Ces problèmes peuvent se produire si le contrôleur de domaine ou le serveur de catalogue global est hors connexion depuis plus longtemps que la valeur de l’attribut Tombstone-Lifetime des objets utilisateur.

Pour plus d’informations sur l’attribut Tombstone-Lifetime , consultez Attribut Tombstone-Lifetime.

L’attribut Tombstone-Lifetime définit le nombre de jours avant la suppression d’un objet supprimé des services d’annuaire. Cela permet de supprimer des objets des serveurs répliqués et d’empêcher les restaurations de réintroduire un objet supprimé. La valeur par défaut est 180 jours. Après ce délai, Active Directory n’a plus besoin de se souvenir de la modification.

Si un contrôleur de domaine ou un serveur de catalogue global est hors connexion plus longtemps que la valeur de l’attribut Tombstone-Lifetime , sa copie d’Active Directory (ou du catalogue global) peut contenir des objets qui ont été supprimés sur les autres contrôleurs de domaine. Toutefois, les autres contrôleurs de domaine ne se souviennent plus que les objets ont été supprimés. Lorsque vous mettez le contrôleur de domaine hors connexion en ligne, il synchronise sa copie d’Active Directory avec le reste du domaine. Étant donné que les informations sur les suppressions ont été ignorées, le contrôleur de domaine réplique les objets affectés (appelés objets persistants) dans le reste du domaine.

En général, AD DS utilise un modèle de réplication à cohérence faible, dans lequel certains contextes d’affectation de noms (également appelés partitions de répertoire) sont en lecture/écriture et d’autres en lecture seule. Lorsqu’un contrôleur de domaine qui reçoit un objet répliqué qui appartient à un contexte de nommage en lecture/écriture et que cet objet n’existe pas déjà dans la copie locale de l’arborescence d’informations sur le répertoire (DIT), le contrôleur de domaine crée l’objet. À mesure que le processus de réplication se poursuit, l’objet réapparaît sur tous les contrôleurs de domaine du domaine.

Les contrôleurs de domaine et les serveurs de catalogue globaux peuvent également utiliser un modèle de cohérence de réplication strict. Dans ce modèle, lorsque le contrôleur de domaine reçoit un objet répliqué qui n’existe pas encore dans le DIT local, le contrôleur de domaine cesse de recevoir ou d’envoyer des données répliquées et journalise des événements tels que l’ID d’événement 1084, « Il n’y a pas d’objet de ce type sur le serveur ». Pour plus d’informations sur la cohérence de réplication stricte, y compris les circonstances dans lesquelles les contrôleurs de domaine peuvent utiliser ce modèle par défaut, consultez kb 910205, Informations sur les objets persistants dans une forêt Windows Server Active Directory. Pour plus d’informations sur les problèmes tombstone, consultez KB216993 durée de conservation utile d’une sauvegarde d’état système d’Active Directory.

Résolution 1 : Déterminer si Active Directory a des objets persistants et éviter les objets persistants à l’avenir

Kb 910205 explique plusieurs façons de déterminer si votre système Active Directory a accumulé des objets persistants. Kb 910205 décrit également les étapes à suivre pour empêcher l’accumulation d’objets persistants.

Résolution 2 : Supprimer les objets persistants

Si l’objet ne doit pas exister dans Active Directory (par exemple, si l’objet a été réintroduit par un contrôleur de domaine obsolète), vous pouvez supprimer les objets avec les outils standard (tels que ADSIEdit ou le composant logiciel enfichable Utilisateurs et ordinateurs Active Directory).

Il est facile de supprimer les objets persistants pour les contextes d’affectation de noms en lecture/écriture. Dans Windows Server 2003 et versions ultérieures, vous pouvez supprimer les objets persistants à l’aide de la commande repadmin /removelingeringobjects. Pour plus d’informations sur l’utilisation de RepAdmin, consultez ID d’événement de réplication Active Directory 1388 ou 1988 : un objet persistant est détecté.

Cet article explique comment supprimer les objets persistants qui sont déjà apparus dans des contextes d’affectation de noms en lecture seule, tels que des partitions d’annuaire sur des serveurs de catalogue globaux ou des contrôleurs de domaine Read-Only (RODC). Les fonctionnalités décrites dans la section Plus d’informations existent toujours dans les systèmes d’exploitation plus récents et peuvent toujours être utiles pour résoudre les problèmes de comportement de RepAdmin inattendu.

Plus d’informations

Cette procédure nécessite l’objectGUID d’un contrôleur de domaine qui a une copie en lecture/écriture de l’objet, et l’objectGUID de l’objet lui-même. Si vous devez supprimer plusieurs objets, déterminez si l’un des objets se trouve dans une relation parent/enfant (vous pouvez le déterminer à partir des noms uniques des objets). Si c’est le cas, triez les suppressions afin que tous les objets enfants soient supprimés avant leurs objets parents.

Cette procédure comporte trois étapes principales, que vous devez effectuer sur un ordinateur qui a accès à la forêt (et vous devez utiliser un compte d’utilisateur disposant d’autorisations d’administration sur la forêt) :

  1. Obtenez le nom unique et objectGUID de l’objet persistant.
  2. Identifiez un contrôleur de domaine dans le domaine d’objet.
  3. Supprimez les objets persistants. Sélectionnez l’une des méthodes suivantes :
    • Supprimez quelques objets persistants.
    • Supprimer un grand nombre d’objets persistants.

Importante

Chaque serveur de catalogue global sur lequel vous envisagez d’exécuter les opérations de suppression (étape 3) doit disposer d’une connectivité réseau au contrôleur de domaine que vous avez identifié (étape 2).

Pour plus d’informations sur la résolution des problèmes, consultez les sections suivantes :

  • Message d’erreur lors de l’exécution de Walkservers.cmd pour modifier de nombreux objets persistants dans l’environnement.
  • Message d’erreur 87 lors de la suppression d’objets persistants dans l’environnement.

Obtenir le nom unique et objectGUID de l’objet persistant

La meilleure façon d’identifier le domaine dans lequel se trouve un objet (et à partir de là pour déterminer le nom d’un contrôleur de domaine qui a une copie en lecture/écriture de l’objet) consiste à récupérer le nom unique de l’objet. Vous pouvez rechercher le nom (ou des parties du nom) de l’objet à l’aide de l’outil Ldp.exe. Pour cela, procédez comme suit :

  1. Démarrez Ldp.exe.

    Dans la plupart des versions de Windows, sélectionnez Démarrer>exécuter et entrez ldp.exe. Dans les versions antérieures de Windows (telles que Windows Server 2003 SP1), cet outil est disponible en tant qu’outil de support.

  2. Sélectionnez Connexion>Connecter. Dans la zone Serveur , tapez le nom d’un serveur de catalogue global. Dans la zone Port , tapez 3268, puis sélectionnez OK.

  3. Sélectionnez Liaison de connexion>. Tapez des informations d’identification valides si vos informations d’identification actuelles ne sont pas suffisantes pour interroger tout le contenu du catalogue global. Sélectionnez OK.

  4. Sélectionnez Arborescence d’affichage>. Entrez le nom unique de la racine de la forêt, puis sélectionnez OK.

  5. Dans l’arborescence, cliquez avec le bouton droit sur la racine de la forêt, puis sélectionnez Rechercher.

  6. Dans la zone Filtre, tapez un filtre qui utilise l’attribut<> = <format valeur>.

    Dans le texte de filtre, <attribute> représente l’attribut d’objet à rechercher, et <value> représente les critères pour lesquels vous recherchez. Vous pouvez utiliser ***** comme caractère générique dans la valeur, et vous pouvez utiliser une expression.

    Pour plus d’informations sur la syntaxe de filtre LDAP (Lightweight Directory Access Protocol), consultez Syntaxe du filtre de recherche.

    Par exemple, pour rechercher des objets pour lesquels l’attribut sAMAccountName a une valeur testuser, tapez (sAMAccountName = testuser) dans la zone Filtre . Pour rechercher un objet utilisateur, les attributs suivants sont les plus utiles :

    • cn
    • userPrincipalName
    • Samaccountname
    • name
    • mail
    • sn

    Pour rechercher un objet de groupe, les attributs suivants sont les plus utiles :

    • cn
    • Samaccountname
    • name
  7. Sous Étendue, sélectionnez Sous-arborescence.

  8. Sélectionnez la zone Attributs , puis sélectionnez la fin de la chaîne d’attribut. Type ; objectGUID à la fin de la chaîne.

    Capture d’écran de la fenêtre De recherche avec ;objectGUID tapé à la fin de la chaîne dans la zone Attribut.

    Dans certaines versions de Ldp, vous devez sélectionner Options pour afficher la zone Attributs .

  9. Pour exécuter la requête, sélectionnez Exécuter.

    Les résultats s’affichent dans la fenêtre main Ldp.

  10. Déterminez les objets répertoriés dans les résultats, le cas échéant, qui doivent être supprimés du catalogue global. Une indication que vous avez trouvé un objet incorrect est que l’objet n’existe pas sur une copie en lecture/écriture du contexte d’affectation de noms.

  11. Si les objets que vous recherchez ne sont pas inclus dans les résultats de la requête, reformulez le filtre et réexécutez la recherche.

  12. Si vous avez identifié un objet persistant, notez les valeurs de ses attributs DN et objectGUID . Vous aurez besoin de ces valeurs ultérieurement.

Identifier un contrôleur de domaine dans le domaine d’objet

La valeur de l’attribut DN de l’objet inclut le domaine de l’objet . Lorsque vous connaissez le domaine, vous pouvez identifier un contrôleur de domaine ou un serveur de catalogue global dans le domaine. Pour cela, procédez comme suit.

  1. Vérifiez les parties dc= de la valeur DN . Combinez les parties dc= pour obtenir le nom de domaine.

    Par exemple, si un objet a la valeur DNcn=FirstName LastName,cn=Users,dc=name1,dc=name2,dc=com, l’objet se trouve dans le name1.name2.com domaine.

  2. Pour localiser un contrôleur de domaine (ou un serveur de catalogue global) dans ce domaine, ouvrez Utilisateurs et ordinateurs Active Directory, ouvrez le conteneur de domaine, puis ouvrez le conteneur Contrôleurs de domaine.

  3. Ouvrez une fenêtre d’invite de commandes avec élévation de privilèges et entrez repadmin /showreps dc-name.

    Remarque

    Dans cette commande, dc-name représente le nom d’ordinateur du contrôleur de domaine que vous avez identifié à l’étape 2.

    Dans les versions antérieures de Windows (telles que Windows Server 2003 SP1), RepAdmin est disponible en tant que l’un des outils de support.

    Repadmin produit des résultats qui ressemblent à ce qui suit :

    Default-First-Site-Name\WS2016-DC-01 DSA Options : IS_GC Site Options : (aucun) GUID d’objet DSA : <GUID> DSA invocationID : <invocationID>

  4. Notez la valeur du GUID de l’objet DSA. Il s’agit de la valeur objectGUID du contrôleur de domaine.

Supprimer des objets persistants

Utilisez les méthodes suivantes pour supprimer les objets persistants.

Supprimer quelques objets persistants de quelques serveurs de catalogue globaux

Si vous n’avez que quelques objets et catalogues globaux, procédez comme suit pour supprimer les objets à l’aide de Ldp.exe :

  1. Utilisez les informations d’identification d’administrateur d’entreprise pour vous connecter à chaque serveur de catalogue global qui contient une copie de l’objet persistant.

  2. Démarrez Ldp.exe et connectez-vous au port 389 sur le contrôleur de domaine local (laissez la zone Serveur vide).

  3. Sélectionnez Liaison de connexion>. Laissez toutes les zones vides (vous êtes déjà connecté en tant qu’administrateur d’entreprise).

  4. Sélectionnez Parcourir>Modifier.

    Capture d’écran de la fenêtre Modifier avec certaines entrées pouvant être configurées.

  5. Configurez les entrées suivantes dans la boîte de dialogue Modifier :

    1. Laissez la zone Dn vide.

    2. Dans la zone Attribut , tapez RemoveLingeringObject.

    3. Dans la zone Valeurs , tapez une valeur qui utilise le format suivant :

      <GUID=dcGUID> : <GUID=objectGUID>

      Dans cette valeur, dcGUID représente le GUID du contrôleur de domaine que vous avez identifié à l’étape 2 de cette section, et objectGUID représente le GUID de l’objet persistant que vous avez identifié à l’étape 1 de cette section.

      La valeur doit ressembler à ce qui suit :

      <GUID=<GUID>> : <GUID=<GUID>>

      Importante

      Dans la valeur , n’omettez pas les espaces avant et après le signe deux-points.

    4. Sélectionnez Opération>Remplacer, puis Entrée.

      La zone Liste des entrées affiche la commande complète.

    5. Sélectionnez Exécuter.

      Les résultats s’affichent dans la fenêtre main Ldp et doivent ressembler à ce qui suit.

      Appelez Modifier... ldap_modify_s(ld, '(null)',[1] attrs) ; Modification de « ».

Supprimer un grand nombre d’objets persistants de plusieurs serveurs de catalogue globaux

Si vous devez supprimer un grand nombre d’objets persistants, vous pouvez supprimer plus efficacement à l’aide de scripts qu’en les supprimant manuellement. Pour générer de tels scripts, procédez comme suit :

  1. Créez un dossier et, dans ce dossier, créez des fichiers qui portent les noms suivants :

    • Walkservers.cmd
    • Walkobjects.cmd
    • Modifyrootdse.vbs
    • Server-list.txt
    • fichier Object-list.txt
  2. Collez le texte suivant dans Walkservers.cmd :

    for /f %%j in (server-list.txt) do walkobjects %%j
    
  3. Collez le texte suivant dans Walkobjects.cmd :

    for /f "delims=@" %%i in (object-list.txt) do cscript //NoLogo MODIFYROOTDSE.VBS %1 "%%i" >>update-%1.log
    
  4. Collez le texte suivant dans Modifyrootdse.vbs :

    '********************************************************************
    '*
    '* File: MODIFYROOTDSE.VBS
    '* Created: January 2002
    '* Version: 1.0
    '*
    '* Main Function: Writes Active Directory information to clean up
    '* objects as per: Q314282.
    '* Usage: Modifyrootdse.vbs <TargetServer> <GUID PAIR>
    '* Parameter are fed into the script using a pair of batch files.
    '*
    '* Copyright (C) 2002 Microsoft Corporation '*
    '********************************************************************
    OPTION EXPLICIT
    ON ERROR RESUME NEXT
    
    Dim objDomain
    Dim ObjValue, strServerName, adsLdapPath
    Dim i
    
    'Get the command-line arguments
    
    if Wscript.arguments.count <> 2 Then
        Print "Invalid Number of Parameters. Use with WalkServers.CMD and WalkObjects.CMD"
        WScript.quit
    End If
    
    strServerName = Wscript.arguments.item(0)
    ObjValue = Wscript.arguments.item(1)
    
    adsLdapPath = "LDAP://" & strServerName & "/RootDSE"
    
    Set objDomain = GetObject(adsLdapPath)
        If Err.Number <> 0 Then
        WScript.Echo "Error opening ROOTDSE. Error number is: " & Err.Number & ". Error description is: " & Err.Description & "."
        Set objDomain = Nothing
        WScript.quit
    End If
    
    objDomain.Put "RemoveLingeringObject", ObjValue
    objDomain.Setinfo
    
    If Err.Number = 0 Then
        WScript.Echo "Object " & ObjValue & " was removed."
    Else
        WScript.Echo "Object " & ObjValue & " could not be removed. Error number is: " & Err.Number & ". Error description is: " & Err.Description & "."
    End If
    
    WScript.Quit
    

    Remarque

    Si vous commencez Modifyrootdse.vbs manuellement, veillez à placer entre guillemets tous les paramètres qui contiennent des espaces.

  5. Créez une liste de tous les noms de domaine complets des serveurs de catalogue global et des contrôleurs de domaine qui contiennent les objets persistants, puis collez la liste dans Server-list.txt. Utilisez les noms de domaine complets pour éviter les recherches de suffixe DNS.

  6. Pour chaque objet en attente, identifiez un contrôleur de domaine dans le domaine de l’objet qui n’a pas de copie de l’objet persistant. Il s’agit généralement d’un contrôleur de domaine qui a un contexte de nommage en lecture/écriture dans lequel vous avez supprimé manuellement l’objet persistant. Comme décrit ailleurs dans cet article, utilisez RepAdmin pour obtenir la valeur objectGUID de chaque contrôleur de domaine.

  7. Dans Object-list.txt, créez une liste de paires GUID au format suivant :

    <GUID=dcGUID> : <GUID=objectGUID>

    Remarque

    Dans cette valeur, dcGUID représente le GUID du contrôleur de domaine qui n’a pas de copie de l’objet persistant, et objectGUID représente le GUID de l’objet persistant.

    Chaque paire doit ressembler à ce qui suit :

    <GUID=<GUID>> : <GUID=<GUID>>

    Importante

    Dans la valeur , n’omettez pas les espaces avant et après le signe deux-points.

  8. Exécutez le fichier Walk-servers.cmd.

Pour chaque contrôleur de domaine ou serveur de catalogue global répertorié dans Server-list.txt, les scripts génèrent un fichier journal nommé Update-server-name.log. Chaque fichier journal contient une ligne pour chaque objet à supprimer.

Étant donné que les objets persistants n’existent pas sur tous les serveurs répertoriés, les erreurs dans les fichiers journaux n’indiquent pas nécessairement un problème. Toutefois, les messages d’erreur de l’opération de formulaire refusée ou d’une erreur d’opération indiquent qu’il existe un problème avec les GUID ou avec la syntaxe de la valeur. Si ces erreurs se produisent, vérifiez les points suivants :

  • Assurez-vous que les GUID du contrôleur de domaine sont les GUID appropriés pour les contrôleurs de domaine qui contiennent un contexte de nommage en lecture/écriture du domaine qui contient l’objet.

  • Assurez-vous que les GUID d’objet identifient les objets persistants dans les contextes d’affectation de noms en lecture seule (serveurs de catalogue global ou contrôleurs de domaine en lecture seule).

Erreur lors de l’exécution de Walkservers.cmd pour modifier de nombreux objets persistants dans l’environnement

Object <GUID=<GUID>> : <GUID=<GUID>> n’a pas pu être supprimé. Le numéro d’erreur est : -2147016672. La description de l’erreur est : .

Cause de cette erreur

Cette erreur se produit lorsque le script s’exécute sur le GUID d’un contrôleur de domaine qui ne contient pas de contexte d’affectation de noms en lecture/écriture qui correspond au contexte d’affectation de noms qui contient l’objet persistant. Vérifiez l’emplacement de l’objet persistant par l’outil Ldp.exe.

Exemple

Dans l’exemple suivant, l’objet persistant à supprimer se trouve dans le domaine corp.company.local. Toutefois, l’entrée <GUID=<GUID>> dans le fichier Objects-list.txt est associée à un contrôleur de domaine qui réside dans le domaine company.local. Ce contrôleur de domaine n’a pas de contexte de nommage en lecture/écriture pour le domaine corp.company.local.

La recherche suivante produit plusieurs objets qui représentent le même utilisateur (Joe) et répertorie leurs valeurs objectGUID .

ldap_search_s(ld, « DC=company,DC=local », 2, « (cn=User*) », attrList, 0, &msg) Résultat <0> : (null)
Noms de domaine correspondants :
Obtention de 4 entrées :
>> Dn : CN=User, Joe,OU=Exec,OU=Corporate Users,DC=corp,DC=company,DC=local
1> canonicalName : corp.company.local/Corporate Users/Exec/User, Joe ;
1> cn : Utilisateur, Joe ; 1> description : PDG ;
1> displayName : User, Joe ; 1> distinguishedName : CN=User, Joe,OU=Exec,OU=Corporate Users,DC=corp,DC=company,DC=local ; 4> objectClass : top ; person ; organizationalPerson ; user ;
1> objectGUID : <GUID> ; 1> nom : Utilisateur, Joe ;
>> Dn : CN=User, Joe,OU=Migration,DC=corp,DC=company,DC=local 1> canonicalName : corp.company.local/Migration/User, Joe ;
1> cn : Utilisateur, Joe ;
1> description : Compte désactivé ; 1> displayName : Utilisateur, Joe ; 1> distinguishedName : CN=User, Joe,OU=Migration,DC=corp,DC=company,DC=local ;
4> objectClass : top ; person ; organizationalPerson ; user ;
1> objectGUID : <GUID> ;
1> nom : Utilisateur, Joe ;

Dans cet exemple, supposons qu’il existe un contrôleur de domaine dans le domaine corp.company.local nommé CORP-DC-01. L’exécution de la commande repadmin /showreps CORP-DC-01 produit le GUID> de la valeur<objectGUID. Ce GUID remplace le GUID précédent dans le fichier Objects-list.txt. L’entrée de cet objet persistant s’affiche désormais comme suit :

<GUID=<GUID>> : <GUID=<GUID>>

Le premier GUID est le GUID du contrôleur de domaine dans le domaine corp.company.local. Le deuxième GUID est le GUID de l’objet persistant. Après cette modification, le script Walk-servers.cmd s’exécute correctement.

Message d’erreur 87 lors de la suppression d’objets persistants dans l’environnement

Cette erreur peut se produire lorsque vous constatez que les objets n’apparaissent pas sur tous les contrôleurs de domaine qui hébergent le contexte d’affectation de noms, mais repadmin /removelingeringobjects ne les suppriment pas. Il peut s’agir d’une situation où un contrôleur de domaine hub réplique de nouveaux objets qu’il a créés avec des serveurs de catalogue globaux, mais pas avec des contrôleurs de domaine en lecture/écriture réplica dans son propre domaine.

Cette erreur est retournée uniquement dans deux cas :

  • L’objet existe sur le contrôleur de domaine de référence.
  • L’objet est trop jeune (par rapport à la valeur TSL actuelle) pour durer.

Pour obtenir un exemple du deuxième cas, prenons l’exemple d’un serveur de catalogue global qui a les métadonnées suivantes :

Attribut Loc.USN Originating DC Org.USN Org.Time/Date Ver
======= =============== ========= ============= === =========
143543261 d20f71f3-6147-4f80-a0c2-470541ef09e6 104742409 <DateTime> objectClass
Vecteur de mise à jour d’un rw-réplica : d20f71f3-6147-4f80-a0c2-470541ef09e6 @ USN 104583382 @ Time <DateTime>
Vecteur de mise à jour d’un GC : d20f71f3-6147-4f80-a0c2-470541ef09e6 @ USN 104762881 @ Time <DateTime>

Dans ce cas, le contrôleur de domaine a créé l’objet après la réplication avec les contrôleurs de domaine dans son propre domaine a commencé à échouer, mais il a toujours été répliqué avec des serveurs de catalogue globaux dans d’autres domaines.

Pour résoudre ce problème, laissez ces objets devenir des objets persistants réels (anciens au-delà de TSL), puis supprimez-les à l’aide du script de cet article. Pour vous assurer que les données continuent de se répliquer, définissez Autoriser la réplication avec un partenaire divergent et corrompu sur tous les contrôleurs de domaine de la forêt.

Si vous ne pouvez pas résoudre les erreurs dans les fichiers journaux à l’aide de ces méthodes, vous rencontrez peut-être un autre problème. Pour obtenir de l’aide supplémentaire, contactez les services de support technique Microsoft.

Collecte de données

Si vous avez besoin d’aide du support Microsoft, nous vous recommandons de collecter les informations en suivant les étapes mentionnées dans Collecter des informations à l’aide de TSS pour les problèmes de réplication Active Directory.