Vorgehensweise DC Migration - ich habe bereits zufällig den neuen DC bereits promotet!

[kaineanung 14]

Hallo Leute,

 

ich hatte ja vor unsere Domäne aus dem Steinzeitalter (W2K3) in die Neuzeit (W2K16) zu bringen.

Dafür entwickle ich schon recht lange eine Strategie und mache mir ToDo-Listen und Wikieinträge mit Vorgehensweisen, Befehlen und der Gleichen.

 

Ein Punkt davon war: Domäne sichern um im Falle einer mißlungenen Migration zurückspringen zu können. Das war auch recht einfach da wir nur 1x DC (ohne DNS) haben und 2x separate DNS-Server im Netzwerk betreiben.

Das sind sozusagen die 'neuralgische Punkte' und wenn man die gesichert hat, kann ja eigentlich nichts schief gehen weil man ja jederzeit zurückspringen kann. Richtig?

Mein Plan war: das Netzwerk wird heruntergefahren, alle Clients abgeschaltet (was an den Wochenenden sowieso der Fall ist) und dann kann ich von dem einzigen DC ein Image erstellen (Nur von der C-Platte da auf der D-Platte Daten des Fileservers liegen (DC ist auch Fileserver den ich in diesem Zuge dann auch trenne)) und die DNS-Server per Snapshot (sind beide auf unterschiedlichen VMWare-Servern -> Snapshot ist die einfachste Lösung) sichern.

 

Ich habe eine Testumgebung in einem eigenen (VMWare-) Testnetz erstellt und dort geübt (Mit W2K16 Evaluation-Installation die ich alle 2 Wochen erneuern muss und von Installation zu Installation migriert habe). Am Montag früh ist mir was blödes passiert: ich habe den falschen Netzadapter angegeben (also nicht den des virtuellen Netzwerkes sondern des echten physikalischen Netzwerkes) und da ich in dem virtuellen Netz die Domäne 1:1 abgebildet habe, habe ich erst spät bemerkt daß ich jetzt einen 2. DC in der Produktivumgebung erstellt habe (Rollen wurden aber noch nicht übertragen).

Ist ja nicht schlimm, ABER: wie sieht die Sicherung der Domäne nun aus? Ich habe ein 'neuralgischen Punkt' mehr. Kann ich das jetzt noch überhaupt sichern um wieder zurückspringen zu können?

Ich will kein demote durchführen, ja nicht einmal die FSMO-Rollen übertragen oder gar von FRS nach DFSR konvertieren bevor ich nicht sichergestellt habe das ich 'safe' bin und im Worts-Case-Szenario wieder am gleichen WE vor dem Montag wieder zurückspringen kann.

 

 

Meine angedachte Vorgehensweise:

1. Alle Clients herunterfahren (Am Wochenende ist das der Normalfall) und alle zwei DCs herunterfahren (1x W2K3 und 1x W2K16).

1. DC (W2K3 mit Acronis oder CloneZilla ein Image erstellen von der C-Platte wo auch das FSR / SYSVOL ist.)

2. Snapshots von neuem DCs (W2K16) erstellen

3. Snapshots von beiden DNS-Servern erstellen (ebenfalls VMWare)

4. Alle DCs wieder starten und dann FSMO-Rollen übertragen, 1. DC (W2K3) demoten, Gesamtstruktur und Domänenstruktur anheben auf W2K16, FRS nach DFSR konvertieren, GPOs einspielen und alles testen.

5. Aufräumen (Snapshots entfernen)

 

 

 

P.S.

wir wollen es gleich richtig machen und haben eigentlich 2x neue DC (W2K16) nur das der 2. eben noch nicht in der Produktivumgebung promotet wurde. Meint ihr das es auch nichts mehr ausmacht den jetzt vorab zu promoten und die Sicherung wie oben beschrieben zu machen nur daß eben dieser DC dann noch zusätzlich auch gesichert werden muss? Beide neuen DC laufen auf VMWare (physikalisch und verwaltungstechnisch komplett getrennt) und können mit einem Snapshot leicht gesichert werden.

 

[daabm 1.348]

