Active Directory-Replikationsfehler 8606: Unzureichende Attribute zum Erstellen eines Objekts

Dieser Artikel enthält Hilfe bei der Problembehandlung des Active Directory-Replikationsfehlers 8606: Es wurden nicht genügend Attribute zum Erstellen eines Objekts angegeben.

Gilt für: Windows Server 2012 R2
Ursprüngliche KB-Nummer: 2028495

Zusammenfassung

In diesem Artikel werden die Symptome und Ursachen eines Problems beschrieben, bei dem die Active Directory-Replikation nicht erfolgreich ist, und der Fehler 8606 wird generiert: "Es wurden nicht genügend Attribute zum Erstellen eines Objekts angegeben. Dieses Objekt ist möglicherweise nicht vorhanden, weil es möglicherweise gelöscht wurde." In diesem Artikel wird auch eine Lösung für dieses Problem beschrieben.

Problembeschreibung

Symptom 1

Die DCDIAG meldet, dass der Active Directory-Replikationstest mit dem Fehler 8606 fehlgeschlagen ist: "Es wurden nicht genügend Attribute zum Erstellen eines Objekts angegeben."

Test wird gestartet: Replikationen
[Replikationsprüfung, <Ziel-DC>] Fehler beim letzten Replikationsversuch:
Vom <Quelldomänencontroller> zum <Zieldomänencontroller>
Benennungskontext: <DN-Pfad der Verzeichnispartition>
Die Replikation hat einen Fehler (8606) generiert:
Es wurden nicht genügend Attribute zum Erstellen eines Objekts angegeben. Dieses Objekt ist möglicherweise nicht vorhanden, da es möglicherweise gelöscht wurde und bereits eine Garbage Collection erstellt wurde.
Der Fehler ist zum Zeitpunkt des <Datums><aufgetreten.>
Der letzte Erfolg ist zum <Zeitpunkt des Datums><aufgetreten.>

Symptom 2

Eingehende Replikation, die durch den Befehl Jetzt replizieren im DSSITE-Snap-In "Active Directory-Standorte und -Dienste" ausgelöst wird. MSC ist nicht erfolgreich und generiert den Fehler "Unzureichende Attribute wurden zum Erstellen eines Objekts angegeben". Wenn Sie mit der rechten Maustaste auf ein Verbindungsobjekt von einem Quelldomänencontroller klicken und dann Replizieren jetzt auswählen, ist die Replikation nicht erfolgreich und generiert den folgenden Fehler: "Zugriff verweigert". Darüber hinaus erhalten Sie die folgende Fehlermeldung:

Dialogtiteltext: Jetzt replizieren
Dialogmeldungstext: Der folgende Fehler ist beim Versuch aufgetreten, den Namenskontext <%active directory partition name%> vom Domänencontrollerquell-Domänencontroller <> mit dem Domänencontroller-Zieldomänencontroller <>zu synchronisieren:

Es wurden nicht genügend Attribute zum Erstellen eines Objekts angegeben. Dieses Objekt ist möglicherweise nicht vorhanden, da es möglicherweise gelöscht und bereits vom Garbage Collection erfasst wurde.

Der Vorgang wird nicht fortgesetzt.

Symptom 3

Verschiedene repadmin.exe-Befehle schlagen mit dem Fehler 8606 fehl. Diese Befehle umfassen, sind jedoch nicht beschränkt auf Folgendes:

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

Symptom 4

Ereignis 1988 wird kurz nach dem Auftreten eines der folgenden Ereignisse protokolliert:

• Der erste Domänencontroller in der Gesamtstruktur wird bereitgestellt.
• Alle Aktualisierungen des teiliellen Attributsatzes werden vorgenommen.

Symptom 5

Das NTDS-Replikationsereignis 1988 wird möglicherweise im Ereignisprotokoll des Verzeichnisdiensts von Domänencontrollern protokolliert, die versuchen, Active Directory in eingehender Richtung zu replizieren.

Typ: Fehler
Quelle: NTDS-Replikation
Kategorie: Replikation
Ereignis-ID: 1988
Benutzer: NT AUTHORITY\ANONYMOUS LOGON
Computer: <Hostname des Domänencontrollers, der das Ereignis protokolliert hat, auch als "Ziel"-DC beim Replikationsversuch bezeichnet>
Beschreibung: Der lokale Domänencontroller hat versucht, das folgende Objekt aus dem folgenden Quelldomänencontroller zu replizieren. Dieses Objekt ist auf dem lokalen Domänencontroller nicht vorhanden, da es möglicherweise gelöscht und bereits garbage collection (Garbage Collection) gesammelt wurde.
Quelldomänencontroller:
<Vollqualifizierter GUIDED CNAME des Quell-DC>
Objekt:
<DN-Pfad des Liveobjekts auf quell-DC>
Objekt-GUID:
<Objekt-GUID des Objekts auf Quell-DCs Kopie von Active Directory>

