Jump to content

Empfohlene Beiträge

Hallo Miteinander

 

zunächst noch ein gesundes neues Jahr an alle.

 

Grund meines Themas ist das ich mich momentan mit der Thematik Disaster Recovery im AD Umfeld beschäftige.
Ich habe jetzt schon einiges gelesen was das Thema Rücksicherung eines DCs angeht , vorallem das was man nicht machen soll oder nur mit vorsicht

wegen USN (Snapshot usw...).

 

Wir setzen bei uns im AD zwei Dcs mit WinServer2016 ein und diverser Memberserver Exchange, CAD usw... das ganze wird per VMware 6.7 Virtualisiert,
die Sicherung fahren wir mit Veeam.

 

Jetzt habe ich in unserer Firma ein zweites Vcenter aufgesetzt um dort einige Fälle im Falle des Falles aus zu probieren.

 

Hier habe ich einen der beiden DCs aus einer Sicherung (eig. eher Veeam Replication) in diese geschottete Umgebung rückgesichert, jedoch stellt dieser DC ca. 5 min
nach dem einschalten die AD dienste ein. Der Hintergrund ist das wohl VMware die Invocation ID mit dem Anschalten ändert und somit der
DC weis das er aus einer Sicherung gestartet wurde und auf seine anderen "Kollegen" wartet das Sie ihm die aktuellen AD Daten replizieren

(ich habe auch mit repadmin den Clone und das original verglichen, die Invocation ID ist anders).

 

Jetzt gibt es ja nur den einen, weil wenn ich den anderen auch Rücksichere denkt der ja auch so.

 

Im Eventlog steht auch in etwa das er kein AD von einem andern DC replizieren konnte.

Gibt es hier einen Reg Key das man sagen kann er ist der DC wo die aktuelle Version des AD hält und seinen Betrieb wieder aufnimmt?

 

Ebenso einmal die Frage, ich habe gelesen das wenn man ein USN verursacht dieser DC herabgestuft werden soll, läuft dann das AD wieder
ganz normal weiter? Auch stand irgendwo das bei einem AD mit z.b 3 DCs und einer davon Rückgesichert wurde die anderen zwei ihre Dienste
einstellen können, reicht es dann hier auch nur den Rückgesicherten herab zu stufen so das die beiden anderen wieder laufen?

 

Ich frage deshalb um einfach das ganze besser verstehen zu können .

 

Mfg

Marcel

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hi,

 

Veeam schlägt das folgendermaßen vor: https://www.veeam.com/kb2119 (Punkt: Restoring entire AD infrastructure (AKA “all DC’s are lost”))

Zitat

As mentioned above, the automatic recovery process performs a non-authoritative restore, where the DC reboots and starts looking for other DC’s to sync up. However, in a scenario where all DC’s are gone, there are no other partners available and replication may take quite long (15-30 minutes) to start. To avoid wasting the time attempting to contact replication partners, it is recommended to restore two of the domain controllers at once, power them on, wait for their reboot and force one of them to become authoritative for SYSVOL, so that they can start replicating. Then restoring other DC’s will be similar to the first scenario, i.e. will be 100% automatic.

 

Generell würde ich einen DC nie zurücksichern, solange es noch mindestens einen funktionierenden DC gibt. Da würde ich den zu restorenden DC wegschmeißen, aufräumen, und neu aufsetzen.

 

Gruß

Jan

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Insgesamt würde ich eher davon abraten mit der Kopie einer Liveumgebung irgendwelche Tests durchzuführen. :) Aber das glauben die meisten auch erst, nachdem sie auf die Nase gefallen sind.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 17 Minuten schrieb NorbertFe:

Insgesamt würde ich eher davon abraten mit der Kopie einer Liveumgebung irgendwelche Tests durchzuführen. :) Aber das glauben die meisten auch erst, nachdem sie auf die Nase gefallen sind.

Bei einem AD DR Test bleibt allerdings nicht viel an Alternativen über. ;)

Bei Veeam könnte man da evtl. noch auf SureBackup oder Virtual Lab zurückgreifen.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Mir sind die Thematiken mit der Testumgebung bewusst, es ist nun mal aufwändig alles neu nach zu bauen um es dann ggf. wieder zu löschen.

 

Man tut sich aber auch leichter mit dem ganzen Thema wenn man es einmal durchgesielt hat und die vor u. Nachteile weis.

 

 

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 51 Minuten schrieb testperson:

Bei einem AD DR Test bleibt allerdings nicht viel an Alternativen über. ;)

Wenns das sein sollte, dann nicht. Aber es klingt halt nicht danach (oder nicht nur).

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Moin,

 

viele "DR-Tests" werden allzu naiv durchgeführt. Da "isoliert" jemand irgendwas und stellt dann irgendwas mit irgendeiner Methode wieder her. Aus so einem Vorgehen kann man keine nützlichen Rückschlüsse ziehen. Mindestens ein grundlegender Plan muss schon sein, damit man auch weiß, was man tut. Bei komplexen Applikationen wie dem AD ist zudem eine ausreichende Kenntnis der technischen Zusammenhänge nötig.

 

Im konkreten Szenario wäre jetzt wichtig zu wissen, was denn dies hier überhaupt heißen soll:

Zitat

jedoch stellt dieser DC ca. 5 min nach dem einschalten die AD dienste ein.

Was genau wurde durchgeführt? Was genau ist geschehen?

 