Ein 2., DC ist völlig belanglos. Den kannst im Notfall einfach ausschalten und per Metadata Cleanup aus der Domäne entfernen. Aber diesen Snapshot-Aufwand - Du könntest jetzt auch einfach weitermachen.

 

Für die Wiederherstellung einer Domäne reicht ein einziger (!) gesicherter Domain Controller, völlig egal welcher das war. "Einfach zurück" kannst übrigens nicht - Du wirst immer Probleme mit zwischenzeitlich geänderten Computerkennwörtern haben. Und 2003 weiß noch nix von Snapshots - wenn Du also mehr als einen zurückholst, ist ein USN Rollback recht gut möglich.

 

Und Snapshots von DNS-Servern? Da exportiert man bestenfalls die statischen Host- und CName-Einträge, der Rest ist doch auch stateless.

 

ym2c

[kaineanung 14]

vor 12 Stunden schrieb daabm:

Ein 2., DC ist völlig belanglos. Den kannst im Notfall einfach ausschalten und per Metadata Cleanup aus der Domäne entfernen. Aber diesen Snapshot-Aufwand - Du könntest jetzt auch einfach weitermachen.

 

Für die Wiederherstellung einer Domäne reicht ein einziger (!) gesicherter Domain Controller, völlig egal welcher das war. "Einfach zurück" kannst übrigens nicht - Du wirst immer Probleme mit zwischenzeitlich geänderten Computerkennwörtern haben. Und 2003 weiß noch nix von Snapshots - wenn Du also mehr als einen zurückholst, ist ein USN Rollback recht gut möglich.

 

Und Snapshots von DNS-Servern? Da exportiert man bestenfalls die statischen Host- und CName-Einträge, der Rest ist doch auch stateless.

 

ym2c

Metadata Cleanup habe ich noch nie gemacht und daher suche ich einfache Lösungen. VMWare-Snapshot ist ein Klick und ab da kann ich zu diesem Zeitpunkt zurückspringen und jedes einzelne Bit so wiederherstellen wie es zu diesem Zeitpunkt war. Daher ist das ganz praktisch um wirklich 100% alle Rückgängig zu machen.

Voraussetzung ist aber: ich halte mein ganzes Netzwerk bzw. die Domäne an. Ich fahre sicherheitshalber die DCs herunter. Da ist dann auch nichts mehr mit 'zwischenzeitlich geänderten Computerkennwörtern'. Denn die Migration MUSS an diesem einen Wochenende über die Bühne gebracht werden und da sind keine anderen Nutzer zu Gange ausser wir Administratoren und da sollte es zwischenzeitlich keinerlei Änderungen an der AD geben. Keine User ändern Passwörter und der Gleichen.

 

Und was die DNS-Server angeht: klar kann ich die DNS-Zonendateien manuell wegkopieren / sichern. Das werde ich Sicherheitshalber auch machen für alle Fälle. Ein Bind-Server ist schenll aufgesetzt und die Konfigurationsdateien sind bereits gesichert. ABER: was spricht gegen einen einfachen Klick auf 'Snapshot erstellen'? Ist doch einfacher... danach 'Snapshot löschen' und gut ist und im Worst-Case 'Snaptsho wierderherstellen'.

Wichtig ist nur die Synchronität -> entweder alle DCs und DNS-Server oder keiner wird wiederhergestellt.

 

b***d ist nur: der DC auf W2K3 läuft nativ und da muss ich mir halt anders helfen: Statt Snapshot eben ein Image fahren.

 

Die Frage ist nur: übersehe ich da etwas? Könnte das klappen oder kann es vielleicht sogar gar nicht klappen?

 

Was ist eigentlich ein 'USN Rollback'?

Und welche Computerkennwörter meinst du mit den 'zwischenzeitlichen geänderten Computerkennwörter'? Du meinst Userkennwörtern, oder?

Wenn keine User da sind dann ist diesbezüglich keine Grund zur Sorge da, oder? Wenn du Computerkennwörter meinst (was auch immer das dann sein soll): wer ändert die, warum und wo? Ist doch bestimmt Benutzerkennwörter welche du meinst, richtig? Da informieren wir alle Homeoffice-USer, alle Aussendienstler und eben alle das an dem WE keiner Arbeiten soll und sich nicht einwählen soll. Dann fahren wir die Kisten runter und stellen so sicher das keiner angemeldet ist. Dann ist nichts mehr mit ändern... und wenn doch und wir müssen im WorstCase zurückspringen -> dann ändert der User es später eben noch einmal wenn uns einer durch die Lappen gegangen ist...

