Problembehandlung bei Active Directory-Vorgänge mit Fehler 8606 fehl: "nicht genügend Attribute erhielten ein Objekt erstellen"

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 2028495 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Alles erweitern | Alles schließen

Zusammenfassung

Dieser Artikel beschreibt die Symptome und Ursache der Situation, in welcher Active Directory-Replikation nicht erfolgreich ist, und es generiert Fehler 8606: "nicht genügend Attribute erhielten ein Objekt zu erstellen. Dieses Objekt kann nicht vorhanden, da es möglicherweise gelöscht worden." Dieser Artikel beschreibt außerdem eine Lösung für diese Situation.

Problembeschreibung

1. Die DCDIAG meldet, dass der Active Directory-Replikationen Test fehlgeschlagen mit Fehler 8606 ist: "nicht genügend Attribute wurden gegeben, um ein Objekt zu erstellen."
Test starten: Replikationen
[Replikationen Check, <destination dc="">] ein letzten Replikationsversuch fehlgeschlagen:</destination>
Aus <source dc=""> , <destination dc=""></destination></source>
Namenskontext:<directory partition="" dn="" path=""></directory>
Die Replikation generiert einen Fehler (8606):
Nicht genügend Attribute wurden gegeben, um ein Objekt zu erstellen. Dieses Objekt kann nicht vorhanden, da es möglicherweise gelöscht wurde und bereits Garbage collection
Der Fehler an<date> <time></time></date>
Letzte Erfolg bei aufgetreten<date> <time></time></date>

2. Eingehende Replikation, die ausgelöst wird, durch die Jetzt replizieren Befehl in der Active Directory-Standorte und Dienste-Snap-in DSSITE.MSC fehl und es generiert die folgende Fehlermeldung: "nicht genügend Attribute wurden gegeben, um ein Objekt zu erstellen." Mit der rechten Maustaste auf ein Connection-Objekt aus einem Quell-DC, und dann auswählen "Jetzt replizieren" ist nicht erfolgreich, und es generiert die folgende Fehlermeldung: "Zugriff verweigert." Die On-Screen Text der Fehlermeldung lautet wie folgt:

Dialogfeld Titeltext: Jetzt replizieren
Dialogfeld Meldungstext: der folgende Fehler trat beim Versuch Namenskontext < active Directory-Partition %name% > Synchronisieren von Domänencontroller <source dc=""> Domänencontroller <destination dc="">:</destination></source>

Nicht genügend Attribute wurden gegeben, um ein Objekt zu erstellen. Dieses Objekt möglicherweise nicht vorhanden, da es möglicherweise gelöscht wurde und bereits Garbage collection.

Der Vorgang wird nicht fortgesetzt.


(3) Verschiedene REPADMIN.EXE Befehle fehl mit Fehler 8606. Diese Befehle enthalten sind aber nicht beschränkt auf die folgenden:

Tabelle minimierenTabelle vergrößern
Repadmin / hinzufügen Repadmin/replsum
Repadmin/showreplRepadmin/showrepl
Repadmin/syncall


4. Ereignis 1988 wird protokolliert, kurz nachdem eine der folgenden Ereignisse eintritt:
  1. Der erste Windows Server 2008 R2-Domänencontroller in der Gesamtstruktur bereitgestellt wird.
  2. Alle Aktualisierungen für den partiellen Attributsatz erfolgt.
5. NTDS-Replikation-Ereignis 1988 kann im Verzeichnisdienst-Ereignisprotokoll von Domänencontrollern protokolliert werden, die versuchen eingehende-Replikation von Active Directory.

Typ: Fehler
Quelle: NTDS-Replikation
Kategorie: Replikation
Ereignis-ID: 1988
Benutzer: NT-AUTORITÄT\ANONYMOUS-Anmeldung
Computer:<hostname of="" dc="" that="" logged="" event,="" aka="" the="" "destination"="" dc="" in="" the="" replication="" attempt=""></hostname>
Beschreibung: Der lokale Domänencontroller hat versucht, das folgende Objekt vom folgenden Quelldomänencontroller zu replizieren. Dieses Objekt ist nicht auf dem lokalen Domänencontroller vorhanden, da es möglicherweise gelöscht wurde und bereits Garbage collection.
Quell-Domänencontroller:
<fully qualified="" guided="" cname="" of="" source="" dc=""></fully>
Objekt:
<dn path="" of="" live="" object="" on="" source="" dc=""></dn>
Objekt-GUID:
<object guid="" of="" object="" on="" source="" dcs="" copy="" of="" active="" directory=""></object>

