Sysvol Restore

[LarryLaffer 10]

Hi,

 

ich bin auf der Suche nach einem Dokument, welches einen Restore des Sysvol unter Verwendung von Windows Server 2008 und NTFRS beschreibt. Hat jemand einen Link für mich oder das schonmal durchgespielt?

 

Die KB Artikel von Microsoft beschreiben dieses Szenario entweder für 2003 oder für 20008 & DFSR.

 

Zudem noch ne andere Frage zu der Problematik. Ich habe einige teils widersprüchliche Infos zum -authsysvol schalter von wbadmin gelesen. Dieser Schalter ist doch eigentlich für ein Sysvol das mit DFS-R repliziert wird, richtig?

 

 

Grüße, Larry

[olc 18]

Hi Larry,

 

über welches Wiederherstellungsszenario redest Du - es existieren noch funktionstüchtige DCs (in dem Fall D2/d4 wie unter 2003) oder geht es um ein domain recovery, also keine anderen DCs existieren mehr in der Domäne (authsysvol).

 

Authsysvol greift auch für FRS, siehe dazu: Performing a Nonauthoritative Restore of AD DS --> Problem kann hierbei nur werden, daß der D4 Wert beim Restart wieder überschrieben wird, da ja der Systemstate zurückgesichert wurde und damit beim Neustart auch der Schlüssel überschrieben wird. Meines Erachtens ein Fehler in der Logik des Restores.

 

Daher nach dem Authsysvol noch einmal in den DS Restore Modus fahren, den D4 Schlüssel manuell setzen, neu starten. Damit sollte es klappen.

 

Insgesamt ist es empfehlenswert, ab Domänenmodus 2008 die FRS zu DFSR SYSVOL Migration durchzuführen.

 

Viele Grüße

olc

[Daim 12]

Servus,

 

Daher nach dem Authsysvol noch einmal in den DS Restore Modus fahren, den D4 Schlüssel manuell setzen, neu starten.

 

warum im DSRM? D4 kann man doch auch im laufenden Betrieb setzen.

[LarryLaffer 10]

Hi olc,

 

es geht mir um das Szenario, dass kein DC mehr ein intaktes Sysvol hat. D.h. z.B. alle GPOs wurde gelöscht. D.h. ich restore den Systemstate eines DC und setze dort den D4 während ich bei allen anderen DCs einen D2 fahre.

 

Deine andere Aussage bzgl des -authsysvol ist so nicht korrekt. Der Burflags Schlüssel wird erst nach dem Reboot automatisch auf D4 gesetzt und folglich verschwindet der Wert dann auch gleich wieder sobald der NTFRS Dienst gestartet werden.

 

Grüße, Larry

[olc 18]

Hi zusammen,

 

@Yusuf: Damit der DC schlichtweg nicht beim ersten Reboot als nicht authorativer Partner versucht, die Daten von einem anderen DC zu replizieren. Dann würden die wiederhergestellten Daten überschreiben. Wenn - wie Larry sagte - D4 korrekt bestehen bleibt (auch nach dem Reboot, so wie es sein sollte), dann entfällt der Schritt natürlich.

 

@Larry: Mein Fehler, mir ist gerade aufgefallen, daß ich den Schlüssel "Repl Perform Initial Synchronisations" meinte, nicht die Burflags. Sorry für die Verwirrung. :)

 

Deiner Aussage entnehme ich, daß Du das fragliche Vorgehen nun erfolgreich getestet hast? Alle Fragen geklärt? ;)

 

Viele Grüße

olc

[Daim 12]

@Yusuf: Damit der DC schlichtweg nicht beim ersten Reboot als nicht authorativer Partner versucht, die Daten von einem anderen DC zu replizieren. Dann würden die wiederhergestellten Daten überschreiben.

 

Das habe ich verstanden und dem stimme ich auch zu. Ich beziehe mich aber auf diese Aussage:

 

Authsysvol greift auch für FRS, siehe dazu: Performing a Nonauthoritative Restore of AD DS --> Problem kann hierbei nur werden, daß der D4 Wert beim Restart wieder überschrieben wird, da ja der Systemstate zurückgesichert wurde und damit beim Neustart auch der Schlüssel überschrieben wird.

 

Also wenn der Schlüssel nach einer System State Rücksicherung überschrieben wurde, warum noch einmal im DSRM starten um D4 zu setzen, anstatt direkt, ohne im DSRM zu starten das D4 setzen? Oder schmeiße ich da jetzt was durcheinander? Bitte nicht falsch verstehen, mir geht es hier nicht um "Erbsenzählen", ich möchte es gerne verstehen. ;)

[LarryLaffer 10]

@Yusuf:

Ich habs getestet. Im DSRM Mode gebootet, Systemstate -authsysvol zurückgespielt, in normalen Mode gebootet => System mach einen D4. Also alles im grünen :D

[olc 18]

@Yusuf: Vrweg sei gesagt, daß ich mich wie gesagt mit dem Schlüssel irrte. D.h. er wird wie angesprochen nicht überschrieben. Ich meinte "Repl Perform Initial Synchronisations", aber das tut hier nichts zur Sache.

 

Um Auf die Frage zurück zu kommen: Nach einem auth sysvol restore möchtest Du, daß der entsprechende DC authorativ ist, d.h. die DB neu aufbaut und seine Daten an die anderen DCs übertragen werden.

Würde - direkt nach der Wiederherstellung der Daten, die Du authorativ zu den anderen DCs replizieren möchtest - der DC nicht im D4 Modus starten, würden ggf. Daten von anderen DCs zuerst "zurück" zum eigentlich authorativen DC repliziert werden.

Folgt nun das D4, hast Du nicht mehr den Status des wiederhergestellten Backups, sondern schon wieder Änderungen. Oder gar Löschungen.

 

Das nachträgliche Setzen von D4 kann Dir also den sauberen Backup Status verhageln.

 

Nachvollziehbar?

 

Viele Grüße

olc

[Daim 12]

Ahh... ok, wir sind von verschiedenen Szenarien ausgegangen. Deine Schilderung kann ich natürlich nachvollziehen und dem stimme ich auch uneingeschränkt zu und so ist das auch korrekt.

 

Mir ging es nur darum, dass man prinzipiell das D4 auf einem gesunden DC und davon bin ich "per se" ausgegangen, im laufenden Betrieb, ohne im DSRM zu starten setzen kann. Um mehr ging es mir gar nicht. :) Ich war davon ausgegangen, dass der zu wiederherstellende DC der "erste DC" in der Domäne ist und somit eben das setzen von D4 nicht im DSRM notwendig ist.

 

Ansonsten hast du ja die Antwort für das Szenario des OP bereits geliefert. ;)

 

Schön das wir das nun geklärt haben. :cool:

bearbeitet 30. März 2011 von Daim

[olc 18]

...genau. Was Du sagst, ist ebenso vollkommen korrekt. :)

 

Schönen Abend Euch, viele Grüße

olc