Ursache

Fehler 8606 wird protokolliert, wenn die folgenden Bedingungen erfüllt sind:

• Ein Quelldomänencontroller sendet eine Aktualisierung an ein Objekt (anstelle eines ursprünglichen Objekts), das bereits erstellt, gelöscht und dann von der Garbage Collection aus der Kopie eines Zieldomänencontrollers von Active Directory freigegeben wurde.
• Der Zieldomänencontroller wurde für die Ausführung in strenger Replikationskonsistenz konfiguriert.

Wenn der Zieldomänencontroller für die Verwendung der losen Replikationskonsistenz konfiguriert wurde, wäre das Objekt in der Kopie des Verzeichnisses des Zieldomänencontrollers "reanimatiert" worden. Spezifische Variationen, die Fehler verursachen können, sind 8606, die im Abschnitt "Weitere Informationen" dokumentiert sind. Der Fehler wird jedoch durch eine der folgenden Ursachen verursacht:

• Ein dauerhaft anhaltendes Objekt, dessen Entfernung einen Administratoreingriff erfordert
• Ein vorübergehendes beibehaltenes Objekt, das sich selbst korrigiert, wenn der Quelldomänencontroller seine nächste Garbage Collection-Bereinigung durchführt. Die Einführung des ersten Domänencontrollers in einer vorhandenen Gesamtstruktur und Aktualisierungen des teiliellen Attributsatzes sind bekannte Ursachen für diese Bedingung.
• Ein Objekt, das zum Zeitpunkt des Ablaufs der Tombstone-Lebensdauer wiederhergestellt oder wiederhergestellt wurde

Beachten Sie bei der Problembehandlung von 8606-Fehlern die folgenden Punkte:

• Obwohl fehler 8606 auf dem Zieldomänencontroller protokolliert wird, befindet sich das Problemobjekt, das die Replikation blockiert, auf dem Quelldomänencontroller. Darüber hinaus hat der Quelldomänencontroller oder ein transitiver Replikationspartner des Quelldomänencontrollers möglicherweise keine Eingehenden Informationen über eine gelöschte Tombstone-Lebensdauer in der Vergangenheit erhalten.

• Bleibende Objekte können unter folgenden Umständen vorhanden sein:

  • Als "live"-Objekte, als CNF- oder Konfliktmanglierte Objekte "live"-Objekte oder als CNF- oder konfliktgemangte Objekte im Container für gelöschte Objekte des Quelldomänencontrollers
  • In einer beliebigen Verzeichnispartition mit Ausnahme der Schemapartition. Bleibende Objekte werden am häufigsten in schreibgeschützten Domänenpartitionen auf GCs gefunden. Weitere Objekte können auch in beschreibbaren Domänenpartitionen sowie in der Konfigurationspartition vorhanden sein. Die Schemapartition unterstützt keine Löschvorgänge.
  • In jeder Objektklasse (Benutzer, Computer, Gruppen und DNS-Einträge sind am häufigsten).

• Denken Sie daran, nach potenziell bleibenden Objekten nach Objekt-GUID und DN-Pfad zu suchen, damit Objekte unabhängig von ihrer Hostpartition und dem übergeordneten Container gefunden werden können. Bei der Suche nach objectguid werden auch Objekte gesucht, die sich im Container für gelöschte Objekte befinden, ohne das LDAP-Steuerelement für gelöschte Objekte zu verwenden.

• Das NTDS-Replikationsereignis 1988 identifiziert nur das aktuelle Objekt auf dem Quelldomänencontroller, das die eingehende Replikation durch einen Zieldomänencontroller im strict-Modus blockiert. Es gibt wahrscheinlich zusätzliche Objekte "hinter" dem Objekt, auf das im Ereignis von 1988 verwiesen wird, das ebenfalls weiterhin besteht.

• Das Vorhandensein von bleibenden Objekten auf einem Quelldomänencontroller verhindert oder blockiert, dass Zieldomänencontroller im strict-Modus eingehende Änderungen replizieren, die hinter dem bleibenden Objekt in der Replikationswarteschlange vorhanden sind.

