2KSRV Crashszenario - DC offline für Reparatur

[mcdaniels 22]

Hey!

Mal angenommen einer von 2 DC (alle Fsmo , Dns) crasht und ist im Netz somit nicht mehr erreichbar. Ein weiterer DC ist aber noch im LAN verfügbar, der zwar keine FSMO hat, jedoch den GC und DNS macht. Die User haben keine Serverprofile, jedoch liegen die Arbeitsdaten auf dem gecrashten Server. (Erreichbar über eine Freigabe).

Variante 1:

Nehmen wir an, die Reparatur dauert eine Woche da einige Teile getauscht werden müssen -> gegen Baugleiche (ich weiß das ist eher unwahrscheinlich... aber ok). Der Server wird danach wieder hochgefahren ohne etwas neu installieren zu müssen.

 

Da der Server wieder normal (mit gleichem Namen) im Netz auftaucht , ist es während der Reparaturdauer ja weniger ratsam, die Rollen auf den andren Server zu erzwingen, denn dann dürfte der reparierte Server ja nicht wieder "einfach so" ins Netz. Die Rollen zu übertragen würde auch nicht funktionieren, da der Server im oben geschilderten Szenario ja nicht im Netz ist...

 

Daraus ergibt sich nun folgende Frage: Kann ich den DC (FSMO Inhaber) einfach so, ohne weiteres, für einige Tage offline lassen, ohne Auswirkungen auf die Domäne befürchten zu müssen? Wie lange darf das maximal sein -> Tumbstone-Lifetime (60 Tage bei 2KSRV)?

 

Variante 2: Server crasht wiederum. Hardware wird gegen andre Hardware getauscht.

Folge: Server fährt nach Reparatur nicht mehr hoch, Reparaturinstallation mittels 2KSRV CD notwendig.

 

Kann der Server in dem Fall nach der Reparatur wieder ins Netz genommen werden und erledigt (im positiven Sinne) die Replikation den Rest -> Abgleich der Daten mit dem verbleibenden DC, der ja den aktuellen Stand haben sollte da er nicht offline war...?

 

Danke

[marin 10]

mcdaniels

 

Zu V1: Also die FSMO Rollen beinhalten doch auch die Clientanmeldung, ohne diese Rolle ist dann wohl nix mehr mit Anmeldung / Authentifizierung der Clients.

 

Zu V2: Kann, muss aber nicht:) Hatte dieses Szenario schon einmal, damals hat das geklappt. Naturlich danach mit DCDIAG / Netdiag / RepMon das ganze überprüfen!

 

Gruss

 

Martin

[mcdaniels 22]

Hey!

Zu V1: Ich glaube, da muß ich dir wiedersprechen, denn soweit ich weiß ist einzig der GC für die Anmeldung sehr wichtig. Sofern ich glaube zu wissen , wäre es kritisch hätte ich keinen 2ten GC.

 

Desweiteren würde das ja heißen, dass man am Erzwingen der FSMOs am noch funktionierenden DC in so nem FAll gar nicht herumkommen würde...

[marin 10]

Jo, war zu schnell mit Schreiben und zu langsam mit Denken, Sorry

 

Das hier ist nicht schlecht:

 

Seizing FSMO Roles

[Daim 12]

Servus,

 

Zu V1: Also die FSMO Rollen beinhalten doch auch die Clientanmeldung, ohne diese Rolle ist dann wohl nix mehr mit Anmeldung / Authentifizierung der Clients.

 

also das überlegst du dir bitte noch einmal.

 

@ Mcdaniels

 

Da der Server wieder normal (mit gleichem Namen) im Netz auftaucht , ist es während der Reparaturdauer ja weniger ratsam, die Rollen auf den andren Server zu erzwingen, denn dann dürfte der reparierte Server ja nicht wieder "einfach so" ins Netz. Die Rollen zu übertragen würde auch nicht funktionieren, da der Server im oben geschilderten Szenario ja nicht im Netz ist...

 

Wenn die FSMO-Rollen "mit Gewalt" verschoben werden, darf der Ursprungsträger nicht mehr online gehen und diesen müsste man neu installieren und die Daten händisch mit NTDSUTIL aus dem AD entfernen.

 

Eine AD-Domäne kann im günstigsten Fall, weiterhin x-Tage ohne Probleme weiterlaufen, ohne das die FSMO-Rollen verfügbar sind.

 

Daraus ergibt sich nun folgende Frage: Kann ich den DC (FSMO Inhaber) einfach so, ohne weiteres, für einige Tage offline lassen, ohne Auswirkungen auf die Domäne befürchten zu müssen? Wie lange darf das maximal sein -> Tumbstone-Lifetime (60 Tage bei 2KSRV)?

 

Was die Tombstone Lifetime betrifft sind es 60 Tage, dass ist korrekt.

