Erreur de réplication Active Directory 8606 : Attributs insuffisants pour créer un objet

Cet article fournit de l’aide pour résoudre l’erreur de réplication Active Directory 8606 : Des attributs insuffisants ont été attribués pour créer un objet.

S’applique à : Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 2028495

Résumé

Cet article décrit les symptômes et les causes d’un problème dans lequel la réplication Active Directory échoue et génère l’erreur 8606 : « Des attributs insuffisants ont été attribués pour créer un objet. Cet objet n’existe peut-être pas, car il a peut-être été supprimé. » Cet article décrit également une résolution de ce problème.

Symptômes

Symptôme 1

Le DCDIAG signale que le test des réplications Active Directory a échoué avec l’erreur 8606 : « Des attributs insuffisants ont été attribués pour créer un objet ».

Démarrage du test : réplications
[Vérification des réplications, <Contrôleur de domaine> de destination] Une tentative de réplication récente a échoué :
Du contrôleur de <domaine> source au contrôleur de <domaine de destination>
Contexte d’affectation de noms : <chemin DN de la partition d’annuaire>
La réplication a généré une erreur (8606) :
Des attributs insuffisants ont été attribués pour créer un objet. Cet objet n’existe peut-être pas, car il a peut-être été supprimé et déjà récupéré par la mémoire
L’échec s’est produit à l’heure de la <date><>
Le dernier succès s’est produit à l’heure de <la date><>

Symptôme 2

Réplication entrante déclenchée par la commande Répliquer maintenant dans le composant logiciel enfichable Sites et services Active Directory DSSITE. Msc échoue et génère l’erreur « Des attributs insuffisants ont été attribués pour créer un objet ». Lorsque vous cliquez avec le bouton droit sur un objet de connexion à partir d’un contrôleur de domaine source, puis sélectionnez Répliquer maintenant, la réplication échoue et génère l’erreur suivante : « L’accès est refusé ». En outre, vous recevez le message d’erreur suivant :

Texte du titre de la boîte de dialogue : Répliquer maintenant
Texte du message de boîte de dialogue : L’erreur suivante s’est produite lors de la tentative de synchronisation du contexte <d’affectation de noms %nommage de partition active directory%> entre le contrôleur de domaine source> du contrôleur <de domaine et le contrôleur de domaine de destination> du contrôleur <de domaine :

Des attributs insuffisants ont été attribués pour créer un objet. Cet objet n’existe peut-être pas, car il a peut-être été supprimé et déjà récupéré par la mémoire.

L’opération ne se poursuit pas

Symptôme 3

Diverses commandes repadmin.exe échouent avec l’erreur 8606. Ces commandes incluent, sans s’y limiter, les éléments suivants :

repadmin /add repadmin /replsum
repadmin /showrepl repadmin /showrepl
repadmin /syncall

Symptôme 4

L’événement 1988 est journalisé peu après l’un des événements suivants :

• Le premier contrôleur de domaine de la forêt est déployé.
• Toute mise à jour du jeu d’attributs partiels est effectuée.

Symptôme 5

L’événement de réplication NTDS 1988 peut être enregistré dans le journal des événements du service d’annuaire des contrôleurs de domaine qui tentent de répliquer Active Directory en entrant.

Tapez : Erreur
Source : Réplication NTDS
Catégorie : Réplication
ID d’événement : 1988
Utilisateur : NT AUTHORITY\ANONYMOUS LOGON
Ordinateur : <nom d’hôte du contrôleur de domaine qui a journalisé l’événement, alias le contrôleur de domaine « destination » dans la tentative de réplication>
Description : le contrôleur de domaine local a tenté de répliquer l’objet suivant à partir du contrôleur de domaine source suivant. Cet objet n’est pas présent sur le contrôleur de domaine local, car il a peut-être été supprimé et déjà récupéré par la mémoire.
Contrôleur de domaine source :
<CNAME guidé complet du contrôleur de domaine source>
Objet:
<Chemin DN de l’objet actif sur le contrôleur de domaine source>
GUID de l’objet :
<GUID d’objet de l’objet sur la copie des contrôleurs de domaine source d’Active Directory>

