Erreur de réplication Active Directory 8606 : des attributs insuffisants ont été attribués 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 ko d’origine :   2028495

Notes

Accueil des utilisateurs : Cet article est destiné uniquement aux agents de support technique et aux professionnels de l’informatique. Si vous recherchez de l’aide sur un problème, demandez à l’CommunityMicrosoft.

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

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

Test de démarrage : réplications
[Vérification des réplications, <Destination DC> ] Une tentative de réplication récente a échoué :
De <source DC> à <destination DC>
Contexte d’attribution de noms : <directory partition DN path>
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à collecté la garbage
L’échec s’est produit à <date> <time>
Le dernier succès s’est produit à l' <date> <time>

Symptôme 2

Réplication entrante déclenchée par la commande Répliquer maintenant dans le logiciel en ligne DSSITE (Sites et services Active Directory). Le 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 dc 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, le message d’erreur suivant s’affiche :

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’attribution de noms <%nom de partition Active Directory%> du contrôleur de domaine au contrôleur de <source DC> domaine <destination DC> :

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à collecté la garbage.

L’opération ne se poursuit pas

Symptôme 3

Diverses REPADMIN.EXE de commande é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 consigné peu de temps 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 partiel est réalisé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 entrante.

Tapez : Erreur
Source : réplication NTDS
Catégorie : Réplication
ID d’événement : 1988
Utilisateur : NT AUTHORITY\ANONYMOUS LOGON
Ordinateur : <hostname of DC that logged event, aka the "destination" DC in the replication attempt>
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à collecté la garbage.
Contrôleur de domaine source :
<fully qualified GUIDED CNAME of source DC>
Objet :
<DN path of live object on source DC>
GUID d’objet :
<object GUID of object on source DCs copy of Active Directory>

Cause

