Jump to content

DC - USN von Hand erhöhen?


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo zusammen,

 

Ich habe ein Netz mit mehreren DCs (2000, 2003, 2008). Einer der Server war wegen Problemen die letzten 9 Tage nicht am Netz. Ich will jetzt die AD mit dem Stand von diesem Server haben.

Inzwischen ist die USN bei meinen anderen Server natürlich hoher als auf dem "Problemserver".

Daher meine Frage:

 

Kann ich bei einem 2000/2003 Server die USN (Update Sequence Number) manuell erhöhen?

Also quasi wie bei einem autorisierenden Restore, bloß eben ohne Restore?

Geht das irgendwie mit ntdsutil o.ä.?

 

Vielen Dank für eure Antworten!

 

Wenn ihr mehr Infos braucht gerne, dann muss ich bloß sehr weit ausholen, das wollte ich euch & mir ersparen... ;-)

 

Gruß Jochen

Link zu diesem Kommentar

Hi Jochen,

 

ganz so einfach ist das nicht... :wink2:

 

Vielleicht beschreibst Du noch einmal den Hintergrund für Dein Anliegen. Im Kern kannst Du einige Verfahren des Forest Recovery fahren, aber sicherlich gibt es bessere Möglichkeiten.

 

Download details: Forest Recovery

 

Download details: Best Practices: Active Directory Forest Recovery

 

Auch das autorative Wiederherstellen des Domain und Config NC sollte gut überlegt und im besten Fall vermieden werden.

Geht es unter Umständen "nur" um einige Benutzer- oder Gruppenobjekte oder ist da mehr im Argen?

 

Viele Grüße

olc

Link zu diesem Kommentar

Öhm, bist du dir absolut sicher, das du den Stand eines DC's der wegen Problemen nicht am Netz war auf einmal in deine Domain pusten willst?

 

Mir ist beim besten Willen nicht klar wofür man sowas machen will... Vielleicht könntest du doch ein wenig weiter ausholen und uns die Situation ein wenig genauer erläutern, vielleicht findet sich ja auch ein anderer Weg um dein eigentliches Ziel zu erreichen.

 

/Edit: da können nur Sekunden dazwischen gelegen haben olc ;)

Link zu diesem Kommentar

Okay, dann hole ich mal aus! :)

 

Wir haben im Netz eine Rootdomain mit einem Win2000. Das ist keine Produktivdomain.

Wir haben eine Subdomain mit 7 DCs (2003 & 2008).

 

Wir haben 2x ESX am Laufen, darauf sind u.a. 3 2008er DCs und der 2000er (aus der Root) virtualisiert. 3 DCs (2003) laufen noch physikalisch.

Der 2000er wurde erst kurz vor Weihnachten virtualisiert, die physikalische Kiste steht noch neben dran.

Vor 9 Tagen gabs einen Stromausfall, die beiden ESX sind heruntergefahren und haben beim manuellen Reboot die VMs nicht geladen (weil wir es wohl vergessen hatten einzustellen ->automatisch starten).

Da über die Feiertage schnell geholfen werden musste hat dann jemand den alten 2000er (physikalisch) einfach wieder eingeschaltet......

 

So, und nun würden wir gerne die VMs der beiden ESX wieder in Betrieb nehmen.

Als Problem kommt hinzu, dass nach der damaligen Virtualisierung vom 2000er DC die GUIDs neu erstellt werden mussten, da das SYSVOL nicht repliziert wurde.

 

Ich dachte mir nun, wir setzen die USN beim 2000er VM-DC hoch, fahren die physikalische Kiste runter und hängen die VMs alle wieder dran, dann bekommen die 3 physikalischen DCs die Updates von meiner intakten (das war meine VM-Umgebung bis zum Stromausfall) Umgebung.

 

Ich hoffe ich hab mich einigermaßen verständlich ausgedrückt.

 

?Any help?

 

 

Gruß Jochen

Link zu diesem Kommentar

Öhm, wenn ich das recht verstehe, dann habt ihr eigentlich garkeine richtig intakte Umgebung mehr:

1. Die virtuellen DCs waren ne Weile aus durch den Stromausfall ==> inkonsistent.

2. Der physikalische DC war vor dem Stromausfall aus und hat nichts mehr mitbekommen und ist dann in einem inkonsistenten Zustand in Betrieb genommen worden.

 