[NorbertFe 2.027]

vor 3 Stunden schrieb kaineanung:

jedes einzelne Bit so wiederherstellen wie es zu diesem Zeitpunkt war. Daher ist das ganz praktisch um wirklich 100%

Probleme bei einer multimaster Datenbank wie dem ad zu verursachen.

vor 3 Stunden schrieb kaineanung:

Du meinst Userkennwörtern, oder?

Dann hätte er wohl kaum von Computern geschrieben.

[daabm 1.348]

Zu USN Rollback findest ganz viele Fallbeschreibungen im Internet. Sogar hier im Forum - der erste Satz sagt schon alles:

 

[kaineanung 14]

Hallo Leute,

 

gutes neues Jahr wünsche ich euch erst einmal.

 

Ich möchte meine DC-Migration an einem der folgenden WE angehen.

Ich bin mir mittlerweile sicher daß wenn alle DCs heruntergefahren sind es keine Probleme mit USN-Rollback oder der Gleichen geben kann wenn ich den alten Server (der mit allen FSMO-Rollen) mit einem offline-Tool wie Acronis oder Ghost sichere (imagen). Da kann es ja keine Datenabweichungen in der Datenbank geben da kein DC online ist. Daher mache ich das am WE wenn das ganze Netzwerk nicht benutzt wird und die DCs heruntergefahren werden können (ich habe seit neustem einen neuen DC und eben den alten als Rolleninhaber -> der neue wird nur heruntergefahren, der alte heruntergefahren und gesichert).

 

Was ich mir noch Bestätigen lassen wollte ist die Reihenfolge die ich mir so vorgenommen habe:

1. 2. DC herunterfahren (neuer DC mit W2K16)

2. 1. DC herunterfahren (alter DC mit W2K3)

3. Von beiden BIND9-DNS-Server (UBUTNU) Snapshot erstellen (Master & Slave DNS Server) und sicherheitshalber die Zonendateien sichern

4. 1. DC sichern mit Acronis oder Ghost (Image erstellen auf externen Datenträger)

5. 2. DC Sichern mit Snapshot (läuft auf VMWare als vrituelle Maschine)

5. beide DCs wieder starten