• Aufgrund der Art und Weise, wie Domänencontroller Objekte einzeln aus ihren gelöschten Objektcontainern löschen (der Garbage Collection-Daemon wird alle 12 Stunden nach dem letzten Start jedes Domänencontrollers ausgeführt), können die Objekte, die 8606-Fehler auf Zieldomänencontrollern verursachen, bei der nächsten Ausführung der Garbage Collection-Bereinigung entfernt werden. Bleibende Objekte in dieser Klasse sind vorübergehend und sollten sich nicht mehr als 12 Stunden nach dem Start des Problems entfernen.

• Das in Frage bleibende Objekt ist wahrscheinlich eines, das absichtlich von einem Administrator oder einer Anwendung gelöscht wurde. Berücksichtigen Sie dies in Ihren Lösungsplan, und achten Sie auf reanimierte Objekte, insbesondere sicherheitsprinzipale, die absichtlich gelöscht wurden. Lösung

Lösung

1. Identifizieren Sie den aktuellen Wert für die gesamtstrukturweite Einstellung TombStoneLifeTime .

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

   Weitere Informationen finden Sie im Abschnitt "Tombstone-Lebensdauer und Replikation von Löschungen" im folgenden Artikel der Microsoft Knowledge Base:
   910205 Informationen zu bleibenden Objekten in einer Windows Server Active Directory Gesamtstruktur.

2. Filtern Sie für jeden Zieldomänencontroller, der den Fehler 8606 protokolliert, das Verzeichnisdienstereignisprotokoll nach NTDS-Replikationsereignis 1988.

3. Sammeln Sie Metadaten für jedes eindeutige Objekt, das im NTDS-Replikationsereignis 1988 zitiert wird. Füllen Sie aus jedem Ereignis von 1988, das auf dem Zieldomänencontroller protokolliert wird, der ein neues Objekt angibt, die folgende Tabelle auf:

   Objekt-DN-Pfad	Objekt-GUID	Quell-DC	Hostpartition	Live oder gelöscht?	LastKnownParent	IsDeleted-Wert

   Die Spalten 1 bis 5 dieser Tabelle können durch direktes Lesen von Werten aus Feldern in den NTDS-Replikationsereignissen von 1988 aufgefüllt werden, die in den Verzeichnisdienstereignisprotokollen der Zieldomänencontroller protokolliert werden, die entweder das Ereignis 1988 oder die 8606-Replikation status protokollieren.

   Die Datumsstempel für die Spalten LastKnownParent und IsDeleted können durch Ausführen repadmin /showobjmeta und Verweisen auf die objectguid des Objekts bestimmt werden, das im NTDS-Replikationsereignis 1988 zitiert wird. Verwenden Sie hierzu die folgende Syntax:

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

   Der Datumsstempel für LastKnownParent gibt das Datum an, an dem das Objekt gelöscht wurde. Der Datumsstempel für IsDeleted gibt an, wann das Objekt zuletzt gelöscht oder reanimiert wurde. Die Versionsnummer gibt an, ob die letzte Änderung das Objekt gelöscht oder reanimiert hat. Ein IsDeleteted-Wert von 1 stellt einen anfänglichen Löschvorgang dar. Ungerade Werte größer als 1 deuten auf eine Reanimation nach mindestens einem Löschvorgang hin. Ein isDeleted-Wert von 2 stellt beispielsweise ein Objekt dar, das gelöscht (Version 1) und später wieder gelöscht oder reanimiert wurde (Version 2). Spätere gerade nummerierte Werte für IsDeleted stellen spätere Reanimationen oder Rückgängigmachen des Objekts dar.