Länger sollte ein DC nicht aus sein.

 

Allerdings sind die FSMO-Rollen wichtiger. Denn wenn z.B. ein neuer Benutzer erstellt wird, werden dazu RIDs verwendet die vom RID-Master vergeben wurden. Jeder DC fordert vom RID-Master 500 RIDs an und wenn diese (ab SP2/3) zur Hälfte verbraucht wurden, versucht der DC vom RID-Master in regelmäßigem Abstand, neue RIDs anzufordern. Sind die RIDs auf einem DC verbraucht, kann er keine Änderungen mehr vollziehen.

 

Das war nur ein Beispiel mit dem RID-Master.

 

Wenn man absehen könnte, dass der erste DC 2 Wochen down ist, dann würde ich vorher die FSMO-Rollen online auf den zweiten DC übertragen. Wenn der erste dann repariert ist, kann man die Rollen erneut zurück übertragen.

 

Variante 2: Server crasht wiederum. Hardware wird gegen andre Hardware getauscht.

Folge: Server fährt nach Reparatur nicht mehr hoch, Reparaturinstallation mittels 2KSRV CD notwendig.

 

Dieses Szenario schilderst du falsch.

Wenn die gecrashte Hardware durch neue Hardware ersetzt wird, musst du die neue Hardware installieren und als zusätzlichen DC in deine Domäne integrieren.

 

Schildere dein Szenario 2 genauer.

[mcdaniels 22]

Hi!

@Daim: Hast natürlich recht, der 2te Fall war etwas sehr simpel definiert.

 

Also nochmal. Der Server crasht (DC alle FSMO) Hardware ist nicht mehr verfügbar. Somit muß die Hardware getauscht werden. Sagen wir mal, das wäre z.B. das Mainboard samt Prozessor. Das Mainboard hätte zusätzlich noch nen andren Chipsatz bzw. SATA-Controller.

 

Die Festplatten des defekten Server mitsamt dem installierten System werden in die neue HArdware verbaut. Nach dem Start des Server bootet selbiger nicht mehr (inaccessible boot device) da er die Festplatten - wegen des Fehlenden Controllertreiber - nicht ansprechen kann.

 

1. Es wird eine Reparaturinstallation mittels 2KSRV CD durchgeführt. Der Server startet danach wieder.

2. Fehlende Treiber werden nachinstalliert.

3. SP4 wird installiert.

4. Der Server wird an das Netz angebunden und gestartet bzw. neu gestartet

5. Anmeldung über Domänenadmin

 

Danach würde ich mal checken was Replmon bzw. Dcdiag sagt. Ich gehe davon aus, dass durch die Replikation vom verbleibenden DC (der ja immer online war) der reparierte Server auf den neuesten Stand gebracht wird...

 

Was haltest du/ihr von dieser Vorgangsweise? Hab ich was übersehen?

 

LG

[Daim 12]

Was haltest du/ihr von dieser Vorgangsweise?

 

Ja, dass könnte klappen.

 

Hab ich was übersehen?

 

Du solltest eben nach so einer Aktion den DC anschließend auf Herz und Niere prüfen.

Mit DCDIAG sowie Netdiag, den DC samt der Netzwerkkonnektivität prüfen.

Checkdisk über die HDDs laufen lassen.

Die AD-Datenbank auf dem DC würde ich mit der SEMANTIC DATABASE ANALYSES prüfen.

Yusuf`s Directory - Blog - Die Active Directory-Datenbank reparieren

 

Eventlog überprüfen.

[ducke 11]

Also ich halte nicht viel von diesem Szenario :)

Ich pers. würde dann eher folgendes machen:

 

- alle Rollen auf den gesunden DC übertragen

- mit ntdsutil ein metadata cleanup machen und alle alten Einträge vom def. DC löschen

- den "neuen" Server normal installieren und ihn per dcpromo befördern :p

- replizieren und glücklich sein *g*

 

Hab ich was vergessen? Ich hoffe nicht.

Mit Reparaturinstallation ab ich pers. schlechte Erfahrungen gemacht, deshalb würde ich diesen Weg bevorzugen.

Aber wie sagt man so schön: Viele Wege führen nach Rom :)

[mcdaniels 22]

Hey!

Ja, das ist mit Sicherheit die sicherste und sauberste Variante. Da es sich hierbei um einen Fileserver handelt, mußte ich dann halt nach der Neuinstallation und dem Dcpromo die Daten zurückspielen.

 

Verglichen mit den eventuell auftretenden Problemen bei ner Reparaturinstallation (wenn die Hardware getauscht werden würde) ist das sicher ein Klacks, weil ja dann die Folgeprobleme auch nicht abschätzbar sind.

 

Werd mal in ner Vm nachstellen , was passiert wenn der DC und Rolleninhaber offline ist.

 

LG