Ursache

8606-Fehler wird protokolliert, wenn ein Quell-Domänencontroller eine Aktualisierung auf ein Objekt sendet (anstelle von einem ursprünglichen Objekt erstellen), die bereits erstellt, gelöscht, und wurde durch die Garbagecollection aus einem Zieldomänencontroller Kopie von Active Directory freigegeben und der Ziel-Domänencontroller wurde so konfiguriert, dass ausgeführt strenge Replikationskonsistenz.

Der Zieldomänencontroller loose Replication Consistency verwenden konfiguriert wurde, würde das Objekt lediglich "auf dem Zieldomänencontroller Kopie des Verzeichnisses wiederbelebt wurden haben". Bestimmte Varianten, die die 8606 Fehler verursachen können, sind im Abschnitt "Weitere Informationen" dokumentiert. Jedoch wird durch eine der folgenden Fehler verursacht:

? Dauerhaft veraltetes Objekt, dessen Entfernung Admin-Eingriff erforderlich ist
? Transiente veraltetes Objekt selbst korrigieren soll, wenn der Quelldomänencontroller seiner nächsten Garbage Collection-Bereinigung durchführt. Die Einführung der ersten Windows Server 2008 R2-Domänencontroller in einer vorhandenen Gesamtstruktur und Updates zu Teilattributsatz sind die Ursachen für diese Bedingung bekannt.
? Ein Objekt, das wiederhergestellt oder an der Schwelle der Tombstone-Lebensdauer-Ablaufdatum wiederhergestellt wurde

Beachten Sie Folgendes, wenn 8606 Fehler zu beheben:

?, Obwohl der 8606-Fehler auf dem Zieldomänencontroller protokolliert wird, befindet sich das Problemobjekt, das Blockieren von Replikation auf dem Quell-Domänencontroller. Darüber hinaus Quell-Domänencontroller oder transitive Replikationspartner des Quelldomänencontrollers potenziell nicht eingehende Kenntnisse über eine gelöschte Tombstone-Life-Anzahl von Tagen in der Vergangenheit Replikation.

? Veraltete Objekte können unter folgenden Bedingungen vorhanden sind:

1. Als "live-Objekte, CNF oder Konflikt Objekte"live"Objekte entstellt, entstellt CNF oder Konflikt Objekte im Container Gelöschte Objekte des Quell-Domänencontroller

2. In jede Verzeichnispartition einschließlich Anwendungsverzeichnispartitionen mit Ausnahme die Schemapartition. Löscht unterstützt die Schemapartition nicht.

(3) In jede Objektklasse (Benutzer, Computer, Gruppen und DNS-Datensätze werden am häufigsten). Veraltete Objekte werden am häufigsten in der Read-only Domain-Partitionen auf globale Kataloge und beschreibbare Domänen gefunden und möglicherweise auch in der Konfigurationspartition gefunden werden.

? Beachten Sie die Suche nach möglicherweise veraltete Objekte durch Objekt-GUID vs. DN-Pfad so, dass Objekte unabhängig von ihrer Host-Partition und der übergeordnete Container gefunden werden können. Suche nach Objectguid wird auch in den Container Gelöschte Objekte werden ohne Verwendung des gelöschten Objekte LDAP-Steuerelements Objekte suchen.

? Die NTDS-Replikation 1988-Ereignis identifiziert nur das aktuelle Objekt auf dem Quelldomänencontroller, der eingehende Replikation von einer strikten Modus Zieldomänencontroller blockiert. Es gibt wahrscheinlich zusätzliche Objekte "hinter" das Objekt, das in der 1988-Ereignis verwiesen wird, die auch für veraltete Objekte sind.

? Das Vorhandensein von veralteten Objekten auf einem Quelldomänencontroller verhindert oder blockiert im strikten Modus Zieldomänencontroller aus eingehende Replikation "guten" Änderungen, die hinter dem veralteten Objekt in der Replikationswarteschlange für die vorhanden sind.