4. Wählen Sie die entsprechende Aktion basierend auf den Objektmetadaten aus, die im Ereignis 1988 zitiert werden.

   Fehler 8606/NTDS-Replikationsereignis 1988 wird am häufigsten durch langfristige Replikationsfehler verursacht, die verhindern, dass Domänencontroller eingehende Replikationsinformationen über alle ursprünglichen Löschvorgänge in der Gesamtstruktur erhalten. Dies führt dazu, dass Objekte auf einem oder mehreren Quelldomänencontrollern bleiben.

   Überprüfen Sie die Metadaten für das Objekt, das in der Tabelle aufgeführt ist, die in Schritt 4 des Abschnitts "Auflösung" erstellt wurde.

   Wenn das Objekt im Ereignis 1988 entweder (auf dem Quelldomänencontroller live) aber (auf dem Zieldomänencontroller für länger als die Tombstone-Lebensdauer gelöscht wurde)) ist, finden Sie weitere Informationen unter Entfernen von lingernden Objekten und "". Objekte in dieser Bedingung müssen manuell von einem Administrator entfernt werden.

   Gelöschte Objekte wurden möglicherweise vorzeitig aus dem Container für gelöschte Objekte gelöscht, wenn die Systemzeit auf dem Zieldomänencontroller rechtzeitig vorgesprungen ist. Überprüfen Sie den Abschnitt "Auf Zeitsprünge überprüfen".

   Wenn das im Ereignis 1988 zitierte Objekt im Container für gelöschte Objekte des Quelldomänencontrollers vorhanden ist und das Löschdatum direkt am Anfang des Ablaufs der Tombstone-Lebensdauer liegt, so dass das Objekt von einem oder mehreren Zieldomänencontrollern von der Garbage Collection freigegeben wurde und im nächsten Garbage Collection-Intervall auf Quelldomänencontrollern (d. die bleibenden Objekte vorübergehend sind), haben Sie die Wahl. Warten Sie entweder, bis die nächste Garbage Collection-Ausführung das Objekt löscht, oder lösen Sie die Garbage Collection manuell auf dem Quelldomänencontroller aus. Weitere Informationen finden Sie unter Manuelles Starten der Garbage Collection. Diese Bedingung kann durch die Einführung des ersten Domänencontrollers oder durch jede Änderung des teiliellen Attributsatzes verursacht werden.

   Wenn repadmin /showobjmeta die Ausgabe für das Objekt, das im Ereignis 1988 zitiert wird, den LastKnownParent-Wert 1 aufweist, gibt dies an, dass das Objekt gelöscht wurde , und ein IsDeleted-Wert von 2 oder ein anderer gerader Wert, und dieser Datumsstempel für IsDeleted befindet sich am Ende der Tombstone-Lebensdaueranzahl von Tagen, die sich vom Datumsstempel für LastKnownParent unterscheidet. Dann wurde das Objekt gelöscht und dann wiederhergestellt/Authentifizierung wiederhergestellt, während es noch auf dem Quelldomänencontroller aktiv war, aber bereits von der Garbage Collection von Zieldomänencontrollern mit Protokollierungsfehler 8606/Ereignis 1988 freigegeben wurde. Weitere Informationen finden Sie unter Reanimations am Anfang des TSL-Ablaufs.

Entfernen von bleibenden Objekten

Es gibt zwar viele Methoden, um beibehaltene Objekte zu entfernen, aber es gibt drei primäre Tools, die häufig verwendet werden: repadmin.exe, Lingering Object Liquidator (LoL) und repldiag.

Lingering Object Liquidator (LoL)

Die einfachste Methode zum sauber Lingering Objects ist die Verwendung der LoL. Das LoL-Tool wurde entwickelt, um den Bereinigungsprozess für eine Active Directory-Gesamtstruktur zu automatisieren. Das Tool ist GUI-basiert und kann die aktuelle Active Directory-Gesamtstruktur überprüfen und bleibende Objekte erkennen und bereinigen. Das Tool ist im Microsoft Download Center verfügbar.

Repadmin

Die folgenden beiden Befehle in repadmin.exe können fortbestehende Objekte aus Verzeichnispartitionen entfernen:

• repadmin /removelingeringobjects
• repadmin /rehost

Der repadmin /removelingeringobjects Befehl kann verwendet werden, um bleibende Objekte aus schreibbaren und schreibgeschützten Verzeichnispartitionen auf Quelldomänencontrollern zu entfernen. Die Syntax lautet wie folgt:

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

Dabei gilt:
<> Dest_DSA_LIST ist der Name eines Domänencontrollers, der bleibende Objekte enthält (z. B. der Quelldomänencontroller, der im NTDS Replication 1988-Ereignis angegeben wird).

<Quell-DSA-GUID> ist der Name eines Domänencontrollers, der eine beschreibbare Kopie der Verzeichnispartition hostet, die beibehaltene Objekte enthält, mit denen der Domänencontroller in <Dest_DSA_LIST> über Netzwerkkonnektivität verfügt. Der zu bereinigende Domänencontroller (erster im Befehl angegebener DC) muss in der Lage sein, eine direkte Verbindung mit Port 389 auf dem Domänencontroller herzustellen, der eine beschreibbare Kopie der Verzeichnispartition hostet (die zweite im Befehl angegeben).