Cause

L’erreur 8606 est enregistrée lorsque les conditions suivantes sont remplies :

• Un contrôleur de domaine source envoie une mise à jour à un objet (au lieu d’une création d’objet d’origine) qui a déjà été créé, supprimé, puis récupéré par garbage collection à partir de la copie active Directory d’un contrôleur de domaine de destination.
• Le contrôleur de domaine de destination a été configuré pour s’exécuter dans une cohérence de réplication stricte.

Si le contrôleur de domaine de destination a été configuré pour utiliser une cohérence de réplication faible, l’objet aurait été « réanimé » sur la copie du répertoire du contrôleur de domaine de destination. Les variantes spécifiques qui peuvent entraîner une erreur sont documentées dans la section « Plus d’informations ». Toutefois, l’erreur est due à l’une des causes suivantes :

• Objet persistant de façon permanente dont la suppression nécessite une intervention de l’administrateur
• Objet temporaire persistant qui se corrige lui-même lorsque le contrôleur de domaine source effectue son nettoyage de garbage collection suivant. L’introduction du premier contrôleur de domaine dans une forêt existante et les mises à jour du jeu d’attributs partiels sont des causes connues de cette condition.
• Objet qui a été supprimé ou restauré au moment de l’expiration de la durée de vie de la pierre tombstone

Lorsque vous résolvez les erreurs 8606, réfléchissez aux points suivants :

• Bien que l’erreur 8606 soit enregistrée sur le contrôleur de domaine de destination, l’objet de problème qui bloque la réplication réside sur le contrôleur de domaine source. En outre, le contrôleur de domaine source ou un partenaire de réplication transitive du contrôleur de domaine source n’a potentiellement pas répliqué la connaissance entrante d’un nombre de jours de durée de vie de la pierre tombstone supprimée dans le passé.

• Des objets persistants peuvent exister dans les circonstances suivantes :

  • En tant qu’objets « actifs », en tant qu’objets « actifs » CNF ou en tant qu’objets « dynamiques » entre les conflits ou les objets CNF dans le conteneur d’objets supprimés du contrôleur de domaine source
  • Dans n’importe quelle partition de répertoire, à l’exception de la partition de schéma. Les objets persistants sont le plus fréquemment trouvés dans les partitions de domaine en lecture seule sur les contrôleurs de groupe. Des objets persistants peuvent également exister dans les partitions de domaine accessibles en écriture, ainsi que dans la partition de configuration. La partition de schéma ne prend pas en charge les suppressions.
  • Dans n’importe quelle classe d’objet (les utilisateurs, ordinateurs, groupes et enregistrements DNS sont les plus courants).

• N’oubliez pas de rechercher des objets potentiellement persistants par GUID d’objet ou chemin DN afin que les objets puissent être trouvés indépendamment de leur partition hôte et de leur conteneur parent. La recherche par objectguid permet également de localiser les objets qui se trouvent dans le conteneur d’objets supprimés sans utiliser le contrôle LDAP des objets supprimés.

• L’événement NTDS Replication 1988 identifie uniquement l’objet actuel sur le contrôleur de domaine source qui bloque la réplication entrante par un contrôleur de domaine de destination en mode strict. Il y a probablement des objets supplémentaires « derrière » l’objet référencé dans l’événement 1988 qui est également en cours.

• La présence d’objets persistants sur un contrôleur de domaine source empêche ou bloque les contrôleurs de domaine de destination en mode strict de répliquer les « bonnes » modifications entrantes qui existent derrière l’objet persistant dans la file d’attente de réplication.

