AD-Replikation fehlerhaft + Tombstoned AD-Controller

[cascade 10]

Hallo zusammen,

 

ich sitze gerade vor einer größeren Installation mit mehreren "Struktur"-Domänen unter einem Stamm und entsprechend vielen DCs. Alle DCs halten DNS (AD-integriert). Exchange-Server existieren mehrere. Windows Server ab 2003R2 bis hin zu 2012R2 ist im Einsatz. Sowohl als Member als auch DC.

Problem, weswegen ich eigentlich hier bin (dieses Problem ist das derzeit einzig "spürbare"): Ein DNS-Eintrag eines Servers wird nicht an alle Standorte repliziert. DAS ist aber nicht das einzige Problem hier.

 

Wie auch immer:

repladmin /showrepl /repsto

an einem der Standorte gibt mir sowohl den

Fehler 8606 (Es wurden nicht genügend Attribute übergeben, um ein Objekt zu erstellen ...)

als auch

Fehler 8614 (Der Verzeichnisdienst kann mit diesem Server nicht replizieren, da die ...)

zurück.

Wiederhole ich die Abfrage an anderen Standorten, bekomme ich ähnliche Fehler.

 

Tatsache ist also wohl, dass ich hier zumindest einen "getombstoneden" DC + lingering objects habe. Ich hab dazu schon ein bissel gelesen - aber richtig sicher bin ich noch nicht:

Wie geht man in so einem Fall strukturiert vor? Wie bekomme ich die Gesamtstruktur wieder dazu, sauber zu replizieren?

Runter- und wiederhochstufen des/der DC ist ja wohl ein ziemlicher Aufwand, oder sehe ich das falsch? Und wie bekomme ich den Übeltäter sicher heraus?

 

Vielen Dank schon mal für die Antworten!

[Reingucker 3]

Bin noch neu, aber hab da paar Gedanken dazu. Ein "getombstoneden DC" existiert doch eigentlich gar nicht. Und, falls der Server physikalisch noch existiert, dürfte er auch nicht starten oder mit jeder Menge Fehlermeldungen. Wenn da trotzdem hin repliziert wird, dann müsste der auch noch unter "Standorte" stehen und bei den anderen Servern in der ntds als Replikationspartner noch drin stehen. Vielleicht muss man den nur dort austragen und irgendwann, wenn die Grabsteinzeit um ist, ist er dann ganz aus dem AD.

[blub 115]

Hallo,

Wegen ein paar lingering objects brauchst du keinen DC neu aufzusetzen.

 

Suche im Eventlog (Directory Service) des DC nach Events 1988, 1388 etc,

http://technet.microsoft.com/de-de/library/cc949134%28v=ws.10%29.aspx#BKMK_1988

diese Events sollten dir sagen, in welcher Partition das oder die "Lingering Objects" liegen.

 

anschließend suchst du dir einen "guten" DC ohne diese Events und rehostest die Partition manuell von dem guten auf den "schlechten" DC   

 

repadmin /rehost <schlechterDC> <guterDC>  <PartitionName>

repadmin /rehost DC01 DC07  DC=subdomain1,DC=Forest,DC=Intern

 

Ist eine Sache von wenigen Minuten

 

blub

[NorbertFe 2.027]

Ich hab schon Forestrecovery gesehen wegen "ein paar lingering objects". ;) Und das war in einer Multidomainumgebung keine Sache von wenigen Minuten. Und ja, da saß vorab der MSPSS mehrere Wochen dran.

 

Bye

Norbert

[blub 115]

ich weiss jetzt leider nicht genau worauf du hinaus willst.

Der Umgang mit Lingering Objects bzw. deren Bereinigung ist in einem großen MultidomainForest, sagen wir mal >1000 DCs,  zwar nicht ganz Tagesgeschäft, aber zumindest Monatsgeschäft :) . Jedesaml ein Forestrecovery bei lingering objects ist natürlich keine ernsthafte Option. 

Es gibt auch noch andere Ansätze zum Entfernen derselbigen, ich persönlich finde "repadmin /rehost"  relativ einfach und sicher.

 

blub

[NorbertFe 2.027]

Ich wollte damit sagen, dass damals zu 2003 Zeiten der MSPSS auch nach Eskalation nur den Auswege über Forestrecovery sah der dann auch durchgeführt wurde.

[Reingucker 3]

Ah, ok. Für mich hat sich sein Problem so angehört als dass irgendjemand diesen DC unter "Users and Computers" gelöscht hat und die Eintragungen für diesen DC unter den NTDS-Settings der anderen DC vergessen hat zu löschen.

[cascade 10]