Also hast du auf gut deutsch die Wahl zwischen Pest und Cholera, aber viel besser als jetzt wird es nicht werden. Während der 9 Tage Verlust wird sich ja sicher was im AD getan haben, was dann auf dem physikalischen DC ausgeführt wurde. Damit ist dieser aus meiner Sicht der aktuellste DC. Oder hab ich das immer noch nicht verstanden?

Link zu diesem Kommentar

Ja, der 2000er DC ist momentan der aktuellste.

Das Problem, wenn ich den einfach noch mal virtualisiere ist, dass die vorhandenen VMs bereits andere GUIDs haben. Da weiß ich nicht wie sich das verhält.

Im Augenblick schmeißt das System natürlich Fehler ohne Ende, da die VMs noch down sind.

Die VMs sind soweit intakt, ich weiß bloß leider auch nicht was passiert wenn ich die Kisten starte (und die 2000er DC-VM auslasse).

 

Ist mein Ansatz/Wunsch mit der USN-Erhöhung arg abwegig?

Oder bin ich da komplett auf dem falschen Dampfer?

Link zu diesem Kommentar

Die anderen GUIDs haben sie aber auch, wenn du den 2000er DC nicht virtualisierst. Da der physikalische 2000er im Moment eh der aktuellste ist, wirst du sowieso den "aktuellen" Stand erstmal replizieren müssen, oder seh ich das falsch?

 

Insgesamt kann ich auch dein Server- und Domänenkonstrukt grade noch nicht genau erfassen. Vielleicht kannst du uns mit (gerne auch gefakten) Servernamen und Domänenangaben mal deine Domänenstruktur ein wenig näher bringen, damit wir uns ein genaueres Bild von der aktuellen Situation machen können. Schreib dann auch dazu, welche Server virtuell und welche physikalisch sind und welche die sind, die grade aus sind. So das man das ganze anständig erfassen und gedanklich verarbeiten kann.

Link zu diesem Kommentar

Hi,

 

also ich versuche für mich das ganze hier gedanklich mal ein wenig zu sortieren, aber ich mir fällt es schwer die Aktionen nachzuvollziehen. Schauen wir mal...

 

/Edit: da können nur Sekunden dazwischen gelegen haben olc ;)

 

:D Der frühe Vogel frißt den Wurm. :D

 

Der 2000er wurde erst kurz vor Weihnachten virtualisiert, die physikalische Kiste steht noch neben dran.

Vor 9 Tagen gabs einen Stromausfall, die beiden ESX sind heruntergefahren und haben beim manuellen Reboot die VMs nicht geladen (weil wir es wohl vergessen hatten einzustellen ->automatisch starten).

Da über die Feiertage schnell geholfen werden musste hat dann jemand den alten 2000er (physikalisch) einfach wieder eingeschaltet......

 

Wenn ich das ganze richtig verstehe, dann dürfte es in diesem Moment zu einem USN-Rollback gekommen sein. Der Windows 2000 DC der Root-Domain hätte also nicht mehr mit den anderen DCs replizieren dürfen (automatisch).

 

P.S.: Einen einzigen DC (und dann noch Windows 2000) in der Root-Domain zu betreiben ist "sportlich"... :shock:

 

Als Problem kommt hinzu, dass nach der damaligen Virtualisierung vom 2000er DC die GUIDs neu erstellt werden mussten, da das SYSVOL nicht repliziert wurde.

 

Was genau meinst Du damit?

 

Ich dachte mir nun, wir setzen die USN beim 2000er VM-DC hoch, fahren die physikalische Kiste runter und hängen die VMs alle wieder dran, dann bekommen die 3 physikalischen DCs die Updates von meiner intakten (das war meine VM-Umgebung bis zum Stromausfall) Umgebung.

 

Nein, der wirklich korrekte Weg wäre hier meines Erachtens ein Forest Recovery, sollten korrekte Backups vorhanden sein.

 

Also hast du auf gut deutsch die Wahl zwischen Pest und Cholera, aber viel besser als jetzt wird es nicht werden.

 

ACK.

 

Ja, der 2000er DC ist momentan der aktuellste.

 

Nein, ist er nicht. Er hat entweder wegen des USN-Rollbacks gar nicht mehr repliziert oder ist in einem undefinierten Zustand. Also sprich lieber nicht von "aktuell". ;)

 

Das Problem, wenn ich den einfach noch mal virtualisiere ist, dass die vorhandenen VMs bereits andere GUIDs haben. Da weiß ich nicht wie sich das verhält.

 