<NC> ist der DN-Pfad der Verzeichnispartition, die verdächtigt wird, bleibende Objekte zu enthalten, z. B. die Partition, die in einem Ereignis von 1988 angegeben ist.

Der repadmin /rehost Befehl kann verwendet werden, um lingering-objects-Domänencontroller, die eine schreibgeschützte Kopie einer Domänenverzeichnispartition hosten, von Domänencontrollern zu entfernen. Die Syntax lautet wie folgt:

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

Dabei gilt:
DSA ist der Name eines Domänencontrollers, der eine schreibgeschützte Domänenverzeichnispartition für eine nicht lokale Domäne hostet. Beispielsweise kann eine GC in root.contoso.com ihre schreibgeschützte Kopie von child.contoso.com erneut hosten, aber root.contoso.com nicht erneut hosten.

<Naming Context> ist der DN-Pfad einer schreibgeschützten Domänenverzeichnispartition, die sich in einem globalen Katalog befindet.

<Gute DSA-Quelladresse> ist der Name eines Domänencontrollers, der eine beschreibbare Kopie des Namenskontexts <>hostet. Der Domänencontroller muss für den DSA-Computer über das Netzwerk verfügbar sein.

Wenn das im Ereignis 1988 gemeldete beibehaltene Objekt nicht von repadmin entfernt wird, bewerten Sie, ob das Objekt auf dem Quelldomänencontroller in einer USN-Lücke erstellt wurde oder ob die Objekte, aus denen der Domänencontroller stammt, nicht im aktuellen Vektor des Quelldomänencontrollers vorhanden sind.

Repldiag

Starten Sie das folgende TechNet On-Demand-Lab für die geführte Problembehandlung bei dieser und anderen AD-Replikationsfehlern:

Im Lab verwenden Sie sowohl repadmin als auchrepldiag.exe , um bleibende Objekte zu entfernen.
Problembehandlung bei Active Directory-Replikationsfehlern
In diesem Lab durchlaufen Sie die Problembehandlungs-, Analyse- und Implementierungsphasen von häufig auftretenden Active Directory-Replikationsfehlern. Sie verwenden eine Kombination aus ADREPLSTATUS, repadmin.exeund anderen Tools, um Probleme mit einer Umgebung mit fünf Domänencontrollern und drei Domänen zu beheben. Im Lab aufgetretene AD-Replikationsfehler sind -2146893022, 1256, 1908, 8453 und 8606."

Tägliche Überwachung der Active Directory-Replikationsintegrität

Wenn fehler 8606/Ereignis 1988 dadurch verursacht wurde, dass der Domänencontroller Active Directory-Änderungen in der letzten Tombstone-Lebensdaueranzahl von Tagen nicht replizieren konnte, stellen Sie sicher, dass die Active Directory-Replikationsintegrität in Zukunft täglich überwacht wird. Die Replikationsintegrität kann mithilfe einer dedizierten Überwachungsanwendung oder durch Anzeigen der Ausgabe einer kostengünstigen, aber effektiven Option zum Ausführen repadmin /showrepl * /csv des Befehls in einer Tabellenkalkulationsanwendung wie Microsoft Excel überwacht werden. (Weitere Informationen finden Sie unter "Methode 2: Überwachen der Replikation über eine Befehlszeile" im Microsoft Knowledge Base-Artikel 910205).

Domänencontroller, die in 50 Prozent der Tombstone-Lebensdauer nicht in 50 Prozent der Tombstone-Lebensdauer repliziert wurden, sollten in eine watch Liste mit Prioritätsadministratoren aufgenommen werden, um die Replikation betriebsbereit zu machen. Domänencontroller, die nicht erfolgreich repliziert werden können, sollten erzwungen werden, wenn sie nicht innerhalb von 90 Prozent der TSL repliziert wurden.

Replikationsfehler, die auf einem Zieldomänencontroller auftreten, können durch den Zieldomänencontroller, den Quelldomänencontroller oder durch das zugrunde liegende Netzwerk und die DNS-Infrastruktur verursacht werden.

Überprüfen auf Zeitsprünge

Um zu ermitteln, ob ein Zeitsprung aufgetreten ist, überprüfen Sie datumsstempel in Ereignis- und Diagnoseprotokollen (Ereignisanzeige, repadmin /showreps, netlogon logs, dcdiag reports) auf Zieldomänencontrollern, die fehler 8606/NTDS Replication 1988 ereignisse für Folgendes protokollieren:

