NTDS Replication 2092 - nach Ausfall eines Replikationspartners

[jonborno 10]

Guten Tag.

 

Zuerst einen kleinen Überblick über die Konfiguration:

 

DC-1 Hardware 2003 (GC)

DC-2 Virtuell 2008 (GC)

 

Domänenfunktionsebene:

Windows 2000 pur

 

Gesamtstrukturebene:

Windows 2000

 

 

Nun zum egendlichen Problem:

 

Beide Server mussten wegen räumlichen Umbauarbeiten heruntergefahren werden.

 

Der Virtuelle DC-2 ist bootet nach dem wiedereinschalten nur noch mit Bluescreen.

Der Hardware DC-1 bootet ok, meldet aber im Ereignisprotokoll:

 

NTDS Replication (2092)
Dieser Server ist der Besitzer der folgenden FSMO-Rolle, jedoch wird diese nicht als gültig angesehen. Für die Partition, die das FSMO enthält, wurde dieser Server nicht erfolgreich mit irgendeinem der Partner seit dem letzten Neustart des Servers repliziert. Replikationsfehler verhindern die Bestätigung dieser Rolle. 

 

Authentifizierung an der Domäne läuft nur noch Teilweise. Wir haben gestern schon versucht mit NTDSUTIL.EXE und seize <rolle> diese Problem zu beheben. Schien auch so zu funktionieren, bis ich versucht habe heute morgen einen neuen DC-2 aufzusetzten. Dieser konnte sich wieder nicht Authentifizieren.

 

Wie bringe ich den DC1 nun dazu das er seine FSMO Rolle als gültig ansieht?

Habe ich bei NTDSUTIL.EXE evtl. was falsch gemacht?

[Daim 12]

Bonjour,

 

Domänenfunktionsebene:

Windows 2000 pur

 

warum, wenn ohnehin keine Windows 2000 DCs existieren? Stufe den Domänenfunktionsmodus herauf.

 

LDAP://Yusufs.Directory.Blog/ - Domänen- und Gesamtstrukturfunktionsmodus

 

Gesamtstrukturebene:

Windows 2000

 

Hier das gleiche. Stufe den Gesamtstrukturfunktionsmodus auf "Windows Server 2003".

 

Der Virtuelle DC-2 ist bootet nach dem wiedereinschalten nur noch mit Bluescreen.

 

Hast du mal anhand dem Fehlercode der dir oben links angzeigt wird im Internet danach gesucht?

 

Wir haben gestern schon versucht mit NTDSUTIL.EXE und seize <rolle> diese Problem zu beheben.

 

Welche Rollen fehlen "angeblich" denn und welche sind verfügbar bzw. werden mit NETDOM QUERY FSMO angezeigt?

 

Schien auch so zu funktionieren, bis ich versucht habe heute morgen einen neuen DC-2 aufzusetzten. Dieser konnte sich wieder nicht Authentifizieren.

 

Was genau meinst du mit "...wieder nicht Authentifizieren"? Und hast du den neuen Server mit dem gleichen Computernamen wie es der "alte DC 2" hatte zum DC gestuft? Wurde der "alte DC 2" aus den Metadaten des AD entfernt?

 

Bitte formuliere klar und deutlich was bereits durchgeführt wurde und was nicht funktioniert. Dabei ist dir das Eventlog und DCDIAG behilflich.

 

Wie bringe ich den DC1 nun dazu das er seine FSMO Rolle als gültig ansieht?

Habe ich bei NTDSUTIL.EXE evtl. was falsch gemacht?

 

Gecrashte FSMO-Rollen werden mit Gewalt mit NTDSUTIL übernommen. Deine Vorgehensweise kannst du anhand des folgenden Artikels (ganz unten) überprüfen:

 

LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben

[jonborno 10]

Guten Tag,

vielen Danke für deine schelle Reaktion.

 

warum, wenn ohnehin keine Windows 2000 DCs existieren? Stufe den Domänenfunktionsmodus herauf.

 