Gleiche Frage wie oben - was genau meist Du damit? Habt Ihr ein authoritative restore des DCs durchgeführt?

 

Ist mein Ansatz/Wunsch mit der USN-Erhöhung arg abwegig?

 

Ja!

 

Oder bin ich da komplett auf dem falschen Dampfer?

 

Ja, laß die Finger davon! Abgesehen von der Idee als solches ist das technisch auch nicht möglich bzw. vorgesehen (bzw. nicht in der Art und Weise, wie Du Dir das überlegt hast; für den "Normalfall" erledigt eine autorative Wiederherstellung in den vorgegebenen Limitierungen das Ganze).

 

<MEINE MEINUNG>

Ganz ehrlich: Es ist nicht böse gemeint wenn ich sage, daß wir hier wahrscheinlich an den Grenzen eines Forums angelangt sind. Wenn Du Datenverlust und Produktionsausfall vermeiden möchtest halte jetzt lieber die Füße still, führe keine weiteren Aktionen durch und hole Dir einen kompetenten Dienstleister ins Haus.

 

Ich mag mich irren, aber so wie das klingt, würde alles andere in einem noch größeren Problem enden...

</MEINE MEINUNG>

 

Viele Grüße

olc

Link zu diesem Kommentar
Als Problem kommt hinzu, dass nach der damaligen Virtualisierung vom 2000er DC die GUIDs neu erstellt werden mussten, da das SYSVOL nicht repliziert wurde.

 

Wohin hätte er das replizieren sollen? Gibt es da noch mehr DCs in der Root?

Wie sieht denn die Sicherungstrategie aus, will heißen, welche ordentlichen Sicherungen sind denn von welchen DCs vorhanden?

 

Ansonsten schließe ich mich olc's obigen Ausführungen an. Da ist einiges am brodeln .....

Vorschlag: entnimmst du auch olc's Beitrag ;)

 

 

grizzly999

Link zu diesem Kommentar

Moin,

 

also, weckt mich auf, wenn ich was übersehe, aber:

 

Wenn die Root-Domäne nur einen DC hat, gibt es dort ja keinen lokalen Replikationspartner. Ein USN Rollback, so aufgetreten, kann hier also keine Folgen haben (mit Ausnahme eines veralteten Datenstands in der Root-Dom selbst). Höchstens in der Config- und der Schema-Partition könnte so etwas aufgetreten sein. Halte ich für unwahrscheinlich. Und wenn, dann sollte es ja einschlägige Fehlermeldungen im Eventlog geben. (Gibt es die?)

 

In der Subdomäne sind von 7 DCs drei online und vier offline. Ich sehe da jetzt auch gerade nicht das Problem, wenn man die vier einfach wieder hochfährt (warum sollten die inkonsistent sein?!) - mit Ausnahme des virtuellen Root-DCs natürlich.

 

Jochen, welche Fehler werden dir denn gemeldet? Vielleicht ist die Situation ja tatsächlich gar nicht so dramatisch. Nur vom Herumfummeln an den USNs würde ich die Finger lassen.

 

Gruß, Nils

Link zu diesem Kommentar

Hi Nils,

 

wie Du schon sagst - minimum der Configuration NC läuft sicherlich in einen USN Rollback (Schema wird ja hoffentlich in der Zwischenzeit nicht verändert worden sein). Weiterhin kannst Du Probleme mit den Computerkonten / Kennwörtern der DCs bekommen, damit NTLM und Kerberos Probleme etc. pp. - die Liste geht noch weiter.

 

Man kann daran herumfrickeln, man kann schauen, ob man es irgendwie mit Backups hingebogen bekommt, z.B. mittels autorativer Wiederherstellung des Config NC und des Domänen NCs (oder schlimmstenfalls mittels eines kompletten Forest Recovery), man kann eine Domänenmigration durchführen (solange die Root- und Child-Domäne noch betriebsfähig ist) usw. - das ist nicht der Punkt.

 

Wenn aber der TO (und das meine ich jetzt nicht böse) vom "Hochschrauben der USNs" spricht, dann sollte dort vielleicht erst einmal jemand drüber schauen, der die Abhängigkeiten kennt und die zugrunde liegende Technik in der Tiefe versteht. Weiterhin wurden scheinbar einige Aktionen durchgeführt, die nicht wirklich gut geplant waren.

 

