2x DCs Replikationsfehler Tombstone Ablaufzeit überschritten

[Wolke2k4 11]

Hallo,

 

ich benötige Hilfe zur folgenden Problemstellung:

 

2x W2K3 DCs: 1x mit SP2 1x ohne SP

 

Der DC mit den FSMO Rollen (der mit SP2) bringt im Eventlog folgende Meldungen:

 

Ereignistyp:	Fehler
Ereignisquelle:	NTDS Replication
Ereigniskategorie:	Replikation 
Ereigniskennung:	2042
Datum:		25.09.2010
Zeit:		15:31:47
Benutzer:		NT-AUTORITÄT\ANONYMOUS-ANMELDUNG
Computer:	DC1
Beschreibung:
Es ist zu lange her, dass dieser Computer zuletzt mit dem genannten Quellcomputer repliziert hat. Die Zeit zwischen den Replikationen mit dieser Quelle hat die Tombstone-Ablaufzeit überschritten. Die Replikation mit dieser Quelle wurde beendet. 
Der Grund dafür, dass das Fortsetzen der Replikation nicht zugelassen wird, ist, dass die Sicht der beiden Computer in Bezug auf gelöschte Objekte sich nun ggf. unterscheidet. Der Quellcomputer hat ggf. noch Kopien von Objekten, die auf diesem Computer gelöscht (und in die Sammlung veralteter Objekte aufgenommen) wurden. Würde der Replikation zugelassen, könnte der Quellcomputer Objekte zurückgeben, die bereits gelöscht wurden. 
Zeitpunkt der letzten erfolgreichen Replikation:
2009-04-15 15:13:09 
Aufrufkennung der Quelle: 
062cf6c8-f6b8-062c-0100-000000000000 
Name der Quelle: 
cccce171-bdfc-4e36-9779-1e0728ae4075._msdcs.name1.name2.net 
Tombstone-Ablaufzeit (Tage): 
60 

Der Replikationsvorgang ist fehlgeschlagen.

Benutzeraktion:

Ermitteln Sie, welcher der beiden Computer von der Gesamtstruktur getrennt wurde und nun veraltet ist. Sie haben drei Möglichkeiten: 

1. Stufen Sie den/die Computer herunter, die getrennt wurden, oder installieren Sie ihn/sie neu. 
2. Verwenden Sie das Tool "repadmin /removelingeringobjects", um inkonsistent gelöschte Objekte zu entfernen, und setzenn Sie dann die Replikation fort. 
3. Setzen Sie die Replikation fort. Möglicherweise werden inkonsistent gelöschte Objekte eingeführt. Sie können die Replikation fortsetzen, indem Sie den folgenden Registrierungsschlüssel verwenden. Es wird empfohlen, zur Wiederherstellung des Schutzes den Schlüssel zu entfernen, sobald das System ein Mal repliziert hat. 
Registrierungsschlüssel:
HKLM\System\CurrentControlSet\Services\nTDS\Parameters\Allow Replication With Divergent and Corrupt Partner

 

Sowie davor noch die Ereignisse 1864 und 2092.

 

Auf dem zweiten DC (der ohne SP) gibt es ähnliche aber nicht die gleichen Fehlermeldungen. Dazu die EventIDs 1837, 1586 und 1837

 

Nach ein wenig googeln bin ich offenbar nicht der Einzige mit solchen Problemen. Eine Lösungsfindung gab es bspw. hier mit Verweis auf die beiden Links (1. Link, 2. Link)

 

Mein Problem ist jetzt, dass ich noch nicht so recht verstehe, was da gemeint ist. Wie z.B. finde ich heraus, welcher DC der "gute" DC ist? Und welche Lösung soll ich letztendlich anwenden?

 

Ich hoffe, das mir jemand weiterhelfen kann.

 

Gruß Wolke

[zahni 550]

Nun Deine DC's haben über eine längere Zeit nicht miteinander repliziert. viellicht war eine aus oder beide verwenden keine synchrone Zeit (warum auch immer). Auch ist es keine gute Idee DC's mit unterschiedlichen SP-Versionen zu betreiben.

 