? Aufgrund der Art, dass Domänencontroller einzeln Objekte aus ihren gelöschten Objekts Containern (Garbage Collection-Daemon führt alle 12 Stunden aus dem letzten Start von jedem Domänencontroller letzten), die Objekte löschen, die Ziel-Domänencontroller 8606 Störungen verursacht werden konnte Entfernen in der nächsten Ausführung des Garbage Collection-Cleanup unterzogen werden. Veraltete Objekte in dieser Klasse sind vorübergehend und sollten sich nicht mehr als 12 Stunden aus entfernen Problem starten.
? Das veraltete Objekt betreffende ist wahrscheinlich eine, die von einem Administrator oder eine Anwendung absichtlich gelöscht wurde. Dies in Ihren Plan Auflösung Faktor und Bissiger Wiederbeleben von Objekten, insbesondere von Sicherheitsprinzipalen, die absichtlich gelöscht wurden.

Lösung

(1) Identifizieren Sie den aktuellen Wert für die Gesamtstruktur Tombstone-Lebensdauer Einstellung

c:\>repadmin/showattr. "CN = Directory Service, CN = Windows NT, CN = Services, CN = Configuration, DC Gesamtstruktur-Stammdomäne, DC = = TLD > /atts:tombstonelifetime

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

(2) Für die einzelnen Zieldomänencontroller 8606 Fehler protokolliert wird, Filtern Sie das Verzeichnisdienst-Ereignisprotokoll auf NTDS-Replikation Ereignis 1988.


3. Sammeln von Metadaten für jede eindeutige Objekt, das in der NTDS-Replikation-Ereignis 1988 angeführt ist.

Füllen Sie von jeder 1988-Ereignis, das auf dem Zieldomänencontroller protokolliert wird, die ein neues Objekt zitiert in der folgende Tabelle:

Tabelle minimierenTabelle vergrößern
Objekt-DN-PfadObjekt-GUIDQuell-DCHost-partitionLive oder gelöscht?LastKnownParentIsDeleted-Wert

Spalten 1 bis 5 dieser Tabelle können durch Lesen von Werten direkt aus den Feldern in der NTDS-Replikation 1988-Ereignisse, die in den Verzeichnisdienst-Ereignisprotokollen der Ziel-Domänencontroller protokolliert werden, die das Ereignis 1988 oder 8606 Replikationsstatus protokollieren aufgefüllt werden.

Die Datumsstempel für LastKnownParent und IsDeleted Spalten können durch Ausführen von "Repadmin/showobjmeta" und verweisen auf die Objectguid des Objekts, das im NTDS-Ereignis für die Replikation 1988 zitiert wird bestimmt werden. Verwenden Sie hierzu die folgende Syntax:

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

Die Datumsangabe LastKnownParent Gibt das Datum, an dem das Objekt gelöscht wurde. Die Datumsangabe IsDeleted Erfahren Sie, wenn das Objekt zuletzt gelöscht oder wiederbelebt wurde. Die Versionsnummer erfahren Sie, ob die letzte Änderung gelöscht oder das Objekt wiederbelebt. Ein IsDeleteted der Wert 1 stellt eine anfängliche löschen. Ungerade Werte größer als 1 zeigen eine Wiederbelebung nach mindestens ein Löschvorgang. Zum Beispiel ein isDeleted der Wert 2 repräsentiert ein Objekt, das gelöschte (Version 1) wurde und dann später wiederhergestellt oder wiederbelebt (Version 2). Später geradzahlige Werte für IsDeleted später Reanimations darstellen oder die Wiederherstellung des Objekts.


4. Wählen Sie die entsprechende Aktion basierend auf der Objektmetadaten zitiert in 1988-Ereignis.

Fehler 8606 / NTDS-Replikation 1988-Ereignis wird am häufigsten verursacht durch langfristige Replikationsfehler, die eingehende Replikation von Domänencontrollern verhindert werden Kenntnisse über alle ursprünglichen Löschungen in der Gesamtstruktur. Dies führt dazu, dass veraltete Objekte auf Quell-Domänencontrollern.

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

Wenn das Objekt in der 1988-Ereignis entweder ist ((live auf dem Quell-Domänencontroller) aber (gelöscht, auf dem Zieldomänencontroller länger als die Tombstone-Lebensdauer-Ablauf)), finden Sie unter "Entfernen veralteter Objekte" und "." Objekte in diesem Zustand müssen manuell von einem Administrator entfernt werden.