Und genau daher die Empfehlung oben von mir (und grizzly999) das hier nicht in einem Forum zu klären. Es handelt sich zwar scheinbar nicht um eine größere Umgebung - aber auch keine sehr kleine... Fällt etwas aus, weil wieder ein falscher Knopf gedrückt wurde, werden die Probleme nur noch größer. Meines Erachtens habe ich auch nicht von inkonsistent gesprochen, sondern von undefiniert. Das ist ein Unterschied zu "inkonsistent" - weiterhin vom Root DC, nicht den Child-DCs. Obwohl hier der Zustand auch nicht wirklich klar ist. Also ebenfalls undefiniert.

 

Aber das entscheidet der TO dann sicher selbst und muß es notfalls auch intern verargumentieren. Von daher ziehe ich mich aus dieser Diskussion lieber einmal zurück.

 

Viele Grüße

olc

Link zu diesem Kommentar

Moin,

 

minimum der Configuration NC läuft sicherlich in einen USN Rollback.

 

ich würde eher sagen "maximal", und auch das ist eher unwahrscheinlich.

 

Einen Fehler durch USN Rollback gibt es nur, wenn der zurückgesetzte DC eine Änderung an einem replizierten Objekt mit einer USN ausführt, die er seinen Replikationspartnern schon mal übertragen hat. Da der 2000er erst kürzlich virtualisiert wurde, halte ich die Wahrscheinlichkeit, dass dies geschieht, hier für ausgesprochen gering - wie oft ändert sich schon was in der Config-Partition? Und wenn der Fall eingetreten ist, sollte sich das anhand einer ausdrücklichen Fehlermeldung ablesen lassen - man braucht also gar nicht zu spekulieren, sondern man kann nachsehen.

 

Weiterhin kannst Du Probleme mit den Computerkonten / Kennwörtern der DCs bekommen, damit NTLM und Kerberos Probleme etc. pp.

 

In dem aktuellen Szenario wohl kaum. In der Root gibt es ja nur einen DC. Und Kennwörter werden nicht in andere Domänen repliziert.

 

Und genau daher die Empfehlung oben von mir (und grizzly999) das hier nicht in einem Forum zu klären.

 

Da stimme ich euch durchaus zu. Ich würde nur die Fehlersituation selbst erst mal deutlich entspannter sehen. (Sofern natürlich hinterher nicht noch wild dran rumgemacht wurde, was ja leider aus Panik leicht passiert.)

 

Gruß, Nils

Link zu diesem Kommentar

Hi Nils,

 

ich würde eher sagen "maximal", und auch das ist eher unwahrscheinlich.

 

Gut - jetzt können wir noch Stunden so weiter machen ;) : Aber gerade in der Konstellation wird es zu Änderungen am Configuration-NC kommen. Denn hier sind auch unter anderem die Connection Objects enthalten - wurden in der Zwischenzeit mehrfach DCs aus und eingeschaltet, kann sich die Topologie oft ändern. Dann ein mehrmaliges Wechseln des Root-DCs, schon läufst Du in den Rollback.

 

In dem aktuellen Szenario wohl kaum. In der Root gibt es ja nur einen DC. Und Kennwörter werden nicht in andere Domänen repliziert.

 

Für die Trusts als auch Kerberos Tickets müssen gemeinsame "geheime" Informationen zur Verfügung stehen, um die Nounces o.ä. zu verschlüsseln und zu validieren. Und genau die müssen auch ausgetauscht werden. Klar - nun kann man sich darüber "streiten", ob das nun genau in der kurzen Zeit passiert sein könnte. Ich gebe Dir diesbezüglich Recht, daß man hier einen genaueren Blick auf die Umgebung und ggf. Fehlermeldungen werfen müßte. Aber genau das bestätigt mich in meiner Empfehlung, das hier nicht im Board zu klären.

 

Da stimme ich euch durchaus zu. Ich würde nur die Fehlersituation selbst erst mal deutlich entspannter sehen. (Sofern natürlich hinterher nicht noch wild dran rumgemacht wurde, was ja leider aus Panik leicht passiert.)

 

Genau das ist der Punkt - das ist passiert, lies Dir noch einmal die Beschreibung oben durch. Also noch ein Punkt mehr lieber jemanden mit Tiefenkenntnis daran zu setzen.

 

Aber Nils, laß uns an dieser Stelle mit der "Auseinandersetzung" der vielen "wenns und abers" Schluß machen. Ich weiß worüber ich spreche, Du weißt es auch. Der TO soll einfach selbst entscheiden, ob er die nötige Sachkenntnis mitbringt.

 

Viele Grüße

olc

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...