• En raison de la façon dont les contrôleurs de domaine suppriment individuellement des objets de leurs conteneurs d’objets supprimés (le démon de nettoyage de la mémoire s’exécute toutes les 12 heures à compter du dernier démarrage de chaque contrôleur de domaine), les objets qui provoquent des erreurs 8606 sur les contrôleurs de domaine de destination peuvent être supprimés lors de la prochaine exécution du nettoyage de la mémoire. Les objets persistants de cette classe sont temporaires et ne doivent pas être supprimés dans plus de 12 heures à compter du début du problème.

• L’objet en question est probablement un objet qui a été supprimé intentionnellement par un administrateur ou une application. Tenez compte de cela dans votre plan de résolution, et méfiez-vous de la réanimation des objets, en particulier des principaux de sécurité qui ont été supprimés intentionnellement. Résolution

Résolution

1. Identifiez la valeur actuelle pour le paramètre TombStoneLifeTime à l’échelle de la forêt.

   repadmin /showattr "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=forest root domain,DC=TLD" /atts:tombstonelifetime  
   

   Consultez la section « Durée de vie de Tombstone et réplication des suppressions » dans l’article suivant de la Base de connaissances Microsoft :
   910205 Informations sur les objets persistants dans une forêt Windows Server Active Directory.

2. Pour chaque contrôleur de domaine de destination qui enregistre l’erreur 8606, filtrez le journal des événements du service d’annuaire sur l’événement de réplication NTDS 1988.

3. Collectez des métadonnées pour chaque objet unique cité dans l’événement de réplication NTDS 1988. À partir de chaque événement 1988 enregistré sur le contrôleur de domaine de destination qui cite un nouvel objet, renseignez le tableau suivant :

   Chemin d’accès d’un nom de domaine d’objet	GUID d’objet	Contrôleur de domaine source	Partition hôte	En direct ou supprimé ?	LastKnownParent	Valeur IsDeleted

   Les colonnes 1 à 5 de cette table peuvent être remplies en lisant les valeurs directement à partir des champs des événements de réplication NTDS 1988 qui sont enregistrés dans les journaux des événements du service d’annuaire des contrôleurs de domaine de destination qui journalisent l’événement 1988 ou le status de réplication 8606.

   Les horodatages des colonnes LastKnownParent et IsDeleted peuvent être déterminés en exécutant repadmin /showobjmeta et en référençant l’objectguid de l’objet cité dans l’événement de réplication NTDS 1988. Pour ce faire, utilisez la syntaxe suivante :

   repadmin /showobjmeta <fqdn of source DC from 1988 event> "<GUID=GUID of object cited in the 1988 event>"
   

   L’horodatage de LastKnownParent identifie la date à laquelle l’objet a été supprimé. L’horodatage pour IsDeleted vous indique quand l’objet a été supprimé ou réanimé pour la dernière fois. Le numéro de version vous indique si la dernière modification a supprimé ou réanimé l’objet. Une valeur IsDeleteted de 1 représente une suppression initiale. Les valeurs impaires supérieures à 1 indiquent une réanimation après au moins une suppression. Par exemple, une valeur isDeleted de 2 représente un objet qui a été supprimé (version 1), puis qui a été supprimé ou réanimé ultérieurement (version 2). Les valeurs paires ultérieures pour IsDeleted représentent des réanimations ou des suppressions ultérieures de l’objet.