Danke schon mal für die Antworten. Ich hab ja das Problem, dass mit mindestens einem DC nicht mehr repliziert wird. Durch das Rehosten mit einem sauberen DC, wie von blub beschrieben, macht man diesen wieder zu einem Mitglied der Gemeinde?

 

Ich hatte ursprünglich den Ansatz, auf allen DC den Registrykey unter services/ntds zu setzen, der die Replikation mit "tombstoned" DC zulässt. Wäre das Ergebnis vergleichbar?

 

Edit: Hier http://technet.microsoft.com/en-us/library/cc757610(v=ws.10).aspx ist der Registrykey beschrieben.

bearbeitet 25. November 2014 von cascade

[blub 115]

den "Allow Replication With Divergent and Corrupt Partner,"  würde ich nur nach reiflicher Prüfung aufmachen. Damit schaltest du etliche qualitätssichernde und fehlervermeidende Replikationsfilter einfach ab.

Da würde ich lieber einen DC depromoten und neu promoten. Das ist relativ gefahrlos und musst du sowieso beherrschen.

Wenn du in einer größeren Umgebung unterwegs bist, hast du doch bestimmt noch ein paar Kollegen in der Rückhand. Sprich dich auf jeden Fall mit denen ab, bevor du Schritte unternimmst, deren Auswirkungen du nicht genau kennst.

 

Es gibt übrigens ein relativ neues Tool von MS, um Lingering Objects zu beseitigen:  "Lingering Object Liquidator".   Habs selbst aber noch nicht eingesetzt

http://blogs.technet.com/b/askpfeplat/archive/2014/09/24/lingering-object-liquidator-for-active-directory-is-now-live.aspx

 

blub

[cascade 10]

Hallo Blub,

 

mit größerer Installation meinte ich eher die Komplexität. Ein paar Kollegen habe ich hier also leider nicht.

Tatsache ist, dass an den Standorten neu installierte Firewalls längere Zeit die Replikation verhindert haben. Die Firewalls sind mittlerweile offen und damit wurde das Problem dann auch erkannt. Der Stand ist, dass nahezu alle DCs auseinander laufen. Die Events 1988 usw. findet man auf ziemlich allen DC. Und ich brauche einen Weg, die Replikation wieder hinzubekommen. 

 

Wäre denn eine Lösung, mir einen Referenz-DC herauszusuchen (im Hauptstandort zB) und Repadmin /removelingeringobjects von allen Außenstellen gegen diesen Referenz-DC auszuführen? Damit müssten die DC doch auf einen Stand (den des Referenz-DC) zu bringen sein? Oder sehe ich das falsch?

 

Die Option, einen (oder mehrere) DC zu depromoten, habe ich natürlich immer noch. Dies erschien mir jedoch zu fehleranfällig (kein sauberes Entfernen).

 

Vielen Dank für die Antworten!

[NorbertFe 2.027]

Wieso sollte es nicht sauber entfernt werden? Über wieviele dcs reden wir denn?

[cascade 10]

Hi Norbert,

 

alles in allem reden wir über 20 DC. Davon 2, mit denen nicht mehr repliziert wird, weil die Tombstonezeit abgelaufen ist. Andere replizieren derzeit nicht, weil es lingering objects gibt und "strict replication consistency" an ist.

Kein sauberes Entfernen, weil der entsprechende DC ja ohne Verbindung zu den anderen DC runtergestuft werden muss (weil keine Replikation) und damit potentiell Reste des runtergestuften DC verbleiben.

[cascade 10]

Falls es noch für jemanden relevant sein sollte:

 

Ich habe die Lingeringobjects entfernt, indem ich einen DC zu einem Referenz-DC (refDC) gemacht, indem ich

repadmin /removelingeringobjects refDC DCxGUID <NC>

gegen jeden DC in der Gesamtstruktur (DCxGUID) ausgeführt habe. Damit habe ich alle Objekte auf diesem refDC gelöscht, welche auf den anderen DC noch herumlungerten. Dies habe ich für jeden Namenskontext (<NC>) mit fehlerhaften Objekten wiederholt.

Im nächsten Schritt habe ich den Befehl

repadmin /removelingeringobjects DCx refDC_GUID <NC>

für jeden DC in der Struktur ausgeführt. Damit wurde der "Zustand" des Referenz-DC mit den anderen DC angeglichen. Die Replikation der DC untereinander funktioniert nun wieder normal. Für die Prüfung der Replikation habe ich übrigens neben repadmin das "AD Replication Status Tool" ( http://www.microsoft.com/en-us/download/details.aspx?id=30005) genutzt.

 

Danke nochmal für eure Antworten.

[Reingucker 3]

Danke auch.