Gelöschte Objekte vorzeitig aus dem Container Gelöschte Objekte wurden möglicherweise gelöscht Wenn Systemzeit vorwärts in der Zeit auf dem Zieldomänencontroller gesprungen. Überprüfen Sie den Abschnitt "Überprüfen Sie für die Zeit springt".

Wenn das Objekt, das im Ereignis 1988 zitiert wird im Container Gelöschte Objekte des Quell-Domänencontroller vorhanden ist und das Löschdatum ist direkt an der Schwelle der Tombstone-Lebensdauer-Ablaufdatum so, dass das Objekt durch eine oder mehrere Ziel-Domänencontroller durch die Garbagecollection freigegeben wurde und wird durch die Garbagecollection beim nächsten Garbage Collection-Intervall auf Quell-Domänencontroller freigegeben werden (d. h. die veralteten Objekte sind transient), Sie haben die Wahl. Warten Sie, bis der nächsten Ausführung der Garbage Collection das Objekt löschen, oder lösen Sie Garbagecollection auf dem Quelldomänencontroller manuell aus. Finden Sie unter "Manuelles Starten Garbagecollection"). Die Einführung des ersten Windows Server 2008 R2-Domänencontroller oder jede Änderung im Teilattributsatz, kann diese Bedingung führen.

Wenn Repadmin/showobjmeta Ausgabe für das Objekt, das im Ereignis 1988 zitiert hat ein LastKnownParent Wert von 1 gibt an, dass das Objekt gelöscht wurde, und ein IsDeleted Wert von 2 oder einige andere geradzahligen Wert, und für dieses Datum-Stempel IsDeleted ist an der Schwelle für die Tombstone-Lebensdauer-Anzahl der Tage aus den Datumsstempel für verschiedene LastKnownParent, und dann das Objekt wurde gelöscht und dann wiederhergestellt / Auth wiederhergestellt werden, während es war noch live auf dem Quelldomänencontroller aber bereits von der Garbagecollection zurückgefordert durch Zieldomänencontroller Protokollierung Fehler 8606 / 1988-Ereignis. Finden Sie unter Reanimations an der Schwelle der TSL-Ablaufdatum


Entfernen von veraltete Objekten

Zwei Befehle in REPADMIN.EXE kann aus folgenden Verzeichnispartitionen veraltete Objekte entfernen:
  • REPADMIN/REMOVELINGERINGOBJECTS
  • REPADMIN-/REHOST

REPADMIN-/REMOVELINGERINGOBJCTS kann verwendet werden, um veraltete Objekte aus beschreibbar und schreibgeschützten Verzeichnispartitionen auf Domänencontrollern der Windows Server 2003-Quelle entfernen. Die Syntax lautet wie folgt:

c:\>repadmin/removelingeringobjects <dest_dsa_list> <source dsa="" guid=""> <nc> [/ ADVISORY_MODE]</nc></source></dest_dsa_list>

Wo:
<dest_dsa_list>ist der Name eines Domänencontrollers, auf dem Windows Server 2003 oder höher ausgeführt wird, und enthält veraltete Objekte (z. B. der Quelldomänencontroller in der NTDS-Replikation 1988-Ereignis angegeben ist).</dest_dsa_list>
<source dsa="" guid="">ist der Name eines Domänencontrollers, auf dem Windows Server 2003 oder höher ausgeführt wird und, hostet eine überschreibbare Kopie der Verzeichnispartition, die veralteten Objekte enthält, der der Domänencontroller in <dest_dsa_list> verfügt über Netzwerk-Konnektivität.</dest_dsa_list></source>
<nc>ist der DN-Pfad der Verzeichnispartition, die vermutet wird, enthält veraltete Objekte, wie z. B. die Partition, die in einem 1988-Ereignis angegeben ist.<b00></b00></nc>

REPADMIN /REHOST So entfernen Sie veraltete Objekte Domänencontroller, die als Host verwendet werden kann ein Nur-Lesezugriff Kopie einer Domänenverzeichnispartition von Domänencontrollern, die Windows 2000 SP4 oder höher ausgeführt werden. Die Syntax lautet wie folgt:

c:\>repadmin /rehost DSA<naming context=""> <good source="" dsa="" address=""></good></naming>