4. Sélectionnez l’action appropriée en fonction des métadonnées d’objet citées dans l’événement 1988.

   L’erreur 8606 /NTDS L’événement de réplication 1988 est le plus fréquemment dû à des échecs de réplication à long terme qui empêchent les contrôleurs de domaine de se répliqués entrants de connaître toutes les suppressions d’origine dans la forêt. Il en résulte des objets persistants sur un ou plusieurs contrôleurs de domaine source.

   Passez en revue les métadonnées de l’objet répertorié dans la table créée à l’étape 4 de la section « Résolution ».

   Si l’objet dans l’événement 1988 est ((en direct sur le contrôleur de domaine source), mais (supprimé sur le contrôleur de domaine de destination pour une durée de vie plus longue que l’expiration de la durée de vie tombstone),consultez « Suppression d’objets persistants » et « ». Les objets dans cette condition doivent être supprimés manuellement par un administrateur.

   Les objets supprimés peuvent avoir été supprimés prématurément du conteneur d’objets supprimés si le temps système a été dépassé dans le temps sur le contrôleur de domaine de destination. Passez en revue la section « Vérifier les sauts temporels ».

   Si l’objet cité dans l’événement 1988 existe dans le conteneur d’objets supprimés du contrôleur de domaine source et que sa date de suppression est juste au moment de l’expiration de la durée de vie de la pierre tombstone, de sorte que l’objet a été récupéré par le garbage collection par un ou plusieurs contrôleurs de domaine de destination et qu’il sera récupéré par le garbage collection à l’intervalle suivant sur les contrôleurs de domaine source (autrement dit, les objets persistants sont temporaires), vous avez le choix. Attendez l’exécution suivante du garbage collection pour supprimer l’objet, ou déclenchez manuellement le garbage collection sur le contrôleur de domaine source. Consultez « Démarrage manuel du garbage collection ». L’introduction du premier contrôleur de domaine, ou toute modification apportée au jeu d’attributs partiels, peut entraîner cette condition.

   Si repadmin /showobjmeta la sortie de l’objet cité dans l’événement 1988 a une valeur LastKnownParent égale à 1, cela indique que l’objet a été supprimé et qu’une valeur IsDeleted égale à 2 ou une autre valeur paire, et que l’horodatage pour IsDeleted est à la pointe du nombre de jours de durée de vie de la pierre tombstone différent de l’horodatage de LastKnownParent, ensuite, l’objet a été supprimé, puis non supprimé /auth-restauré alors qu’il était toujours actif sur le contrôleur de domaine source, mais déjà récupéré par garbage collection par les contrôleurs de domaine de destination, erreur de journalisation 8606 / Événement 1988. Consultez Réanimations au moment de l’expiration du TSL

Comment supprimer des objets persistants

Bien qu’il existe de nombreuses méthodes pour supprimer les objets persistants, il existe trois outils principaux couramment utilisés : repadmin.exe, LoL (Lingering Object Liquidator) et repldiag.

Lingering Object Liquidator (LoL)

La méthode la plus simple pour propre objets persistants consiste à utiliser la loL. L’outil LoL a été développé pour aider à automatiser le processus de nettoyage par rapport à une forêt Active Directory. L’outil est basé sur l’interface graphique utilisateur et peut analyser la forêt Active Directory active et détecter et nettoyer les objets persistants. L’outil est disponible dans le Centre de téléchargement Microsoft.

Repadmin

Les deux commandes suivantes dans repadmin.exe peuvent supprimer les objets persistants des partitions d’annuaire :

• repadmin /removelingeringobjects
• repadmin /rehost

La repadmin /removelingeringobjects commande peut être utilisée pour supprimer les objets persistants des partitions de répertoire accessibles en écriture et en lecture seule sur les contrôleurs de domaine source. La syntaxe est la suivante :

repadmin /removelingeringobjects <Dest_DSA_LIST> <Source DSA GUID> <NC> [/ADVISORY_MODE]

Où :
<> Dest_DSA_LIST est le nom d’un contrôleur de domaine qui contient des objets persistants (par exemple, le contrôleur de domaine source cité dans l’événement NTDS Replication 1988).

<LE GUID> DSA source est le nom d’un contrôleur de domaine qui héberge une copie accessible en écriture de la partition de répertoire qui contient des objets persistants auxquels le contrôleur de domaine dans <Dest_DSA_LIST> a une connectivité réseau. Le contrôleur de domaine à nettoyer (premier contrôleur de domaine spécifié dans la commande) doit être en mesure de se connecter directement au port 389 sur le contrôleur de domaine qui héberge une copie accessible en écriture de la partition de répertoire (spécifiée en deuxième position dans la commande).

<NC> est le chemin d’accès DN de la partition de répertoire qui est soupçonnée de contenir des objets persistants, comme la partition spécifiée dans un événement 1988.

La repadmin /rehost commande peut être utilisée pour supprimer des contrôleurs de domaine d’objets persistants qui hébergent une copie en lecture seule d’une partition d’annuaire de domaine des contrôleurs de domaine. La syntaxe est la suivante :

repadmin /rehost DSA <Naming Context> <Good Source DSA Address>

Où :
DSA est le nom d’un contrôleur de domaine qui héberge une partition d’annuaire de domaine en lecture seule pour un domaine non local. Par exemple, un gc dans root.contoso.com peut réhéberger sa copie en lecture seule de child.contoso.com, mais ne peut pas réhéberger root.contoso.com.

<Naming Context> est le chemin d’accès DN d’une partition de répertoire de domaine en lecture seule qui réside dans un catalogue global.

<Une bonne adresse> DSA source est le nom d’un contrôleur de domaine qui héberge une copie accessible en écriture du contexte> d’affectation de <noms. Le contrôleur de domaine doit être disponible sur l’ordinateur DSA.

Si l’objet persistant signalé dans l’événement 1988 n’est pas supprimé par repadmin, évaluez si l’objet sur le contrôleur de domaine source a été créé dans l’intervalle USN ou si les objets à l’origine du contrôleur de domaine n’existent pas dans le vecteur à jour du contrôleur de domaine source.

Repldiag

Lancez le labo TechNet à la demande suivant pour la pratique de résolution guidée de ce problème et d’autres erreurs de réplication AD :

Dans le labo, vous utilisez repadmin et repldiag.exe pour supprimer les objets persistants
Résolution des erreurs de réplication Active Directory
Dans ce labo, vous allez parcourir les phases de résolution des problèmes, d’analyse et d’implémentation des erreurs de réplication Active Directory fréquemment rencontrées. Vous allez utiliser une combinaison d’ADREPLSTATUS, repadmin.exeet d’autres outils pour résoudre les problèmes d’un environnement à cinq contrôleurs de domaine et à trois domaines. Les erreurs de réplication AD rencontrées dans le laboratoire incluent -2146893022, 1256, 1908, 8453 et 8606. »

Surveillance quotidienne de l’intégrité de la réplication Active Directory

Si l’erreur 8606/événement 1988 a été provoquée par l’échec du contrôleur de domaine à répliquer les modifications d’Active Directory au cours du dernier nombre de jours de durée de vie tombstone, assurez-vous que l’intégrité de la réplication Active Directory est surveillée au jour le jour. L’intégrité de la réplication peut être surveillée à l’aide d’une application de supervision dédiée ou en affichant la sortie de la seule option économique mais efficace pour exécuter repadmin /showrepl * /csv la commande dans une application de feuille de calcul telle que Microsoft Excel. (Consultez « Méthode 2 : Surveiller la réplication à l’aide d’une ligne de commande » dans l’article 910205 de la Base de connaissances Microsoft).

Les contrôleurs de domaine qui n’ont pas été répliqués entrants dans 50 % du nombre de jours de durée de vie tombstone doivent être placés dans une liste watch qui reçoivent une attention prioritaire de l’administrateur pour rendre la réplication opérationnelle. Les contrôleurs de domaine qui ne peuvent pas être correctement répliqués doivent être rétrogradés de force s’ils n’ont pas été répliqués dans un délai de 90 % de TSL.

Les échecs de réplication qui apparaissent sur un contrôleur de domaine de destination peuvent être causés par le contrôleur de domaine de destination, par le contrôleur de domaine source ou par le réseau sous-jacent et l’infrastructure DNS.

Vérifier les sauts de temps

Pour déterminer si un saut de temps s’est produit, case activée des horodatages dans les journaux d’événements et de diagnostic (observateur d'événements, repadmin /showreps, journaux netlogon, rapports dcdiag) sur les contrôleurs de domaine de destination qui enregistrent l’erreur 8606 /NTDS Replication 1988 événements pour les éléments suivants :

• Horodatages antérieurs à la publication d’un système d’exploitation (par exemple, les horodatages de CY 2003 pour un système d’exploitation publié dans CY 2008)
• Horodatages antérieurs à l’installation du système d’exploitation dans votre forêt
• Horodatages à l’avenir
• Aucun événement enregistré dans une plage de dates donnée

Support Microsoft équipes ont vu le temps système sur les contrôleurs de domaine de production sauter incorrectement des heures, des jours, des semaines, des années et même des dizaines d’années dans le passé et à l’avenir. Si l’heure système s’est avéré inexacte, vous devez la corriger, puis essayer de déterminer pourquoi le temps a sauté et ce qui peut être fait pour empêcher l’heure inexacte d’aller de l’avant et de simplement corriger le mauvais moment. Les questions possibles sont les suivantes :

• Le contrôleur de domaine principal de la forêt racine a-t-il été configuré à l’aide d’une source de temps externe ?
• Les sources de temps en ligne de référence sont-elles disponibles sur le réseau et peuvent-elles être résolues dans DNS ?
• Le service de temps Microsoft ou tiers était-il en cours d’exécution et dans un état sans erreur ?
• Les ordinateurs de rôle contrôleur de domaine sont-ils configurés pour utiliser la hiérarchie NT5DS pour l’heure source ?
• La protection contre la restauration du temps décrite dans l’article de la Base de connaissances Microsoft a-t-elle été 884776 en place ?
• Les horloges système ont-elles de bonnes batteries et une heure précise dans le BIOS sur les contrôleurs de domaine sur les ordinateurs hôtes virtuels ?
• Les ordinateurs hôtes virtuels et invités sont-ils configurés pour l’heure source conformément aux recommandations du fabricant de l’hébergement ?
  L’article de la Base de connaissances Microsoft 884776 décrit les étapes à suivre pour protéger les contrôleurs de domaine contre « l’écoute » d’exemples de temps non valides. Pour plus d’informations sur MaxPosPhaseCorrection et MaxNegPhaseCorrection, consultez le billet de blog W32Time Service de temps Windows.

Recherchez les objets persistants à l’aide repadmin /removelingeringobjects /advisorymodede , puis supprimez-les si nécessaire.

Assouplissez « Autoriser la réplication avec un partenaire divergent et corrompu » si nécessaire.

Guide pratique pour démarrer manuellement le garbage collection

Plusieurs options existent pour déclencher manuellement le garbage collection sur un contrôleur de domaine spécifique :

Exécutez " repadmin /setattr «  » «  » doGarbageCollection add 1 »

Exécutez LDIFDE /s <server> /i /f dogarbage.ldif où dobarbage.ldif contient le texte :

Dn:
changetype : modifier
replace : DoGarbageCollection
dogarbagecollection : 1
-

Réanimations au moment de l’expiration TSL

Pour que cette condition existe, repadmin /showobject "<GUID=object guid for object in 1988 event>" doit signaler que l’objet est « introuvable » sur le contrôleur de domaine de destination, mais qu’il est actif sur le contrôleur de domaine source et qu’il s’agit d’un objet supprimé ou non supprimé.

Un examen des champs clés du repadmin /showobjmeta contrôleur de domaine source doit indiquer que les conditions suivantes sont vraies : LastKnownParent a la valeur 1 et son horodatage est à la pointe des jours TSL dans le passé. Son horodatage indique la date de suppression de l’objet.

IsDeleted a un numéro de version 2 (ou une autre valeur paire), où la version 1 a défini la suppression d’origine et la version 2 est la restauration/réanimation. L’horodatage de « isDeleted=2 » doit être ~ le nombre de jours TSL postérieur à la date de dernière modification de LastKnownParent.

Évaluer si l’objet en question doit rester un objet actif ou un objet supprimé. Si LastKnownParent a la valeur 1, quelque chose ou quelqu’un a supprimé l’objet. S’il ne s’agit pas d’une suppression accidentelle , il est probable que l’objet soit supprimé de tous les contrôleurs de domaine source qui ont une copie dynamique de l’objet.

Si l’objet doit exister sur tous les réplicas, les options sont les suivantes :

• Activez la réplication libre sur les contrôleurs de domaine de destination en mode strict qui n’ont pas l’objet .
• Rétrogradez de force les contrôleurs de domaine qui ont déjà récupéré la mémoire de l’objet.
• Supprimez l’objet, puis recréez-le.

Plus d’informations

Lancez le labo TechNet à la demande suivant pour la pratique de résolution guidée de ce problème et d’autres erreurs de réplication AD :

Résolution des erreurs de réplication Active Directory
Dans ce labo, vous allez parcourir les phases de résolution des problèmes, d’analyse et d’implémentation des erreurs de réplication Active Directory fréquemment rencontrées. Vous allez utiliser une combinaison d’ADREPLSTATUS, repadmin.exeet d’autres outils pour résoudre les problèmes d’un environnement à cinq contrôleurs de domaine et à trois domaines. Les erreurs de réplication AD rencontrées dans le laboratoire incluent -2146893022, 1256, 1908, 8453 et 8606. »

Causes des objets persistants

Cause 1 : Le contrôleur de domaine source envoie des mises à jour aux objets qui ont déjà été récupérés par garbage collection sur le contrôleur de domaine de destination, car le contrôleur de domaine source était hors connexion ou a échoué pour le nombre de jours écoulés TSL

Le CONTOSO.COM domaine contient deux contrôleurs de domaine dans le même domaine. Durée de vie de la pierre tombale = 60 jours. La réplication stricte est activée sur les deux contrôleurs de domaine. DC2 subit une défaillance de carte mère. Pendant ce temps, DC1 effectue quotidiennement des suppressions d’origine pour les groupes de sécurité obsolètes au cours des 90 prochains jours. Une fois qu’il est hors connexion pendant 90 jours, DC2 reçoit une carte mère de remplacement, met sous tension, puis génère une modification DACL ou SACL sur tous les comptes d’utilisateur avant qu’il ne réplique la connaissance des suppressions d’origine de DC1. DC1 enregistre les erreurs 8606 pour les mises à jour des groupes de sécurité qui sont vidés sur DC1 pendant les 30 premiers jours pendant lesquels DC2 était hors connexion.

Cause 2 : Le contrôleur de domaine source envoie des mises à jour aux objets au moment de l’expiration TSL qui ont déjà été récupérés par le garbage collection par un contrôleur de domaine de destination en mode strict

Le CONTOSO.COM domaine contient deux contrôleurs de domaine dans le même domaine. Durée de vie de la pierre tombale = 60 jours. La réplication stricte est activée sur les deux contrôleurs de domaine. DC1 et DC2 sont répliqués toutes les 24 heures. DC1 provient-supprime quotidiennement. DC1 est mis à niveau sur place. Cela marque le nouvel attribut sur tous les objets dans les partitions de domaine de configuration et accessibles en écriture. Cela inclut les objets qui se trouvent actuellement dans le conteneur d’objets supprimés. Certains d’entre eux ont été supprimés il y a 60 jours et sont maintenant à l’approche de l’expiration de la pierre tombstone. DC2 récupère certains objets par garbage collection qui ont été supprimés TSL il y a quelques jours avant l’ouverture de la planification de la réplication avec DC2. L’erreur 8606 est enregistrée jusqu’à ce que DC1 récupère les objets bloquants par garbage collection.

Toute mise à jour du jeu d’attributs partiels peut entraîner des objets temporaires persistants qui s’effacent après que les contrôleurs de domaine source collectent les objets supprimés au moment de l’expiration du TSL (par exemple, l’ajout du premier contrôleur de domaine W2K8 R2 à une forêt existante).

Cause 3 : Un saut de temps sur un contrôleur de domaine de destination accélère prématurément le garbage collection des objets supprimés sur un contrôleur de domaine de destination

Le CONTOSO.COM domaine contient deux contrôleurs de domaine dans le même domaine. Durée de vie de la pierre tombale = 60 jours. La réplication stricte est activée sur les deux contrôleurs de domaine. DC1 et DC2 sont répliqués toutes les 24 heures. DC1 est à l’origine des suppressions quotidiennes. La source d’heure de référence utilisée par DC1 (mais pas PAR DC2) est transférée à l’année civile 2039. Cela oblige DC2 à utiliser également une heure système dans CY2039. Cela amène DC1 à supprimer prématurément les objets qui sont supprimés aujourd’hui de son conteneur d’objets supprimés. Pendant ce temps, DC2 est à l’origine des modifications apportées aux attributs sur les utilisateurs, ordinateurs et groupes qui sont en direct sur DC2, mais supprimés et qui sont désormais prématurément récupérés par la mémoire sur DC1. DC1 journalise l’erreur 8606 lorsqu’il réplique ensuite les modifications entrantes pour les objets supprimés prématurément.

Cause 4 : Un objet est réanimé au moment de l’expiration du TSL

Le CONTOSO.COM domaine contient deux contrôleurs de domaine dans le même domaine. Durée de vie de la pierre tombale = 60 jours. La réplication stricte est activée sur les deux contrôleurs de domaine. DC1 et DC2 sont répliqués toutes les 24 heures. DC1 est à l’origine des suppressions quotidiennes. Une unité d’organisation qui contient des utilisateurs, des ordinateurs et des groupes est supprimée accidentellement. Une sauvegarde de l’état du système effectuée à la pointe de TSL dans le passé est restaurée sur DC2. La sauvegarde contient des objets qui sont actifs sur DC2, mais qui ont déjà été supprimés et récupérés par le garbage collection sur DC1.

Cause 5 : Une bulle USN est déclenchée par la journalisation du 8606

Supposons que vous créez un objet dans une bulle USN de telle sorte qu’il ne soit pas répliqué sortant, car le contrôleur de domaine de destination « pense » qu’il a l’objet en raison de la bulle. Maintenant, une fois la bulle fermée et une fois que les modifications ont commencé à se répliquer à nouveau, une modification est créée pour cet objet sur le contrôleur de domaine source et est affichée en tant qu’objet persistant pour le contrôleur de domaine de destination. Le contrôleur de destination enregistre l’événement 8606.

Conditions requises pour la réplication de bout en bout des suppressions d’origine

Les contrôleurs de domaine Active Directory prennent en charge la réplication multi master où n’importe quel contrôleur de domaine (qui contient une partition accessible en écriture) peut créer, modifier ou supprimer un objet ou un attribut (valeur). La connaissance des suppressions d’objets/attributs est conservée par le contrôleur de domaine d’origine et tout contrôleur de domaine qui a une connaissance répliquée entrante d’une suppression d’origine pendant le nombre de jours TSL. (Consultez les articles de la Base de connaissances Microsoft 216996 et 910205)

Active Directory nécessite une réplication de bout en bout de tous les détenteurs de partition pour répliquer de manière transitive toutes les suppressions d’origine de toutes les partitions d’annuaire vers tous les détenteurs de partition. L’échec de la réplication entrante d’une partition de répertoire dans un nombre de jours TSL propagé entraîne la persistance d’objets. Un objet persistant est un objet qui a été supprimé intentionnellement par au moins un contrôleur de domaine, mais qui n’existe pas correctement sur les contrôleurs de domaine de destination qui n’ont pas répliqué la connaissance temporaire de toutes les suppressions uniques.

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.