• Datumsstempel, die vor der Veröffentlichung eines Betriebssystems erfolgen (z. B. Datumsstempel aus CY 2003 für ein in CY 2008 veröffentlichtes Betriebssystem)
• Datumsstempel, die der Installation des Betriebssystems in Ihrer Gesamtstruktur voraus sind
• Datumsstempel in der Zukunft
• Keine Ereignisse, die in einem bestimmten Datumsbereich protokolliert werden

Microsoft-Support Teams haben die Systemzeit auf Produktionsdomänencontrollern in früheren und zukünftigen Jahren fälschlicherweise über Stunden, Tage, Wochen, Jahre und sogar dutzende Jahre hinweg gesehen. Wenn die Systemzeit als ungenau befunden wurde, sollten Sie sie korrigieren und dann versuchen, zu ermitteln, warum die Zeit gesprungen ist und was getan werden kann, um eine ungenaue Zeit zu verhindern, anstatt nur die schlechte Zeit zu korrigieren. Mögliche Fragen sind:

• Wurde die Stamm-PDC der Gesamtstruktur mithilfe einer externen Zeitquelle konfiguriert?
• Sind Referenz-Onlinezeitquellen im Netzwerk verfügbar und in DNS auflösbar?
• Wurde der Zeitdienst von Microsoft oder Drittanbietern ausgeführt und in einem fehlerfreien Zustand?
• Sind Domänencontrollerrollencomputer für die Verwendung der NT5DS-Hierarchie zur Quellzeit konfiguriert?
• Wurde der im Microsoft Knowledge Base-Artikel beschriebene Zeitrollbackschutz 884776 ?
• Verfügen Systemuhren über gute Akkus und genaue Zeit im BIOS auf Domänencontrollern auf virtuellen Hostcomputern?
• Sind virtuelle Host- und Gastcomputer gemäß den Empfehlungen des Hostingherstellers für die Quellzeit konfiguriert?
  Im Microsoft Knowledge Base-Artikel 884776 Werden Schritte beschrieben, mit denen Sie Domänencontroller vor "Lauschen" auf ungültige Zeitbeispiele schützen können. Weitere Informationen zu MaxPosPhaseCorrection und MaxNegPhaseCorrection finden Sie im W32Time-Blogbeitrag Windows-Zeitdienst.

Suchen Sie mithilfe repadmin /removelingeringobjects /advisorymodevon auf objekte, die noch nicht verwendet werden, und entfernen Sie sie dann nach Bedarf.

Lockern Sie nach Bedarf "Replikation mit abweichendem und beschädigtem Partner zulassen".

Manuelles Starten der Garbage Collection

Es gibt mehrere Optionen, um die Garbage Collection auf einem bestimmten Domänencontroller manuell auszulösen:

Führen Sie "repadmin /setattr "" "" doGarbageCollection add 1 aus.

Führen Sie LDIFDE /s <server> /i /f dogarbage.ldif aus, wobei dobarbage.ldif den Text enthält:

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

Reanimations am Anfang des TSL-Ablaufs

Damit diese Bedingung vorhanden ist, sollte gemeldet werden, repadmin /showobject "<GUID=object guid for object in 1988 event>" dass das Objekt auf dem Zieldomänencontroller "nicht gefunden" wurde, aber auf dem Quelldomänencontroller aktiv ist und entweder ein gelöschtes oder nicht gelöschtes Objekt ist.

Eine Überprüfung der Schlüsselfelder auf repadmin /showobjmeta dem Quelldomänencontroller sollte Folgendes melden: LastKnownParent hat den Wert 1, und der Datumsstempel befindet sich am Anfang der TSL-Tage in der Vergangenheit. Der Datumsstempel gibt das Löschdatum des Objekts an.

IsDeleted hat eine Versionsnummer von 2 (oder einen anderen geraden Wert), wobei Version 1 den ursprünglichen Löschvorgang und Version 2 die Wiederherstellung/Reanimation definiert hat. Der Datumsstempel für "isDeleted=2" sollte ~ TSL-Anzahl von Tagen nach dem Datum der letzten Änderung für LastKnownParent sein.