Wie Du da rauskommst ? Wenn es ein produktives System ist, empfehle ich Dir dringend professionelle Hilfe zu suchen. Wenn Du was falsch machst, hast Du unter Umständen noch mehr Probleme.

 

 

-Zahni

[P.Foeckeler 11]

Hallo,

 

Dein großes Problem: Du hast (lediglich) zwei DCs, die länger als die TombstoneLiftime (bei Dir 60 Tage) nicht mehr repliziert haben. Man kann jetzt nicht so genau sagen, dass einer der "gute" und der andere der "schlechte" DC ist....es sei denn einer von beiden war wirklich so lange vom Netz oder sonstwie offline... Aber das hört sich ja eigentlich ncht so an - irgendein anderer Grund hat die beiden die lange Zeit über nicht replizieren lassen.

 

Die Links mit den Heilungsmethoden, die Du genannt hast, beziehen sich alle auf ein Szenario, in denen ein einziger DC von mehreren aus der Replikation rausgefallen ist und wie man diesen identifiziert und das dann wieder geradebiegt.

 

Bei Dir jedoch könnte folgende Situation vorherrschen: Die User werden (falls die DCs in der selben AD-Site sind) per Zufall an einen von beiden DCs angemeldet. Bei Änderungen an Objekten (z.B. Passwörter) wird das jeweils an einem DC gemacht, aber nicht zum anderen repliziert. So geraten die internen Datenbanken der beiden DCs so langsam "auseinander"...Welchen DC kannst Du jetzt als "gut" bezeichnen? Keinen irgendwie...hmmm.

 

Man würde hier tatsächlich mal versuchen, die so genannten "Lingering Objects" zu entfernen (LDAP://Yusufs.Directory.Blog/ - Lingering Objects (veraltete Objekte)) und schauen, ob die Replikation danach wieder in Gang kommt.

 

Falls das nicht funktioniert, dann muß einer der beiden mt DCPROMO /forceremoval herauntergestuft werden (die Änderungen in dessen DB sind dann halt verloren...), der andere verbleibende DC muß dann aber auch funktionieren! => Vorher durch temporäres Offline-Setzen testen und Systemstate BAckups bitte! Dann ein Metadata Cleanup, um die reste des rausgehauenen DCs zu entfernen und mit DCPROMO die rausgenommene MAschine wieder als DC hinzufügen...

 

Alles in allem kein trivialer Vorgang. Ich kann mich dem Ratschlag von zahni hier egentlich nur anschließen: Falls das ein produktives System ist, überleg Dir gut ob Du Dir da evtl. Hilfe dazuholst...

 

Viele Grüße,

Philipp

[Wolke2k4 11]

Danke für die Antworten, das Problem ist gelöst.

 

Mein Vorgehen wie folgt:

 

- Alle Server und Clients runterfahren

- Sicherung beider DCs mittels Image

- Registrykey Allow Replication With Divergent and Corrupt Partner nach Event ID 2042: It has been too long since this machine replicated: Active Directory erstellen

- Server booten, Replikation schaut gut aus, Registrykey entfernen

- Server erneut booten

- Server die Nacht über alleine laufen lassen, Kontrolle am Morgen --> AD wieder ok, keine Replikationsfehler

 

Das AD war hier wohl nicht so defekt wie es den Anschein gemacht hat.

 

Wäre das in die Hose gegangen hätten wir die Images zurückspielen lassen und MS Support kontaktiert.

[Innuendo 10]

An dieser Stelle kann ich nur dazu raten, die fsmo Rollen zu kontrollieren und mit deiner Netzwerkdoku zu vergleichen. So einen Fehler hatte ich mal bei einem Kunden als wiederkehrendes Ärgernis gesehen. Ggfs würde ich bei deinem Szenario die fsmo Rollen temporär auf einen DC (auf den Schemamaster) übertragen, einen dritten DC installieren und den zweiten temporär herunterstufen. Abschließend die fsmo Rollen wieder auf die vorhandenen DCs verteilen. Über diesen Weg veranlasst man Win eine neue Replikation aufzubauen. Falls Du besondere Partitionen im AD erstellt hast, muss das bedacht werden. Backup Systemstate!