LDAP://Yusufs.Directory.Blog/ - Domänen- und Gesamtstrukturfunktionsmodus

 

Hier das gleiche. Stufe den Gesamtstrukturfunktionsmodus auf "Windows Server 2003".

Ja ich werde mir diese Gegebenheit anschauen, aber mit der aktuellen Problematik hat dies nichts am Hut oder?

 

Hast du mal anhand dem Fehlercode der dir oben links angzeigt wird im Internet danach gesucht?

Ja, ist nicht das erste mal das die VM (auf ESX) so abschmiert. Obwohl die VM dann auch komplett neu angelegt wurde. Zum Fehlercode des Bluescreen finden sich aber nur Problem im zusammehang mit Hyper-V.

 

Welche Rollen fehlen "angeblich" denn und welche sind verfügbar bzw. werden mit NETDOM QUERY FSMO angezeigt?

 

Für jeden der folgenden fünf Einträge gibt es den Eintrag im Verzeichnisdienst Protokoll:

CN=Schema,CN=Configuration,DC=Marien-kh,DC=MKH

CN=Partitions,CN=Configuration,DC=Marien-kh,DC=MKH

CN=RID Manager$,CN=System,DC=Marien-kh,DC=MKH

CN=Infrastructure,DC=Marien-kh,DC=MKH

und FSMO-Rolle: DC=Marien-kh,DC=MKH

 

NETDOM QUERY FSMO zeigt folgendes:

Schema owner DC-1.Marien-kh.MKH

Domain role owner DC-1.Marien-kh.MKH

PDC role DC-1.Marien-kh.MKH

RID pool manager DC-1.Marien-kh.MKH

Infrastructure owner DC-1.Marien-kh.MKH

 

Was genau meinst du mit "...wieder nicht Authentifizieren"? Und hast du den neuen Server mit dem gleichen Computernamen wie es der "alte DC 2" hatte zum DC gestuft? Wurde der "alte DC 2" aus den Metadaten des AD entfernt?

Nachdem wir gestern mit NTDSUTIL die Rollen "Übernommen" hatten lief die Authentfizierung (RADIUS, Zugriff aufs DFS, Exchange) auf den Clients wieder.

So habe ich mich dran gemacht einen neuen DC2 mit selben namen zu erstellen.

Dazu habe ich das Computerkonto aus dem Container "Domain Controllers" entfernt und bei der folgenden Abfrage ausgewäht das der DC nicht mehr funktioniert. Der DCPROMO Assistenten den ich nun auf dem neuen DC2 durchlaufen habe erkannt das es einen alten DC2 gab.

DCPROMO konnt ich bis zur eigendlichen "installtion" durchlaufen, doch dann öffnete sich in Login-Promp mit der Meldung das kein DC zur Authentifizierung verfügbar sei.

 

 

Bitte formuliere klar und deutlich was bereits durchgeführt wurde und was nicht funktioniert. Dabei ist dir das Eventlog und DCDIAG behilflich.

Gecrashte FSMO-Rollen werden mit Gewalt mit NTDSUTIL übernommen. Deine Vorgehensweise kannst du anhand des folgenden Artikels (ganz unten) überprüfen:

Wie NETDOM QUERY FSMO zeigt sind alle Rollen dem DC1 zu geordnet auch in den Grafischen Oberflächen (mmc).

 

Bring mich nun ein Neustart des DC1 weiter?

 

Scheinbar ist doch noch immer ein Replicationspartner eingetragen durch den diese "ungültigkeit" zu stande kommt.

Kann man diesen Partner nicht entfernen?

bearbeitet 7. Mai 2010 von jonborno

[jonborno 10]

Nach einem Neustart des DC1 konnte ich nun einen weiteren DC neuinstallieren.

Anschließend habe ich den alten defekten DC2 mit Hilfe des folgenden KB Artikel entfernt.

 

Entfernen von Daten aus Active Directory nach fehlgeschlagener Domänencontroller-Herabstufung