Da Mitte Januar 2020 der Support für Windows Server 2008 R2 abläuft und hier noch drei derartige Domänen Controller (DC) umeinanderschafften, musste dieser Umstand rechtzeitig behoben werden. Einer der DCs war zudem aus historischen Gründen zusätzlichnoch ein Fileserver. (Fragt nicht!)
Das war die Gelegenheit auch dieses gruselige Konstrukt loszuwerden.
Die anfänglichen Überlegungen gingen in die Richtung „das haben wir gleich. Bisschen Server installieren, bisschen Domänen Controller hinzufügen, bisschen DC wegnehmen, fertig“.
Nach ein wenig Nachdenken mit der Erkenntnis, dass „dieses und jenes ja auch noch notwendig ist“, haben wir uns für eine Checkliste entschieden.
Für jeden, bei dem diese Problematik auch Mal ins Haus steht, sollen unsere Ansätze als roter Faden dienen, da sich die Umgebung ja unterscheiden.
Trotz Checkliste hat uns das eine oder andere Problemchen „überrascht“.
Hinweis: den Vorgang sollte man mit Ruhe und Geduld angehen („Ungeduld der Weg zur dunklen Seite der Macht ist!“). Man fährt am besten, wenn man, besonders in größeren Umgebungen, den Domain Controllern ausreichend Zeit für die Replikation(en) lässt. Bei den – für uns – kritischen Vorgängen, haben wir 1-2 h gewartet, bzw. über Nacht, falls wir mit einem Schritt erst am späteren Nachmittag fertig waren. Die Angelegenheit ist somit nur was für die Mittagspause oder den Freitag Nachmittag, wenn man ein „harter Kerl“ ist. dbg
Bitte lasst Euch wirklich Zeit dafür!
Verbesserungsvorschläge für das nächste Mal dürfen gern über die Kommentar-Sektion gemacht werden.
Vorarbeiten und erste Checks für DC#1
DC#1
- direkte Upgradepfade zum neuen OS prüfen
- Login-Skripte aufräumen
- Diskussion, ob Laufwerke zukünftig per Gruppenrichtlinie (GPO) eingebunden werden sollen
- Falls „Ja“: eine GPO „Warten auf das Netzwerk“ erstellen. und
- eine Gruppenrichtlinie, welche die Laufwerke einbindet.
Wir sind noch unentschieden für 2019, aber alle Clients warten jetzt schon mal brav auf das Netzwerk. - eine neue virtuelle Maschine (VM) als DC#4 mit einem aktuelleren Betriebssystem (OS) installieren und auf den gegenwärtigen Patch-Stand bringen.
- dem DC#4 eine feste IP-Adresse geben.
- DC#4 in die Domäne aufnehmen.
- Server DC#4 ins Backup aufnehmen.
- DHCP- und ADDS-Rolle auf DC#4 installieren.
- Replikation mit dem AD Replication Status Tool prüfen.
- DNS auf Fehler prüfen.
- Skript-Verzeichnis auf DC#1 prüfen und noch relevante Skripte auf DC#4 kopieren.
- Aufgabenplanung auf DC#1 prüfen und festlegen, welche Aufgaben auf dem neuen DC#4 noch gebraucht werden.
- Geplante Aufgaben auf DC#4 anlegen und deaktivieren.
- Per dcdiag prüfen, ob auch da alles okilidokili ist. Treten hier Fehler auf, sollte man diese alle beheben.
Der erste neue DC
- AD-Schema auf dem DC mit der FSMO-Rolle Schema-Master erweitern (siehe auch faq-o-matic). Grundsätzlich wird seit W2K12 die Schema-Erweiterung ohne Rückfrage in dem Moment durchgeführt, in dem man den Server zum Domänen Controller hochstuft und der Benutzer die entsprechende Rechte als Schema-Administrator besitzt! Wer das also lieber separat durchführen möchte, muss also die adprep.exe auf Kommandozeilen-Ebene bemühen. Zusatzlink 1 und 2
- DC#4 zum DC hochstufen (Assistent im Server-Manager). Die DNS-Option bei der Installation nicht vergessen.
- Wiederherstellungspasswort von DC#4 in den Passwort-Safe übertragen.
- Replikation und Synchronisation abwarten. Auch die DNS-Replikation abwarten.
- DC#4 als Katalogserver umstellen (Der notwendige Haken ist automatisch beim Hochstufen zum DC gesetzt.)
- FSMO-Rollen auf DC#4 übertragen: Der faule Admin nimmt PowerShell:
Move-ADDirectoryServerOperationMasterRole -Identity "DC#4" -OperationMasterRole SchemaMaster,RIDMaster,InfrastructureMaster,DomainNamingMaster,PDCEmulator - DNS prüfen.
- DHCP-Rolle auf DC#4 authorisieren und aktivieren.
- DHCP-Backup auf DC#1 durchführen und den Dienst beenden.
- DHCP-Restore auf DC#4 durchführen und den Dienst starten.
- DHCP in der VLAN-Konfiguration der Firewall ändern.
- Bei der DHCP-Serveroption 006 den neuen DNS-Server hinzufügen.
- Login-Skripte auf den neuen DC#4 anpassen.
- Geplante Aufgaben auf DC#1 deaktivieren und DC#4 aktivieren
- Alle WLAN-Telefone auf den neuen DC#4 umstellen
- Alle VMware-Server (esxi sowie die Applicance) prüfen, ob DC#1 noch irgendwo eingetragen ist
Erste Nacharbeiten
- Netzwerkkarte von DC#1 für eine Woche deaktivieren. Damit stellt man sicher, dass man nichts vergessen hat, aber den Server binnen Sekunden wieder verfügbar hat.Daraus resultierende Lektionen:
Lektion 1: unsere Drucker haben einen LDAP- und Zeit-Server eingetragen. Die Geräte prüft man am Besten noch VOR der Deaktivierung der Netzwerkkarte. Und nicht erst, wie laut Plan, am Ende der Umstellung. Sonst haben u.a. die Scan-Ziele ein Problem mit unterschiedlichen Zeiten (Stichwort: Kerberos-Ticket-Abweichung) oder das Adressbuch kann nicht durchsucht werden.
Lektion 2: Bei gewisser Backup-Software kann man den hinterlegten DNS-Server nicht ohne den Support umstellen (mein 2 cts: „gute Qualitätssoftware“ für teueres Geld). Da dieser in den USA an der Westküste beheimatet ist, dauerte die Kommunikation seeeeehr lange. Ich glaube, die auswärtigen Supporter haben eine Woche daran rumgefrickelt, bis die neuen DNS-Server-Einträge auch den Neustart überstanden haben.
Lektion 3: Prüfe VORAB auch den Storage, ob da dieser Server als Kommunikationspartner eingetragen ist.
Lektion 4: Erwarte das Unerwartete.
Weiter zu Teil 2.