L’erreur 8606 est consignée lorsque les conditions suivantes sont vraies :

  • 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 le 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 la cohérence de réplication souple, 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 provoquer une erreur sont 8606 documentées dans la section « Plus d’informations ». Toutefois, l’erreur est due à l’une des raisons suivantes :

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

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

  • Bien que l’erreur 8606 soit consignée sur le contrôleur de domaine de destination, l’objet 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 transitif du contrôleur de domaine source n’a potentiellement pas pu répliquer entrante connaissance d’un nombre de jours de durée de vie de tombstone supprimé dans le passé.

  • Les objets en attente peuvent exister dans les circonstances suivantes :

    • En tant qu’objets « live », en tant qu’objets CNF ou en conflit mangled « live » ou en tant qu’objets CNF ou en conflit mangled dans le conteneur d’objets supprimés du contrôleur de domaine source
    • Dans n’importe quelle partition d’annuaire à l’exception de la partition de schéma. Les objets en attente sont le plus souvent trouvés dans les partitions de domaine en lecture seule sur les GCs. Les objets en attente peuvent également exister dans les partitions de domaine accessibles en writables 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, les ordinateurs, les groupes et les enregistrements DNS sont les plus courants).
  • N’oubliez pas de rechercher des objets potentiellement en attente par GUID d’objet ou chemin d’accès DN afin que les objets soient trouvés indépendamment de leur partition hôte et conteneur parent. La recherche par objectguid permet également de localiser les objets qui se trouve 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 existe probablement d’autres objets « derrière » l’objet référencé dans l’événement 1988 qui est également en attente.

  • La présence d’objets en attente 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 se cachent derrière l’objet en attente 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 daemon de nettoyage de la garbage-collection s’exécute toutes les 12 heures à partir de la dernière exécution de chaque contrôleur de domaine), les objets qui provoquent 8606 erreurs sur les contrôleurs de domaine de destination peuvent être supprimés lors de la prochaine exécution de nettoyage du nettoyage de la garbage-collection. Les objets en attente dans cette classe sont temporaires et doivent se supprimer eux-mêmes dans un peu plus de 12 heures après le début du problème.

  • L’objet en question en question est probablement un objet qui a été intentionnellement supprimé par un administrateur ou une application. Factorez-le dans votre plan de résolution et prenez garde à la réanimation des objets, en particulier les 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.

     c:\>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 et réplication de suppressions de Tombstone » dans l’article suivant de la Base de connaissances Microsoft :
    910205 informations sur les objets en attente dans Windows Server Active Directory forêt.

  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. Collecter des métadonnées pour chaque objet unique mentionné 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 mentionne un nouvel objet, remplir le tableau suivant :

    Chemin d’accès DN de l’objet GUID d’objet Source DC Partition hôte En direct ou supprimé ? LastKnownParent Valeur IsDeleted

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

    Les cachets de date pour les colonnes LastKnownParent et IsDeleted peuvent être déterminés en exécutant et en référençant l’objet qui est mentionné dans l’événement 1988 de réplication repadmin /showobjmeta NTDS. Pour ce faire, utilisez la syntaxe suivante :

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

    Le cachet de date de LastKnownParent identifie la date à laquelle l’objet a été supprimé. Le cachet de date pour IsDeleted vous indique à quel moment 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érieure à 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 est ensuite supprimé ou réanimé (version 2). Les valeurs de type even-numbered ultérieures pour IsDeleted représentent des animations ou des suppressions ultérieures de l’objet.

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

    L’erreur 8606 / événement de réplication NTDS 1988 est le plus souvent dû à des échecs de réplication à long terme qui empêchent les contrôleurs de domaine de réplication entrante de toutes les suppressions d’origine dans la forêt. Cela entraîne des objets en attente sur un ou plusieurs contrôleurs de domaine source.

    Examinez les métadonnées de l’objet répertorié dans le tableau créé à l’étape 4 de la section « Résolution ».

    Si l’objet de l’événement 1988 est soit ((live 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 de tombstone), voir « Suppression des objets en attente » et « ». Les objets dans cette condition doivent être supprimés manuellement par un administrateur.

    Les objets supprimés ont peut-être été supprimés prématurément du conteneur d’objets supprimés si le temps système a avancé dans le temps sur le contrôleur de domaine de destination. Consultez la section « Vérifier les sauts de temps ».

    Si l’objet mentionné 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 se trouve juste au moment de l’expiration de la durée de vie de tombstone de telle 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 lors de l’intervalle suivant du garbage-collection sur les contrôleurs de domaine source (c’est-à-dire, les objets en attente sont temporaires), vous avez le choix. Attendez la prochaine exécution du garbage collection pour supprimer l’objet ou déclenchez manuellement le garbage collection sur le contrôleur de domaine source. Voir « Démarrage manuel du collecte de la garbage ». L’introduction du premier contrôleur de domaine ou toute modification du jeu d’attributs partiels peut provoquer cette condition.

    Si la sortie de l’objet mentionné dans l’événement 1988 a une valeur LastKnownParent de 1, cela indique que l’objet a été supprimé et qu’une valeur IsDeleted est de 2 ou une autre valeur numérotée, et que le cachet de date pour IsDeleted est au niveau de la cusp du nombre de jours de durée de vie de tombstone différent du cachet de date pour repadmin /showobjmeta LastKnownParent, l’objet a ensuite été supprimé, puis supprimé /auth-restored alors qu’il était toujours en cours sur le contrôleur de domaine source, mais déjà récupéré par le garbage collection par les contrôleurs de domaine de destination, erreur de journalisation 8606 / Événement 1988. Voir Reanimations à la fin de l’expiration de TSL

Comment supprimer des objets en attente

Bien qu’il existe de nombreuses méthodes pour supprimer les objets en attente, il existe trois outils principaux couramment utilisés : repadmin.exe, Outils d’objets en attente (LoL) et repldiag.

Entâmateur d’objets en attente (LoL)

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

Repadmin

Les deux commandes suivantes peuvent REPADMIN.EXE objets en attente des partitions d’annuaire :

  • REPADMIN /REMOVELINGERINGOBJECTS
  • REPADMIN /REHOST

REPADMIN /REMOVELINGERINGOBJCTS permet de supprimer les objets en attente des partitions d’annuaire accessibles en lecture seule et accessibles en lecture seule sur les contrôleurs de domaine source. La syntaxe est la suivante :

c:\>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 en attente (comme le contrôleur de domaine source mentionné dans l’événement NTDS Replication 1988).

<Source DSA GUID> est le nom d’un contrôleur de domaine qui héberge une copie accessible en texte de la partition d’annuaire qui contient les objets en attente pour lesquels le contrôleur de domaine dans <Dest_DSA_LIST> dispose d’une connectivité réseau. Le dc à nettoyer (premier DC spécifié dans la commande) doit être en mesure de se connecter directement au port 389 sur le dc qui héberge une copie accessible en ligne de la partition d’annuaire (spécifiée en deuxième position dans la commande).

<NC> est le chemin d’accès DN de la partition d’annuaire qui est suspecté de contenir des objets en attente, tels que la partition spécifiée dans un événement 1988.

REPADMIN /REHOSTpermet de supprimer des contrôleurs de domaine d’objets en attente qui hébergent une copie en lecture seule d’une partition d’annuaire de domaines des contrôleurs de domaine. La syntaxe est la suivante :

 c:\>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 de répertoire de domaine en lecture seule pour un domaine nonlocal. Par exemple, un gc dans root.contoso.com peut réhost sa copie en lecture seule de child.contoso.com mais ne peut pas root.contoso.com.

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

<Good Source DSA Address> est le nom d’un contrôleur de domaine qui héberge une copie accessible en texte de <Naming Context> . Le contrôleur de domaine doit être disponible sur le réseau pour l’ordinateur de la DSA.

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

Repldiag

Notes

Les objets en attente peuvent également être supprimés à l’aide repldiag.exe. Cet outil automatise le repadmin /removelingeringobjects processus. La suppression d’objets en attente d’une forêt avec repldiag est aussi simple que repldiag /removelingeringobjects l’exécution. Toutefois, il est généralement préférable d’exercer un contrôle sur le processus dans des environnements plus grands. L’option /OverRideReferenceDC vous permet de sélectionner le dc utilisé pour le nettoyage. L’option vous permet de voir à quoi ressemble un nettoyage à l’échelle de la forêt /outputrepadmincommandlinesyntax à l’aide du repadmin.

Lancez le laboratoire TechNet à la demande suivant pour une pratique de dépannage guidée de cette erreur et d’autres erreurs de réplication AD :

Dans l’atelier, vous utilisez à la fois le repadmin et lerepldiag.exe pour supprimer les objets en attente
Résolution des erreurs de réplication Active Directory
Dans ce laboratoire, vous allez parcourir les phases de dépannage, d’analyse et d’implémentation des erreurs de réplication Active Directory couramment rencontrées. Vous utiliserez une combinaison d’outils ADREPLSTATUS, repadmin.exe et d’autres outils pour résoudre les problèmes d’un environnement de cinq dc à trois domaines. Les erreurs de réplication AD rencontrées dans l’atelier sont les suivantes : -2146893022, 1256, 1908, 8453 et 8606. »

Surveillance quotidienne de l’état de réplication Active Directory

Si l’erreur 8606 /Event 1988 a été causée par l’échec de la réplication des modifications Active Directory dans le dernier nombre de jours de la durée de vie de tombstone, assurez-vous que l’état de réplication Active Directory est surveillé quotidiennement. L’état de la réplication peut être surveillé à l’aide d’une application de surveillance dédiée ou en visualxant la sortie de l’option peu coûteuse mais efficace pour exécuter la commande dans une application de feuille de calcul telle que repadmin /showrepl * /csv Microsoft Excel. (Voir « Méthode 2 : surveiller la réplication à l’aide d’une ligne de commande » dans l’article de la Base de connaissances Microsoft 910205).

Les contrôleurs de domaine qui n’ont pas été répliqués entrants dans 50 % du nombre de jours de la durée de vie de tombstone doivent être placés dans une liste de surveillance qui reçoit l’attention de l’administrateur prioritaire pour rendre la réplication opérationnelle. Les contrôleurs de domaine qui ne peuvent pas être 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 % du chiffrement 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 d’heure s’est produit, vérifiez les horodaters dans les journaux d’événements et de diagnostics (observateur d’événements, journaux netlogon, rapports dcdiag) sur les contrôleurs de domaine de destination qui enregistrent les repadmin /showreps événements d’erreur 8606 /NTDS Replication 1988 pour les événements suivants :

  • Cachets de date qui datent avant la publication d’un système d’exploitation (par exemple, les cachets de date de CY 2003 pour un système d’exploitation publié dans CY 2008)
  • Horodats qui prédent l’installation du système d’exploitation dans votre forêt
  • Horodaodatés à l’avenir
  • Aucun événement consigné dans une plage de dates donnée

Les équipes de support Microsoft ont vu le temps système sur les contrôleurs de domaine de production sauter de manière incorrecte les heures, les jours, les semaines, les années et même les dizaines d’années passées et futures. Si le temps système a été jugé inexact, vous devez le corriger, puis essayer de déterminer pourquoi le temps a été trop long et ce qu’il est possible de faire pour éviter les temps imprécis et simplement corriger le temps incorrect. Les questions possibles sont les suivantes :

  • Le PDC racine de la forêt 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ésolus 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 de contrôleur de domaine sont-ils configurés pour utiliser la hiérarchie NT5DS pour l’heure source ?
  • La protection de la récupération de temps décrite dans l’article de la Base de connaissances Microsoft 884776 mise 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 et invités virtuels 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 des étapes pour protéger les contrôleurs de domaine de l'« écoute » aux exemples de temps non valides. Plus d’informations sur MaxPosPhaseCorrection et MaxNegPhaseCorrection sont disponibles dans le billet de blog W32Time Windows Time Service.

Recherchez les objets en attente à repadmin /removelingeringobjects /advisorymode l’aide, puis supprimez-les selon les besoins.

Relâchez l’utilisateur « Autoriser la réplication avec le partenaire d’autant plus qu’il est endommagé » selon les besoins.

Comment démarrer manuellement le collecte de la garbage

Plusieurs options s’offrent à vous 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: modify
replace: DoGarbageCollection
dogarbagecollection: 1
-

Notes

Le caractère « - » final est un élément obligatoire du fichier .ldif.

Animations à la fin de l’expiration de TSL

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

Un examen des champs clés à partir du contrôleur de domaine source doit signaler que les valeurs suivantes sont vraies : LastKnownParent a une valeur de 1 et son cachet de date est au niveau du nombre de jours TSL dans le repadmin /showobjmeta passé. Son cachet de date indique la date de suppression de l’objet.

IsDeleted a le numéro de version 2 (ou une autre valeur numérotation) où la version 1 a défini la suppression d’origine et la version 2 est la restauration/réanimation. Le cachet de date pour « isDeleted=2 » doit être ~ TSL nombre de jours après la dernière date de modification pour LastKnownParent.

Évaluez si l’objet en question doit rester un objet en direct ou un objet supprimé. Si LastKnownParent a la valeur 1, un objet ou une personne a supprimé l’objet. S’il ne s’agit pas d’une suppression accidentelle, il est fortuit que l’objet soit supprimé des contrôleurs de domaine source qui ont une copie en direct de l’objet.

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

  • Activez la réplication souple 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à collecté la garbage de l’objet.
  • Supprimez l’objet, puis re-créez-le.

Plus d'informations

Lancez le laboratoire TechNet à la demande suivant pour une pratique de dépannage guidée de cette erreur et d’autres erreurs de réplication AD :

Résolution des erreurs de réplication Active Directory
Dans ce laboratoire, vous allez parcourir les phases de dépannage, d’analyse et d’implémentation des erreurs de réplication Active Directory couramment rencontrées. Vous utiliserez une combinaison d’outils ADREPLSTATUS, repadmin.exe et d’autres outils pour résoudre les problèmes d’un environnement de cinq dc à trois domaines. Les erreurs de réplication AD rencontrées dans l’atelier sont les suivantes : -2146893022, 1256, 1908, 8453 et 8606. »

Causes des objets en attente

Cause 1 : le contrôleur de domaine source envoie des mises à jour aux objets qui ont déjà été récupérés par le garbage collection sur le contrôleur de domaine de destination, car le contrôleur de domaine source était hors connexion ou a échoué à la réplication 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 Tombstone = 60 jours. La réplication stricte est activée sur les deux contrôleurs de domaine. DC2 subit une défaillance de la carte mère. En attendant, DC1 effectue quotidiennement des suppressions d’origine pour les groupes de sécurité obsolètes au cours des 90 prochains jours. Une fois hors connexion pendant 90 jours, DC2 reçoit une carte mère de remplacement, s’alimente, puis reçoit une modification DACL ou SACL sur tous les comptes d’utilisateur avant qu’il réplique les connaissances de suppressions d’origine de DC1. DC1 enregistre les erreurs 8606 pour les groupes de sécurité de mises à jour qui sont purgés sur DC1 pendant les 30 premiers jours où DC2 était hors connexion.

Cause 2 : le dc source envoie des mises à jour aux objets à la fin de l’expiration du protocole TSL qui ont déjà été récupérés par le garbage collection par un DC 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 Tombstone = 60 jours. La réplication stricte est activée sur les deux contrôleurs de domaine. DC1 et DC2 répliquent toutes les 24 heures. DC1 part-supprime tous les jours. DC1 est mis à niveau sur place. Cela marque le nouvel attribut sur tous les objets dans la configuration et les partitions de domaine accessibles en writable. Cela inclut les objets qui se trouve actuellement dans le conteneur d’objets supprimés. Certains d’entre eux ont été supprimés il y a 60 jours et sont maintenant à la fin de l’expiration de tombstone. DC2 récupère certains objets par le garbage collection qui ont été supprimés TSL il y a quelques jours avant l’ouverture de la planification de réplication avec DC2. L’erreur 8606 est consignée jusqu’à ce que DC1 récupère les objets bloquants par le garbage collection.

Toute mise à jour de l’ensemble d’attributs partiels peut provoquer des objets temporairement en attente qui s’effacent eux-mêmes après que les contrôleurs de domaine source collectent la garbage-collect des objets supprimés à la mise à jour de 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 tri 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 Tombstone = 60 jours. La réplication stricte est activée sur les deux contrôleurs de domaine. DC1 et DC2 répliquent toutes les 24 heures. DC1 part des suppressions quotidiennes. La source de temps de référence utilisée par DC1 (mais pas DC2) est mise à jour jusqu’à l’année civile 2039. Ainsi, DC2 utilise également une heure système dans CY2039. Dc1 supprime ainsi prématurément les objets qui sont supprimés aujourd’hui de son conteneur d’objets supprimés. En attendant, DC2 a apporté des modifications aux attributs des utilisateurs, des ordinateurs et des groupes qui sont actifs sur DC2, mais supprimés et maintenant prématurément la garbage collecté sur DC1. DC1 enregistre l’erreur 8606 lors de la prochaine réplication entrante des modifications pour les objets supprimés prématurés.

Cause 4 : un objet est réanimé à la fin de l’expiration de TSL

Le CONTOSO.COM domaine contient deux contrôleurs de domaine dans le même domaine. Durée de vie de Tombstone = 60 jours. La réplication stricte est activée sur les deux contrôleurs de domaine. DC1 et DC2 répliquent toutes les 24 heures. DC1 part des suppressions quotidiennes. Une ou plusieurs utilisateurs, ordinateurs et groupes sont supprimés accidentellement. Une sauvegarde de l’état du système qui a été réalisée à la cusp de TSL dans le passé est restaurée sur DC2. La sauvegarde contient des objets qui sont en direct sur DC2, mais qui sont déjà supprimés et récupérés par le garbage collection sur DC1.

Cause 5 : une bulle USN déclenche la journalisation du 8606

Dites 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 possède l’objet en raison de la bulle. À présent, une fois que la bulle se ferme et que les modifications recommencent à se répliquer, une modification est créée pour cet objet sur le contrôleur de domaine source et s’affiche comme un objet en attente pour le contrôleur de domaine de destination. Le contrôleur de destination enregistre l’événement 8606.

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

Les contrôleurs de domaine Active Directory prennent en charge la réplication multi-maîtres où n’importe quel contrôleur de domaine (qui contient une partition accessible en création) peut provenir d’une création, d’une modification ou d’une suppression d’un objet ou d’un attribut (valeur). La connaissance des suppressions d’objet/d’attribut est persistante 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 un 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 titulaires de partition pour répliquer de manière transitive toutes les suppressions d’origine pour toutes les partitions d’annuaire sur tous les titulaires de partition. L’échec de la réplication entrante d’une partition d’annuaire en un nombre de jours TSL de déploiement entraîne l’attente d’objets. Un objet en attente est un objet qui a été intentionnellement supprimé par au moins un contrôleur de domaine, mais qui existe de manière incorrecte sur les contrôleurs de domaine de destination qui n’ont pas répliqué la connaissance passagère de toutes les suppressions uniques.