Wo:
DSA ist der Name eines Domänencontrollers, auf dem Windows 2000 SP4 oder höher und, dass Hosts eine schreibgeschützte Domänenverzeichnispartition für eine nicht lokale Domäne ausgeführt wird. Beispielsweise eine GC in root.contoso.com kann eine schreibgeschützte Kopie der child.contoso.com rehost aber kann nicht erneut speichern, root.contoso.com.

<naming context="">ist der DN-Pfad ein Read-only Domain-Verzeichnispartition, die im globalen Katalog wohnt.</naming>

<good source="" dsa="" address="">ist der Name eines Domänencontrollers, auf dem Windows 2000 SP4 oder höher ausgeführt wird und, eine überschreibbare Kopie von <naming context="">hostet. Der Domänencontroller muss Netzwerk verfügbar, die DSA-Computer.</naming></good>

Wenn das veraltete Objekt, das in der 1988-Ereignis gemeldet wird nicht von Repadmin entfernt wird, zu bewerten, ob das Objekt auf dem Quelldomänencontroller USN Lücke erstellt wurde, oder ob die ursprünglichen Domänencontroller existiert nicht in der Quell-Domänencontroller-Up-to-Dateness Vektorobjekte wie im Microsoft Knowledge Base-Artikel dokumentiert 948071.

Hinweis Veraltete Objekte können auch mithilfe von entfernt werden repldiag.exe. Dieses Tool automatisiert Repadmin/removelingeringobjects.


Active Directory-Replikation Zustandsüberwachung täglich

Wenn Fehler 8606 / 1988-Ereignis wurde verursacht durch den Domänencontroller fehlschlägt, repliziert Active Directory-Änderungen in die letzte Tombstone-Lebensdauer-Anzahl der Tage, stellen Sie sicher, dass Active Directory-Replikation Gesundheit vorwärts gehen täglich überwacht wird. Replikationszustand kann überwacht werden, mithilfe einer dedizierten Überwachungsanwendung oder durch Anzeigen der Ausgabe der Option für eine kostengünstige, aber effektiv ausführen "Repadmin/showrepl * / CSV" Befehl in einer Tabellenkalkulationsanwendung wie Microsoft Excel. (Siehe "Methode 2: Überwachen der Replikation mithilfe einer Befehlszeile" in der Microsoft Knowledge Base-Artikel 910205).

Domänencontroller, die keine eingehende Replikation in 50 Prozent der Tombstone-Lebensdauer-Anzahl von Tagen haben sollten in eine Überwachungsliste, die Priorität Admin Aufmerksamkeit zu Replikation einsatzfähig zu machen. Domänencontroller, die hergestellt werden können, erfolgreich replizieren sollten zwangsweise herabgestuft werden Wenn sie nicht innerhalb von 90 Prozent der TSL repliziert wurden.

Replikationsfehler, die auf einem Zieldomänencontroller angezeigt werden, können der Zieldomänencontroller, von der Quell-Domänencontroller oder durch die zugrunde liegende Netzwerk und DNS-Infrastruktur verursacht werden.


Überprüfen Sie, ob die Zeit springt

Bestimmen, ob ein Sprung Zeit aufgetreten ist, überprüfen Sie Datumsstempel in Ereignis und Diagnoseprotokolle (Ereignisanzeige Repadmin/showreps, Netlogon-Protokolle, Berichte Dcdiag) auf Zieldomänencontrollern, bei der Fehler 8606 anmelden / NTDS-Replikation 1988-Ereignisse für die folgenden:

? Datum-Stempel, die vor die Veröffentlichung des Betriebssystems (z. B. Datumsstempel CY 2003 ein Betriebssystem im CY 2008 veröffentlicht)
? Datum-Stempel, die vor die Installation des Betriebssystems in der Gesamtstruktur
? Datum-Stempel in der Zukunft
? Keine Ereignisse, die in einem bestimmten Zeitraum protokolliert werden müssen

Microsoft Support-Teams haben die Systemzeit auf Produktionsdomänencontrollern falsch Stunden, Tage, Wochen, Jahren und sogar Zehntausende von Jahren in den vergangenen und zukünftigen springen gesehen. Wenn Systemzeit gefunden wurde, zu ungenau ist, sollten Sie korrigieren und wiederholen Sie diesen Schritt, um zu bestimmen, warum Zeit sprang und was kann getan werden, um falsche Uhrzeit vs. Korrektur nur schlechte Zeit Zukunft zu verhindern. Die folgenden: mögliche Fragen an