Bewerten Sie, ob das betreffende Objekt ein aktives oder gelöschtes Objekt bleiben soll. Wenn LastKnownParent den Wert 1 aufweist, wurde das Objekt von etwas oder einer anderen Person gelöscht. Wenn dies kein versehentliches Löschen war, ist die Wahrscheinlichkeit gut, dass das Objekt von allen Quelldomänencontrollern gelöscht wird, die über eine Livekopie des Objekts verfügen.

Wenn das Objekt auf allen Replikaten vorhanden sein soll, stehen folgende Optionen zur Verfügung:

• Aktivieren Sie die lose Replikation auf Zieldomänencontrollern im Strict-Modus, die nicht über das -Objekt verfügen.
• Erzwingen Sie die Herabstufen der Domänencontroller, für die das Objekt bereits eine Garbage Collection durchgeführt wurde.
• Löschen Sie das Objekt, und erstellen Sie es dann neu.

Weitere Informationen

Starten Sie das folgende TechNet On-Demand-Lab für die geführte Problembehandlung bei dieser und anderen AD-Replikationsfehlern:

Problembehandlung bei Active Directory-Replikationsfehlern
In diesem Lab durchlaufen Sie die Problembehandlungs-, Analyse- und Implementierungsphasen von häufig auftretenden Active Directory-Replikationsfehlern. Sie verwenden eine Kombination aus ADREPLSTATUS, repadmin.exeund anderen Tools, um Probleme mit einer Umgebung mit fünf Domänencontrollern und drei Domänen zu beheben. Im Lab aufgetretene AD-Replikationsfehler sind -2146893022, 1256, 1908, 8453 und 8606."

Ursachen für bleibende Objekte

Ursache 1: Der Quelldomänencontroller sendet Updates an Objekte, die bereits von der Garbage Collection auf dem Zieldomänencontroller freigegeben wurden, da der Quelldomänencontroller entweder offline war oder die Replikation für die TSL-Anzahl verstrichener Tage fehlgeschlagen ist.

Die CONTOSO.COM Domäne enthält zwei Domänencontroller in derselben Domäne. Tombstone-Lebensdauer = 60 Tage. Die strikte Replikation ist auf beiden Domänencontrollern aktiviert. DC2 hat einen Motherboard-Fehler. In der Zwischenzeit führt DC1 in den nächsten 90 Tagen täglich Löschvorgänge für veraltete Sicherheitsgruppen durch. Nachdem es 90 Tage lang offline ist, erhält DC2 eine Ersatzplatine, schaltet ein und erstellt dann eine DACL- oder SACL-Änderung für alle Benutzerkonten, bevor es eingehende Replikationen von Ursprünglichen Löschvorgängen von DC1 durchführt. DC1 protokolliert 8606-Fehler für Updatesicherheitsgruppen, die in den ersten 30 Tagen, an denen DC2 offline war, auf DC1 gelöscht werden.

Ursache 2: Der Quelldomänencontroller sendet Aktualisierungen an Objekte am Anfang des TSL-Ablaufs, die bereits von der Garbage Collection von einem Ziel-DC im Strict-Modus freigegeben wurden.

Die CONTOSO.COM Domäne enthält zwei Domänencontroller in derselben Domäne. Tombstone-Lebensdauer = 60 Tage. Die strikte Replikation ist auf beiden Domänencontrollern aktiviert. DC1 und DC2 replizieren alle 24 Stunden. DC1 wird täglich gelöscht. DC1 wird vor Ort aktualisiert. Dadurch wird ein neues Attribut für alle Objekte in der Konfiguration und beschreibbaren Domänenpartitionen gestempelt. Dies schließt Objekte ein, die sich derzeit im Container für gelöschte Objekte befinden. Einige von ihnen wurden vor 60 Tagen gelöscht und stehen jetzt am Ende des Tombstone-Ablaufs. DC2 gibt einige Objekte von der Garbage Collection zurück, die vor Tagen gelöscht wurden, bevor der Replikationszeitplan mit DC2 geöffnet wird. Fehler 8606 wird protokolliert, bis DC1 die blockierenden Objekte von der Garbage Collection zurückgibt.

Alle Aktualisierungen des partiellen Attributsatzes können dazu führen, dass temporäre Objekte beibehalten werden, die sich selbst löschen, nachdem die Quelldomänencontroller gelöschte Objekte am Anfang des TSL-Ablaufs (z. B. das Hinzufügen des ersten W2K8 R2-Domänencontrollers zu einer vorhandenen Gesamtstruktur) garbage-collect gelöscht haben.