6. FSMO-Rollen übertragen (NTDSUTIL -> Roles -> Connection -> Connect to Server 2.DC -> zurück zu Roles -> transfer der Rollen (Domain Naming Master (heisst bei W2K3 noch so statt nur Naming Master), Schema Master, RID Master, PDC und Infrastructure Master)

7. alten DC herunterfahren und prüfen ob Domain funktioniert (z.B. Client-PC in Domäne aufnehmen & entfernen UND/ODER neuen User anlegen und mit diesem anmelden)

8. alten DC wieder starten

9. Globalen Katalog auf dem alten DC deaktivieren

10. alten DC nun demoten (da bin ich mir nun nicht sicher ob man 'dcpromo.exe' eingeben soll (da ja noch alter W2K3-Server) oder man über 'Rolle deaktivieren' im Servermanager gehen muss?)

11. Testen ob Domäne noch funktioniert.

11.1 Domäne funktioniert: super! Ich muss dann nur noch die Domänen- und Gesamtstrukturfunktionsebene auf das höchst-mögliche heraufstufen (W2K16) und alles prima.

11.2 Nachtrag: SYSVOL-Migration bzw. FRS (File Replication Service) nach DFSR (Distributed File System Replication) migrieren

11.3 Domäne funktioniert nicht:

11.3.1 alten ehemaligen DC1 und DC2 herunterfahren

11.3.2 beide restoren (alter DC vom Image restoren, neuen DC per Snapshot wiederherstellen

11.3.3 DNS-Server restoren (ebenfalls vom Snapshot)

 

 

 

Nochmals zu euren Bedenken: Wie ich das verstanden habe können USN-Rollback-Probleme mich doch gar nicht treffen wenn ich sicherstelle das meine Domäne komplett heruntergefahren wurde und ich die Dinger ausschliesslich offline sichere und zwar ohne zwischen drinnen einen der Server wieder zu starten. Beide Server heruntergefahren haben den gleichen Stand von dem gleichen Zeitpunkt. Wenn man das jetzt sichert gibt es keine Diskrepanzen...

 

Ist meine ToDo-Liste so plausibel? Habe ich womöglich noch irgendwo was vergessen? Ich habe die Migration in meiner Testumgebung schon x-mal durchgespielt (nur das ich immer von W2K16 auf W2K16 migriert bin statt von W2K3 auf W2K16 (bis auf das erste mal vor paar Monaten)) und meine Testdomäne funktioniert nach wie vor....

Ich bin mir nur an einer stelle nicht mehr sicher ob dcprmo.exe oder über den Servermanager der W2K3-DC demotet wird.

bearbeitet 7. Januar 2020 von kaineanung

[Squire 260]

mal ne blöde Frage ... warum das ganze Gezuppe? Für die Übertragung der FSMO Rollen ist das alles absolut nicht notwendig. Das geht im laufenden Betrieb ohne dass irgendwas heruntergefahren werden muss. Haben wir schon oft in unseren Domänen gemacht. Wichtig ist einzig eine vernünftige Sicherung des Systemstates (dafür reicht Windows Backup) ...

FSMO Rollen per Powershell auf den neuen DC holen ... wenn alles durch ist - kannst Du noch mal eine Sicherheits-Kaffeetasse trinken und dann die Replikation prüfen. Wenn der 16er schon DC ist kannst Du jederzeit auch den GC dafür aktivieren ... Wenn die Eventlogs sauber sind ... mit dcpromo den alten 2k3 demoten - DNS bereinigen und fertig.

Aber Du hast recht, man kann aus allem ein halbjähriges Projekt machen ...

[NorbertFe 2.027]

vor 15 Minuten schrieb Squire:

Aber Du hast recht, man kann aus allem ein halbjähriges Projekt machen ...

Vielleicht baut er ja nen Flughafen ;)

[kaineanung 14]

vor 16 Stunden schrieb NorbertFe:

Vielleicht baut er ja nen Flughafen ;)

Haha, der war echt gut! ;)

vor 17 Stunden schrieb Squire:

Aber Du hast recht, man kann aus allem ein halbjähriges Projekt machen ... 

Ist ja nicht so das ich nur an diesem Projekt arbeite... und lernen kostet ja auch Zeit... ;)

 

vor 17 Stunden schrieb Squire:

Für die Übertragung der FSMO Rollen ist das alles absolut nicht notwendig. Das geht im laufenden Betrieb ohne dass irgendwas heruntergefahren werden muss. Haben wir schon oft in unseren Domänen gemacht. Wichtig ist einzig eine vernünftige Sicherung des Systemstates (dafür reicht Windows Backup) ...

Das die FSMO-Rollen im laufenden Betrieb übertragen werden weiß ich ja. Habe es in der Testumgebung ja breits x-mal gemacht.

ABER ich habe einfach ANGST das nicht doch irgendwas schief geht und dafür würde ich sehr sehr gerne eine Sicherung des Servers haben für den SUPER-GAU, das 'worst case scenario'.

 

Und was meinst du mit 'Systemstates'?

 

vor 17 Stunden schrieb Squire:

Wenn der 16er schon DC ist kannst Du jederzeit auch den GC dafür aktivieren

Was ist 'GC'?

[Squire 260]

wenn das Übertragen einer der Rollen schief geht bleibt die einfach auf dem alten DC - nix passiert - Fehler beheben und noch mal verschieben

GC = Global Catalog

 

Thema Angst - deshalb Sicherung mit Systemstate (mit einem Backupprogramm Deiner Wahl oder mit Windows backup)

[Sunny61 806]

vor 59 Minuten schrieb kaineanung:

Und was meinst du mit 'Systemstates'?

Systemstatus zu Deutsch: https://docs.microsoft.com/de-de/system-center/dpm/back-up-system-state-and-bare-metal?view=sc-dpm-2019