War ? der Gesamtstrukturstamm-PDC mit eine externen Zeitquelle konfiguriert?
Verweisen ? sind online-Zeit-Quellen im Netzwerk verfügbar und in DNS auflösbar?
Wurde ? die Microsoft oder Drittanbietern Zeitdienst ausgeführt und in einem fehlerfreien Zustand?
? Sind Domain Controller Rolle Computer so konfiguriert, dass um NT5DS Hierarchie Quellcode zu verwenden?
? Rollback-Schutz, die in der Microsoft Knowledge Base-Artikel beschriebene wurde 884776 an Stelle?
Haben ? Systemuhren funktionierende Akkus und genaue Zeit im BIOS auf Domänencontrollern auf virtuellen Host-Computern?
Sind ? virtuelle Host und Gast-Computer so konfiguriert, dass Quelle Uhrzeit entsprechend den Empfehlungen des Herstellers hosting?

Microsoft Knowledge Base-Artikel 884776 Dokumente zum Schutz Domänencontroller aus "listening" Ungültige Zeit Samples. Weitere Informationen zu MaxPosPhaseCorrection und MaxNegPhaseCorrection steht in der W32Time-Blog POST Konfigurieren des Zeitdienstes: Max [Pos/Neg] PhaseCorrection . Microsoft Knowledge Base-Artikel 961027 Beschreibt einige hilfreiche Precision-Aktualisierungen, beim Konfigurieren von zeitbasierten Einstellungen in der Richtlinie.

Für veraltete Objekte mithilfe von "Repadmin/removelingeringobjects /advisorymode" Überprüfen Sie und entfernen Sie sie als erforderlich.

Entspannen Sie "Allow-Replikation mit Divergent und beschädigte Partner" als erforderlich.

Manuelles Starten der Garbagecollection

Manuell Trigger Garbage Collection auf einem bestimmten Domänencontroller gibt es mehrere Optionen:

Führen Sie "Repadmin-/setattr" "" "1" Fügen Sie DoGarbageCollection

Führen Sie LDIFDE/s <server> /i/f dogarbage.ldif dobarbage.ldif, in denen Text enthält:<b00></b00></server>

DN:
ChangeType: ändern
Ersetzen Sie: DoGarbageCollection
Dogarbagecollection: 1
-
Hinweis Die endgültige "-" Zeichen ist ein Obligatorisch Element der .ldif-Datei.


Reanimations an der Schwelle der TSL-Ablaufdatum

Für diese Bedingung vorhanden ist, Repadmin-/showobject "<guid=object guid="" for="" object="" in="" 1988="" event="">" sollte der Bericht, der das Objekt ist<b00></b00></guid=object>
"nicht gefunden" auf dem Zieldomänencontroller aber ist live auf dem Quelldomänencontroller und ein deleted oder eine nondeleted-Objekt.

Eine Überprüfung der Schlüsselfelder von Repadmin/showobjmeta auf dem Quell-Domänencontroller sollten melden, dass die folgenden Bedingungen zutreffen:

LastKnownParent der Wert 1 hat, und seine Datumsstempel an der Schwelle der TSL-Tage in der Vergangenheit. Datum-Stempel zeigt das Löschen des Objekts.

IsDeleted hat die Versionsnummer von 2 (oder einem anderen geradzahligen Wert), wobei Version 1 definiert das Originale löschen und Version 2 ist die Wiederherstellung / Wiederbeleben. Datumsstempel für "IsDeleted = 2" sollte ca. TSL-Anzahl der Tage später als das letzte Datum für LastKnownParent ändern.

Bewerten Sie, ob das betreffende Objekt ein live-Objekt oder ein gelöschtes Objekt bleiben soll. Wenn LastKnownParent hat den Wert 1, etwas oder jemand das Objekt gelöscht. Wenn dies nicht der Fall war ein unbeabsichtigte Löschen, stehen die Chancen gut, dass das Objekt keine Quell-Domänencontroller gelöscht werden sollten, die eine live-Kopie des Objekts verfügen.

Wenn das Objekt für alle Replikate vorhanden sein sollten, sind die Optionen wie folgt:
  • Aktivieren Sie lose Replikation auf den strikten Modus Ziel-Domänencontroller, die nicht das Objekt verfügen.
  • Force-Herabstufen von Domänencontrollern, die bereits Garbage gesammelten Objekts.
  • Löschen Sie das Objekt und dann neu erstellen.