Ursache 3: Ein Zeitsprung auf einem Zieldomänencontroller beschleunigt vorzeitig die Garbage Collection gelöschter Objekte auf einem Zieldomänencontroller.

Die CONTOSO.COM Domäne enthält zwei Domänencontroller in derselben Domäne. Tombstone-Lebensdauer = 60 Tage. Die strikte Replikation ist auf beiden Domänencontrollern aktiviert. DC1 und DC2 replizieren alle 24 Stunden. DC1 löscht täglich. Die von DC1 (aber nicht DC2) verwendete Referenzzeitquelle führt ein Rollforward auf das Kalenderjahr 2039 durch. Dies bewirkt, dass DC2 auch eine Systemzeit in CY2039 verwendet. Dies bewirkt, dass DC1 Objekte, die heute gelöscht werden, vorzeitig aus dem Container für gelöschte Objekte löscht. In der Zwischenzeit entstehen änderungen an Attributen auf Benutzern, Computern und Gruppen, die auf DC2 aktiv sind, aber gelöscht wurden und jetzt vorzeitig auf DC1 gesammelt werden. DC1 protokolliert den Fehler 8606, wenn änderungen für die vorzeitig gelöschten Objekte als nächstes eingehend repliziert werden.

Ursache 4: Ein Objekt wird am Anfang des TSL-Ablaufs reanimiert.

Die CONTOSO.COM Domäne enthält zwei Domänencontroller in derselben Domäne. Tombstone-Lebensdauer = 60 Tage. Die strikte Replikation ist auf beiden Domänencontrollern aktiviert. DC1 und DC2 replizieren alle 24 Stunden. DC1 löscht täglich. Eine Organisationseinheit, die Benutzer, Computer und Gruppen enthält, wird versehentlich gelöscht. Eine Systemstatussicherung, die in der Vergangenheit am Anfang der TSL erstellt wurde, wird auf DC2 Authentifizierung wiederhergestellt. Die Sicherung enthält Objekte, die auf DC2 aktiv sind, aber bereits von der Garbage Collection auf DC1 gelöscht und freigegeben wurden.

Ursache 5: Die Protokollierung der 8606 wird durch eine USN-Blase ausgelöst.

Angenommen, Sie erstellen ein Objekt in einer USN-Blase so, dass es nicht ausgehend repliziert wird, da der Zieldomänencontroller aufgrund der Blase "denkt", dass er das Objekt besitzt. Nachdem die Blase geschlossen wurde und die Änderungen wieder repliziert werden, wird eine Änderung für dieses Objekt auf dem Quelldomänencontroller erstellt und dem Zieldomänencontroller als anhaltendes Objekt angezeigt. Der Zielcontroller protokolliert das Ereignis 8606.

Anforderungen für die End-to-End-Replikation von Informationen zu ursprünglichen Löschvorgängen

Active Directory-Domänencontroller unterstützen multi-master-Replikation, bei der jeder Domänencontroller (der eine beschreibbare Partition enthält) aus dem Erstellen, Ändern oder Löschen eines Objekts oder Attributs (Wert) stammen kann. Das Wissen über Objekt-/Attributlöschungen wird vom ursprünglichen Domänencontroller und allen Domänencontrollern beibehalten, die über eingehende replizierte Informationen über einen ursprünglichen Löschvorgang für die TSL-Anzahl von Tagen verfügen. (Weitere Informationen finden Sie in den Microsoft Knowledge Base-Artikeln 216996 und 910205)

Active Directory erfordert eine End-to-End-Replikation von allen Partitionsinhabern, um transitiv alle ursprünglichen Löschvorgänge für alle Verzeichnispartitionen auf alle Partitionsinhaber zu replizieren. Wenn eine Verzeichnispartition in einer fortlaufenden TSL-Anzahl von Tagen nicht eingehend repliziert wird, führt dies dazu, dass Objekte nicht mehr eingehend repliziert werden. Ein beibehaltenes Objekt ist ein Objekt, das absichtlich von mindestens einem Domänencontroller gelöscht wurde, das aber fälschlicherweise auf Zieldomänencontrollern vorhanden ist, die nicht das vorübergehende Wissen über alle eindeutigen Löschvorgänge eingehend repliziert haben.

Datensammlung

Wenn Sie Unterstützung vom Microsoft-Support benötigen, empfehlen wir Ihnen, die Informationen zu sammeln, indem Sie die unter Sammeln von Informationen mithilfe von TSS für Active Directory-Replikationsprobleme beschriebenen Schritte ausführen.