Gruß, Nils

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Guten Morgen Miteinander,

 

also ich habe gestern Abend das ganze mal aufgezeichnet was genau passiert, im Anhang die Fotos.

 

Der DC  (DC1)wird rückgesichert (die Liveumgebung hat 2 Dcs einer davon hat alle FSMO Rollen diesen nenne ich mal DC1), sobald dieser hochgefahren ist  kann man sich normal anmwlden

und es scheint so als wäre alles OK das AD funktioniert und die Replikation des Sysvol auch. Wenn man jetzt aber ca. 3 Min wartet und nochmal in der cmd net Share aufruft ist das Sysvol und

netlogon verschwunden, auch der Aufruf dsa.msc meldet einen Fehler (es konnte aufgrund des folgenden Problems keine Namensinformation gefunden werden , die angegebene Domäne ist nicht vorhanden...).

 

Im Eventlog steht 2092 Server ist Besitzer der FSMO Rollen die jedoch nicht als Gültig eingestuft wird, Für die PÜartition wurde der Server seit dem letzten neustart nicht repliziert....

 

Im Eventlog steht 1202 Der DFS Replikationsdienst konnte keine Verbindung mit dem Domänencontroller "" zum zugrif auf die Konfigurationspartition herstellen.

 

Was ich nicht ganz verstehe sind die Sysvol Replikation und die des AD zwei paar Schuhe oder nicht, weil wenn man diese Bur Flag setzt läuft ca. 4 min später wieder alles.

Das Bur Flag 0xd4 sagt doch aber nur was über das Sysvol aus das der DC hier der Authorative ist und sein Sysvol Verzeichnis "das sagen hat", oder nicht?

 

Auch habe ich mal KEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState geprüft ob DFSR oder FRS zum Einsatz kommt,

das steht bei uns 0 im Key, das wäre dann das ältere FRS ?

 

Im Voraus schonmal Recht vielen Dank der Hilfe

 

P.s bei den Bildern ist Foto 1 direkt nach dem start und 2-4 ca. 3 Min später

 

Grüße Marcel

 

 

 

 

 

Foto1.jpg

Foto2.jpg

Foto3.jpg

Foto4.png

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Moin,

 

sorry, aber da müsse man jetzt tiefer reingehen, als es in einem Forum sinnvoll bzw. möglich ist. Ich  selbst würde da jetzt  auch nicht groß in die Fehlersuche einsteigen, sondern den DR-Test von Grund auf sorgfältig neu entwerfen.

 

Gruß, Nils

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

@igwadmin Das Verhalten wird eigentlich alles im oben verlinkten Veeam KB Artikel zumindest angeschnitten. Bzw. findest du da die entsprechenden Stichpunkte mit denen du dich dann auseinandersetzen solltest. Des Weiteren empfiehlt Veeam für den Fall "Restoring entire AD infrastructure (AKA “all DC’s are lost”)" 2 DCs zu restoren. Ansonsten sollte es aber auch funktionieren, wenn du einen DC zurücksicherst und die weiteren Schritte durchgehst.

 

In deinem Fall könnte z.B. noch

Zitat

Note: During the restore procedure, make sure the restored DC’s DNS records point to available DNS servers (e.g. to itself).

problematisch sein.

 

Ansonsten wäre ich aber auch bei Nils' Ratschlag.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hi,

 

Also ich bin es durchgegangen, aber wenn nur ein DC (aus einer Rücksicherung) Online ist funktioniert es nicht, der startet die FSMO Rollen oder Dienste nicht.

 

vor 20 Stunden schrieb testperson:

  Ansonsten sollte es aber auch funktionieren, wenn du einen DC zurücksicherst und die weiteren Schritte durchgehst.

 

 

Ich habe aber folgendes gefunden, das ist wohl by Design von Microsoft so

 

Initial Synchronization of FSMO Owners

When a DC that owns a FSMO role boots up, it must complete inbound replication with its known replication partners before it will operate as the FSMO master. Specifically, it must replicate the partition that contains the FSMO role the DC owns. For example, if a DC holds either or both of the forest wide operations masters (the Domain Naming or Schema master), then that DC must successfully replicate the Configuration partition of Active Directory. Similarly, if the DC holds one or more of the domain specific FSMO roles (RID, PDC, Infrastructure) then that DC must successfully replicate the domain partition at startup before it will function as that operations master. See: http://support.microsoft.com/kb/305476

 

 

Was ich dann aber nicht versteht, wenn man mal beide Dcs runterfahren würde (Wartung Hardware wie auch immer) dann würde der FSMO DC nie On gehen wenn 

der zweite nicht Online ist? Oder Trift das nur zu wenn sich die Invocation ID geändert hat?

 

Weis noch einer ne Antwort auf die Frage mit dem DFSR oder FRS Replikationsdienst wie haben 2 x DC2016 und 2012 Funktionsebene Gesammt und Domäne?

 

Grüße

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Moin,

 

gut, aber die FSMO-Rollen sind für den Grundbetrieb des AD ja auch nicht notwendig. Die eigentlichen AD-Dienste müssten dann nach etwas "Einschwingen" laufen. Tun sie das nicht, dann ist noch was anderes im Busch. Daher ja mein Hinweis, dass man so einen Test ordentlich planen und systematisch ausführen sollte, um verschiedene Effekte voneinander unterscheiden zu können.

 

Gruß, Nils

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden

Werbepartner:


×