Weitere Informationen

Ursachen für veraltete Objekte


Ursache 1: Der Quelldomänencontroller sendet Aktualisierungen für Objekte, die bereits durch die Garbagecollection auf dem Zieldomänencontroller da freigegeben haben die Quell-Domänencontroller entweder wurde offline oder abgelaufen fehlgeschlagene Replikation für TSL Anzahl von Tagen.

CONTOSO.COM-Domäne enthält zwei Domänencontroller in derselben Domäne. Tombstone-Lebensdauer = 60 Tage. Strict-Replikation ist auf beiden Domänencontrollern aktiviert. DC2 Erfahrungen ein Hauptplatinenfehler. In der Zwischenzeit macht DC1 Ursprung Löschungen für veraltete Sicherheitsgruppen täglich während der nächsten 90 Tage. Nach 90 Tagen offline ist, DC2 erhält eine Ersatzplatine fährt, und dann eine ACL-Änderung auf alle Benutzerkonten stammt vor dem Es eingehende-repliziert Kenntnis der Ursprung von DC1 löscht. DC1 protokolliert 8606 Störungen für Updates von Sicherheitsgruppen, die für die ersten 30 Tage auf DC1 gelöscht werden, die DC2 offline war.

Ursache 2: Quell-DC sendet Aktualisierungen der Objekte an der Schwelle TSL-Ablaufdatum, die bereits durch die Garbagecollection durch freigegeben im strikten Modus Ziel DC.

CONTOSO.COM-Domäne enthält zwei Domänencontroller in derselben Domäne. Tombstone-Lebensdauer = 60 Tage. Strict-Replikation ist auf beiden Domänencontrollern aktiviert. DC1 und DC2 repliziert alle 24 Stunden. DC1 stammt-Löschungen täglich. DC1 ist Platz für W2K8 R2 aktualisiert. Diese Briefmarken neue Attribute für alle Objekte in den Konfigurations- und Domänenpartitionen beschreibbar. Dies umfasst Objekte, die derzeit in den Container für gelöschte Objekte, von der einige 60 Tagen gelöscht wurden und sind jetzt an der Schwelle der Tombstone-Ablaufzeit. Wiedergewinnung von DC2 für einige Objekte, durch die Garbagecollection, die Waren gelöscht TSL Tagen vor dem Zeitplan für die Replikation mit DC2 wird geöffnet. Fehler 8606 protokolliert bis DC1 blockierende Objekte freigegeben von der Garbagecollection.

Aktualisierungen Teilattributsatz können temporäre veraltete Objekte verursachen, die sich nach dem Quelldomänencontroller-Gelöschte Objekte an der Schwelle TSL-Ablaufzeit (z. B. das Hinzufügen der ersten W2K8-R2-Domänencontroller zu einer vorhandenen Gesamtstruktur) Speicherbereinigung klären wird.

Ursache 3: Zeit Sprung auf ein Zieldomänencontroller beschleunigt vorzeitig die Garbagecollection der gelöschten Objekte auf einem Ziel-Domänencontroller.

CONTOSO.COM-Domäne enthält zwei Domänencontroller in derselben Domäne. Tombstone-Lebensdauer = 60 Tage. Strict-Replikation ist auf beiden Domänencontrollern aktiviert. DC1 und DC2 repliziert alle 24 Stunden. Löschungen wird täglich von DC1 stammt. Die Referenz-Zeitquelle, die von DC1 (aber nicht DC2) wird ein Rollforward Kalenderjahr 2039. Dadurch wird DC2, auch eine Systemzeit in CY2039 erlassen. Dies bewirkt, dass DC1 vorzeitig Objekte löschen, die heute von seinem Container Gelöschte Objekte gelöscht werden. Inzwischen DC2 stammt von Änderungen an Attributen auf Benutzer, Computer und Gruppen, die auf DC2 live aber gelöscht, und nun vorzeitig-veralteter auf DC1. DC1 protokolliert 8606 Fehler wenn es weiter inbound-Änderungen für die vorzeitige Gelöschte Objekte repliziert.

Ursache 4: Ein Objekt wird an der Schwelle TSL Ablaufdatum wiederbelebt.