vor 59 Minuten schrieb kaineanung:

Was ist 'GC'?

Global Catalog. https://docs.microsoft.com/de-de/previous-versions/windows/desktop/legacy/ms681905(v=vs.85)

[kaineanung 14]

Hallo Leute,

 

wir haben die Migration am WE durchgezogen. Gott sei Dank hat alles gut geklappt. An der Stelle des Demoten des alten DC-Servers habe ich an einer Stelle geschwind geschwitzt da ich, anders als bei meinen unzähligen Testläufen, die Zugangsdaten eingeben musste weil der alte Server die neue Domäne nicht gefunden hat und der Gleichen.

Aber danach hat alles wunderbar geklappt.

Naja, fast alles.

Da wir übergangsweise noch auf eine 'LOGON.BAT' setzen (GPO ist bereits erstellt. Muss diese nur noch einbinden und dann testen und Abteilungsweise umsteigen), bekomme ich bei einigen PCs nach der Anmeldung keine Netzlaufwerke (die diese LOGON.BAT u.a. erstellt) und andere Dinge. Sprich: die LOGON.BAT wird nicht immer ausgeführt. Meist löst sich das Problem auf indem man sich einmal neu anmeldet (ab- und anmeldet, NICHT Neustartet). Ich vermute das die Anmeldung zu schnell nach dem Start ausgeführt wird so die Netzwerkschnittstelle noch nicht initialisiert wurde.

Aber ok, das ist ein Problem das sich bald sowieso mit dem Umstieg auf GPO erledigt haben müsste.

 

Was mich mehr wurmt ist folgendes:

In den 'AD-Standorte und Dienste' habe ich unter 'Sites->First-Site-Name->Servers' noch den alten DC aufgelistet OBWOHL ich diesen 'demotet' habe und obwohl ich davor darauf geachtet habe den Globalten Katalog zu entfernen! (Das war eigentlich der Grund warum ich in meiner Vorgehensweise vor dem Demoten den Globalen Katalog entferne da ich in meiner Testumgebung dies damit geschafft habe den alten DC aus dieser Liste weg zu bekommen!).

In meinem DNS-Server (übrigens: nach wie vor Bind auf Linux und scheint alles sauber vonstatten gegangen zu sein) ist der alte DC wie gewünscht automatisch verschwunden. Also hat das mit dem GC entfernen ja auch gut geklappt.

Die Frage ist: Wieso zum Teufel ist der Server hier noch gelistet ('Active Directory - Standorte und Dienste'->'Sites'->'Default-First-Site-Name'->'Servers')??

Und die noch wichtigere Frage: wie bekomme ich ihn von hier sauber wieder weg? Nur löschen wäre sicherlich nicht sauber, oder?

[Squire 260]

doch genau so

 

zu deinen Clients ... ich wette mal, die haben SSDs verbaut. Die fahren schlicht zu schnell hoch, das Netzwerk ist noch nicht so weit. Du kannst per GPO setzen, dass die Kisten erst aufs Netzwerk warten sollen

[testperson 1.674]

Evtl. auch: https://docs.microsoft.com/en-us/archive/blogs/leesteve/demystifying-the-unc-hardening-dilemma

[kaineanung 14]

vor einer Stunde schrieb Squire:

doch genau so

Also an dieserStelle einfach markeiren und löschen? Und das war es? Es bleiben nirgends irgendwelcher Müll zurück oder der Gleichen?

 

vor einer Stunde schrieb Squire:

u deinen Clients ... ich wette mal, die haben SSDs verbaut. Die fahren schlicht zu schnell hoch, das Netzwerk ist noch nicht so weit. Du kannst per GPO setzen, dass die Kisten erst aufs Netzwerk warten sollen

Die meisten bei denen es nicht funktioniert haben in der Tat schnelle Festplatten...

Ich werde wohl eine GPO erstellen die das Anmelden vor der Konnektivität verhindern soll aber nur bei Desktop-PCs.

Kannst du mir zufällig gleich sagen wo ich diesen Eintrag finde? Andernfalls suche ich selber geschwind danach..

Danke für den Hinweis.