CONTOSO.COM-Domäne enthält zwei Domänencontroller in derselben Domäne. Tombstone-Lebensdauer = 60 Tage. Strict-Replikation ist auf beiden Domänencontrollern aktiviert. DC1 und DC2 repliziert alle 24 Stunden. Löschungen wird täglich von DC1 stammt. Eine Organisationseinheit, die Benutzer, Computer und Gruppen enthält, wird versehentlich gelöscht. Eine Sicherung des Systemstatus, die an der Schwelle TSL, in der Vergangenheit vorgenommen wird ist auf DC2 Auth wiederhergestellt. Die Sicherung enthält Objekte, die auf DC2 live aber bereits gelöscht und durch die Garbagecollection auf DC1 freigegeben.

Ursache 5: Eine Blase USN wird ausgelöst, die Protokollierung der 8606

Sagen, dass Sie beim Erstellen eines Objekts in einer USN-Blase so, dass es keine ausgehende Replikation ist da der Zieldomänencontroller "er denkt" hat das Objekt wegen der Blase. Jetzt, nachdem Blase schließt, und starten Sie die Änderungen erneut replizieren, eine Änderung für das Objekt auf dem Quelldomänencontroller erstellt und als ein veraltetes Objekt auf dem Zieldomänencontroller angezeigt wird. Der Ziel-Controller protokolliert das 860-Ereignis.


Anforderungen für die End-to-End-Kenntnisse der Ursprung von Löschungen replizieren

Active Directory Domain Controller Unterstützung Multimasterreplikation, wenn alle Domänencontroller (holding eine schreibbare Partition) erstellen, stammen kann, zu ändern oder Löschen eines Objekts oder -Attribut (Wert). Kenntnis der Objekt / Attribut Löschungen werden von den ursprünglichen Domänencontroller und einem beliebigen Domänencontroller, die eingehenden replizierten wissen verfügt, wenn ein ursprünglicher Löschvorgang TSL-Anzahl von Tagen beibehalten. (Siehe Microsoft Knowledge Base-Artikel 216996 und 910205)

Active Directory benötigt End-to-End-Replikation von Partition Inhabern transitiv alle ursprüngliche Löschungen für alle Verzeichnispartitionen auf alle Inhaber von Partition repliziert. Fehler beim Eingang einer Verzeichnispartition in einer parallelen TSL-Anzahl der Tage Replikation führt veraltete Objekte. Ein veraltetes Objekt ist ein Objekt, wurde absichtlich von mindestens einem Domänencontroller gelöscht, jedoch fälschlicherweise auf Ziel-Domänencontroller, die nicht eingehend transiente Wissen der eindeutigen Löschungen Replikation vorhanden ist.







Eigenschaften

Artikel-ID: 2028495 - Geändert am: Montag, 18. Juli 2011 - Version: 2.0
Die Informationen in diesem Artikel beziehen sich auf:
  • Windows Server 2008 R2 Standard
  • Windows Server 2008 Standard
  • Microsoft Windows Server 2003 R2 Standard x64 Edition
  • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
  • Microsoft Windows Server 2003, Standard x64 Edition
  • Microsoft Windows Server 2003 R2 Standard Edition (32-bit x86)
  • Microsoft Windows 2000 Server
Keywords: 
kbmt KB2028495 KbMtde
Maschinell übersetzter Artikel
Wichtig: Dieser Artikel wurde maschinell und nicht von einem Menschen übersetzt. Die Microsoft Knowledge Base ist sehr umfangreich und ihre Inhalte werden ständig ergänzt beziehungsweise überarbeitet. Um Ihnen dennoch alle Inhalte auf Deutsch anbieten zu können, werden viele Artikel nicht von Menschen, sondern von Übersetzungsprogrammen übersetzt, die kontinuierlich optimiert werden. Doch noch sind maschinell übersetzte Texte in der Regel nicht perfekt, insbesondere hinsichtlich Grammatik und des Einsatzes von Fremdwörtern sowie Fachbegriffen. Microsoft übernimmt keine Gewähr für die sprachliche Qualität oder die technische Richtigkeit der Übersetzungen und ist nicht für Probleme haftbar, die direkt oder indirekt durch Übersetzungsfehler oder die Verwendung der übersetzten Inhalte durch Kunden entstehen könnten.
Den englischen Originalartikel können Sie über folgenden Link abrufen: 2028495
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com