Dieser Eintrag gehört zu meiner Serie „Migration zu Windows Server 2025„. In dieser möchte ich euch die Aktualisierung meiner Server-Infrastruktur von 2019 auf 2025 dokumentieren. Es ist eine lebendige Welt von Systemen, die mir wichtig sind. Mit realen Anforderungen und Bedingungen werde ich alle Arbeitsschritte erläutern.
In diesem Beitrag werde ich mein Active Directory auf Windows Server 2025 Domain Controller vorbereiten und den ersten DC mit diesem Betriebssystem installieren.
Inhaltsverzeichnis
Planung
IST-Situation
Ich verwende seit 2013 ein eigenes Active Directory. Dieses habe ich immer wieder aktualisiert. Derzeit wird es von 2 Windows Server 2019 Domain Controllern betrieben. Beide laufen als VM auf je einem Hyper-V-Host in meinem Server-Schrank.
Die Server WS-DC1 und WS-DC2 stellen neben den kassischen Active Directory Diensten natürlich auch Namensauflösung über DNS und Zeitsynchronisierung über NTP bereit. Eine Vielzahl von Richtlinien werden hier zentral gepflegt.
Der Service arbeitet fehlerfrei.
SOLL-Situation
Ich möchte die beiden alten Betriebssysteme in den Ruhestand schicken und durch das neue Windows Server 2025 ablösen. Danach würde ich mir die neuen Funktionen etwas genauer ansehen.
Migrationsszenario
Es gibt eine große Menge an Abhängigkeiten zu den beiden Servernamen und den IP-Adressen: In diversen Konfigurationen spreche ich die Domain Controller mit ihren Namen an. Und deren IPs sind in nahezu jedem Device als DNS-Serveradressen hinterlegt. Ich muss also die Namen und die IPs der Domain Controller beibehalten. Damit ist das Szenario Side-by-Side ausgeschlossen. Ich werde die DCs mit Wipe&Load migrieren.
Da ich WS-DC1 als Tier-0-Adminserver verwende und dort viele Details in meinem Benutzerprofil konfiguriert habe, werde ich zuerst den WS-DC2 umstellen.
Vorbereitung
Review des alten Server
Review vom Active Directory
Als Tier-0-Admin mit Domain Admin Berechtigung melde ich mich an meinem WS-DC2 an und starte die Analyse. Diese werde ich für den gesamten Service vornehmen.
Das sind meine beiden Domain Controller:
- WS-DC1 mit 192.168.100.1/24; Rollen: ADDS, DNS; Windows Server 2019
- WS-DC2 mit 192.168.100.2/24; Rollen: ADDS, DNS; Windows Server 2019
Mein Active Directory besteht aus der Root-Domain ws.its. Diese läuft im Domain- und ForestMode Windows Server 2016. Das ist das Maximum unter Windows Server 2019:
Meine physikalische und logische Struktur umfasst mehrere Subnetze, die alle dem Standort Ergoldsbach zugewiesen sind. Dort sind dann natürlich auch beide Domain Controller registriert:
Beide Domain Controller replizieren über eine automatische Verbindung gegenseitig:
Die Replikation arbeitet fehlerfrei. Das lässt sich mit diesem Einzeiler in der PowerShell gut kontrollieren:
repadmin /showrepl * /csv | ConvertFrom-Csv | Out-GridView
Beide Domain Controller arbeiten als Global Catalog Server:
Bei der Replikation der Gruppenrichtlinien schaut es ebenfalls gut aus. Diese kontrolliere ich mit ein paar Zeilen PowerShell: diese suchen alle Dateien unter SYSVOL und NETLOGON auf jedem Domain Controller und bestimmen davon je einen FileHash. Alle Ergebnisse werden in einer Variable gesammelt. Abschließend wird nach den Hashes gruppiert und es werden alle Ergebnisse ausgegeben, bei denen es weniger oder mehr Treffer als Domain Controller gibt:
$Files = @()
$DCs = Get-ADDomainController -Filter "*"
$DCs | ForEach-Object {
$CurDC = $_
$Files += Get-ChildItem -Path "\\$( $CurDC.Hostname )\SYSVOL\$( $CurDC.Domain )\Policies" -File -Recurse |
Select-Object -Property `
"Fullname",
"LastWriteTime",
@{ n="Hash" ; e={ ($_.Fullname -split '\\Policies\\')[1] + (Get-FileHash -Path $_.fullname).hash }},
@{ n="DomainController" ; e={ $CurDC.Hostname }}
$Files += Get-ChildItem -Path "\\$( $CurDC.Hostname )\NETLOGON\" -File -Recurse |
Select-Object -Property `
"Fullname",
"LastWriteTime",
@{ n="Hash" ; e={ ($_.Fullname -split '\\NETLOGON\\')[1] + (Get-FileHash -Path $_.fullname).hash }},
@{ n="DomainController" ; e={ $CurDC.Hostname }}
}
$Files = @()
$DCs = Get-ADDomainController -Filter "*"
$DCs | ForEach-Object {
$CurDC = $_
$Files += Get-ChildItem -Path "\\$( $CurDC.Hostname )\SYSVOL\$( $CurDC.Domain )\Policies" -File -Recurse |
Select-Object -Property `
"Fullname",
"LastWriteTime",
@{ n="Hash" ; e={ ($_.Fullname -split '\\Policies\\')[1] + (Get-FileHash -Path $_.fullname).hash }},
@{ n="DomainController" ; e={ $CurDC.Hostname }}
$Files += Get-ChildItem -Path "\\$( $CurDC.Hostname )\NETLOGON\" -File -Recurse |
Select-Object -Property `
"Fullname",
"LastWriteTime",
@{ n="Hash" ; e={ ($_.Fullname -split '\\NETLOGON\\')[1] + (Get-FileHash -Path $_.fullname).hash }},
@{ n="DomainController" ; e={ $CurDC.Hostname }}
}
($Files | Group-Object -Property "Hash" | Where-Object { $_.count -ne $DCs.count }).group | Format-Table -Property "FullName","LastWriteTime","Hash"So würde es aussehen, wenn eine Datei nicht synchron wäre:
Bei mir gibt es keine Treffer. Daher ist alles synchron. 🙂
Eine Anmerkung an dieser Stelle: Robocopy kann hier nicht eingesetzt werden, da durch die DFS-R-Replication der Gruppenrichtlinien nicht alle Eigenschaften genau übereinstimmen. So ist diese Datei z.B. zu unterschiedlichen Zeiten „geändert“ worden:
Beide Server sind über LDAP und LDAPS erreichbar. Für die abgesicherte LDAP-Version werden automatisch passende Zertifikate ausgestellt:
Im Active Directory gibt es Funktionen, die nur von einem Domain Controller je Domain/Forest übernommen werden können: Die Flexible Single Master Operators – kurz FSMO. Diese werden bei mir von einem DC ausgeführt:
Kontrolle der Zeitkonfiguration
Der PDC-Emulator ist selber der primäre Zeitserver für alle anderen Domain Controller seiner Domain. Daher kontrolliere ich die Zeitkonfiguration auf dem WS-DC1. Dafür nutze ich w32tm.exe. Weil ich aber auf WS-DC2 angemeldet bin, nutze ich zusätzlich noch PowerShell-Remoting. Der Server holt sich seine Zeit bei ptbtime2.ptb.de:
Speziell bei virtuellen Domain Controllern kann es Konflikte geben, wenn die Zeit der Hypervirsor-Server an die VM durchgereicht wird – vor allem, wenn sich wie bei mir die Hypervisor-Server ihre Zeit als Domain-Member von den DCs holen. Das kann sich schnell aufschaukeln! Daher sollte bei virtuellen DCs die Zeit nicht vom Host durchgereicht werden:
Review der DNS-Server
Im DNS-Umfeld sieht auch alles fein aus. Alle Zonen sind auf allen Servern AD-integriert:
Das gilt mit Ausnahme der inaddr-arpa-Zonen auch für alle Reverse-Lookup-Zonen:
Beide Server verwenden IPv6 im Link-Local-Mode:
Für die Weiterleitung werden keine Root-Server verwendet. Stattdessen wird meine Fritzbox WS-GATE1 angesprochen. Als Fallback beim Ausfall meiner primären Internetleitung wird meine WS-PFS2 zur Namensauflösung genutzt. Dieser Router ist mit einer zweiten Internetleitung verbunden!
Veraltete DNS-Records werden von WS-DC1 nach einem Tag bereinigt (ich habe kurze Lease-Times!):
Beide Server protokollieren den DNS-Traffic in einer lokalen Datei:
Zusätzlich werden alle möglichen Events in das Eventlog geschrieben:
Die Sicherheitseigenschaften sind unverändert:
Es gibt keine bedingten Weiterleitungen:
Zwischen Den Active Directory Standorten und Diensten und DNS gibt es einen Zusammenhang. Jeder Domain Controller muss sich im DNS in den richtigen Domains registrieren. Spätestens vor einer DC-Migration muss man hier einmal durch alle relevanten Container navigieren und die Records kontrollieren. Abweichungen werden schnell erkannt. Bei mir ist alles in Ordnung:
Review der sonstigen Eigenschaften
Es sind nur die erforderlichen Rollen und Features installiert:
Das VC++ Redist-Setup kann ich mir aktuell nicht erklären. Ansonsten ist lokal nur LAPS installiert:
Beide Server haben 2 ScriptTasks in der Aufgabenplanung registriert, die ich übernehmen möchte: Der erste Task repariert einen fehlerhaften Start eines Domain Controllers. Der 2. erzeugt täglich einen verschlüsselten Dump aller LAPS-Passworte, damit ich mich bei einem Server-Rollback nicht aussperre. Das hatte ich bei meiner letzten DC-Migration hier schon einmal beschrieben: WS IT-Solutions · Blog: Migration eines DC auf Win2019. Beide Aufgaben exportiere ich in ein Migrationsverzeichnis auf meinem Fileserver:
Auf meinem WS-DC1 finde ich noch weitere ScriptTasks. Einer davon wird für eine kleine DNS-Trickserei genutzt. Dann habe ich noch einen NTLM-Monitorscript laufen. Und dieser Server ist für meine GPO-Datensicherung zuständig. Auch diese Tasks exportiere ich:
Auf der C-Partition liegen alle besonderen Dateien unter c:\admin. Da hier auch Logfiles enthalten sind, werde ich dieses Verzeichnis erst nach der Entfernung des Active Directory auf WS-DC2 in mein Migrationsverzeichnis verschieben:
Im Startmenü sind einige meiner Anwendungen integriert. Diese muss ich ebenfalls sichern:
Die Dateien dazu liegen hier:
Für mein PAM-AdminGUI-Script nutze ich Just-Enough-Administration (JEA). Hier gibt es auf jedem Domain Controller einen registrierten JEA-Endpunkt. Der erste Eintrag ist für mein PRTG-Monitoring:
Allgemeinzustand
Zum Abschluss prüfe ich noch auf problematische Eventlogs. Hier nutze ich gerne die Zusammenfassungsansicht in der Ereignisanzeige. Hier finde ich aber nur einige Einträge zum DFS-R. Diese zeigen einmal den automatischen Neustart des WS-DC1 und die Datensicherung des WS-DC1 an:
Beide Server und deren Services sind also bereit für eine Migration auf ein neues Betriebssystem.
Aufbau der neuen VM
Für meinen WS-DC2 erstelle ich mit meinem Script eine neue VM. Dabei passe ich auch gleich die Zeitsynchronisierung mit dem Host an:
$VMName = "WS-DC2"
$VMPath = "V:\Hyper-V\PROD"
Copy-Item `
-Path "W:\Base\win2025-2501.vhdx" `
-Destination "$VMPath\$VMName\Virtual Hard Disks\HDD0.vhdx"
$NewVM = New-VM `
-Name "$VMName" `
-MemoryStartupBytes 3GB `
-SwitchName "VLANs" `
-Path "$VMPath" `
-Generation 2 `
-VHDPath "$VMPath\$VMName\Virtual Hard Disks\HDD0.vhdx"
$NewVM | Set-VM `
-ProcessorCount 4 `
-MemoryMinimumBytes 2GB `
-MemoryMaximumBytes 6GB `
-DynamicMemory `
-AutomaticStartAction "Start" `
-AutomaticStartDelay 0 `
-AutomaticStopAction "ShutDown"
$NewVM |
Get-VMNetworkAdapter |
Set-VMNetworkAdapterVlan -Access -VlanId 99
$NewVM |
Get-VMIntegrationService |
Enable-VMIntegrationService
Disable-VMIntegrationService -VM $NewVM -Name "Zeitsynchronisierung"Danach starte ich die VM und beende das Ersteinrichtungssetup. Dann erhält der neue Server die IP-Konfiguration und den Namen des alten DCs – Dank der VLAN-ID 99, die ich nicht habe, können sich beide Server nicht sehen und es gibt keinen Konflikt! Der WS-DC2 soll die IP des WS-DC1 als primäre DNS-Adresse verwenden:
Trick: Minimierung der DNS-Downtime
Damit ich den neuen Server als Domain Controller mit DNS einsetzen kann, muss ich zuerst den alten deinstallieren und herunterfahren. Erst dann kann ich den neuen in das AD aufnehmen und als DC promoten. In dieser gesamten Zeit ist der DNS-Service des neuen Domain Controllers normalerweise nicht funktional. Jedes System, dass nun die IP des neuen DCs als primäre DNS-Serveradresse konfiguriert hat, wird davon gestört sein, bis der neue DC mit DNS einsatzbereit ist. Clients werden auf den 2. DNS-Server zurückgreifen, aber das passiert eben nicht sofort. Damit werden Namensauflösungen länger dauern und Timeouts bei Verbindungsaufbauten sind die Folge.
Jetzt kann man aus 4 Optionen wählen, um das Problem zu minimieren:
- Man stellt die DNS-Configuration auf vielen/allen Systemen um. Bei Clients mit DHCP-Konfiguration mag das recht schnell gehen, aber die meisten Server und Appliances werden statische DNS-Konfigurationen haben. Diese Option ist nicht gut.
- Man könnte vorher einen DNS-Loadbalancer aufbauen, der als primärer DNS-Server für alle Systeme konfiguriert wird und die Antworten selber von allen DNS-Servern erhält. Fällt dann ein DNS-Server aus, dann bekommt er die Antworten von einem anderen. Generell bin ich ein Fan von DNS-Loadbalancern und betreibe bei mir einen in der PFSense. Aber die meisten von euch werden so etwas nicht haben. Daher braucht diese Option etwas mehr Vorlaufzeit.
- Die Migration könnte auch einfach in das Wartungszeitfenster gelegt werden. Dann sollte der Impact nicht so groß sein. Aber ich arbeite gerne tagsüber.
- Daher nehme ich die 4. Option: Ich installiere die Rolle DNS-Server vorab auf dem neuen DC und konfiguriere sie als DNS-Forwarder. Fragt ein Client ab dem Servertausch den neuen DC (der dann noch keiner ist) nach einem DNS-Namen, dann kann dieser die Antwort vom anderen DC holen.
In diesem Bild kann man beide Szenarien sehen. Links der Standard mit dem möglichen Timeout bei DNS-Anfragen und rechts die Variante mit dem DNS-Forwarder:
In meiner neuen VM schaut das nach der Installation der DNS-Serverrolle so aus. Die Fehlermeldung bei der Prüfung kann ignoriert werden, denn der andere DNS-Server ist ja wegen der Netzwerkisolation nicht erreichbar:
Die Wirkung dieses Tricks sehen wir uns nach dem Serveraustausch an.
AD-Vorbereitung
Auch diesen Schritt sollte man vorab durchführen: Das Active Directory muss auf den Betrieb mit Windows Server 2025 als Domain Controller vorbereitet werden. Dafür sind 2 Aktualisierungen erforderlich: Die Vorbereitung der Gesamtstruktur und die Vorbereitung der Domain(s). Beides wird über die cmd auf einem der alten DC ausgeführt. Dazu muss das ISO mit Windows Server 2025 gemoutet sein. Und der Account muss Mitglied in den Gruppen „Enterprise Admins“ und „Schema Admins“ sein:
So ausgestattet melde ich mich auf meinem WS-DC2 an. Dort starte ich eine administrative cmd und darin dann die beiden Aktualisierungsaufrufe. Die erste Aktion dauert nur wenige Sekunden:
Die zweite Aktion muss für alle Domains ausgeführt werden, die Windows Server 2025 als DCs erhalten sollen:
Danach sollte die gesamtstrukturweite AD-Replikation abgewartet und kontrolliert werden. Nutzt dazu diesen Einzeiler in der administrativen PowerShell:
repadmin /showrepl * /csv | convertfrom-csv -Delimiter ',' | Out-GridViewBitte nicht verzweifeln, wenn kurz nach der Aktualisierung des AD-Schema die Replikation hängt. Das legt sich nach einigen Minuten:
Das Ergebnis zeigt mir auch mein eigener Sensor im PRTG an:
Bei mir ist nach der nächsten AD-Replikation wieder alles normal:
Vorbereitung der Domain Controller GPO
Ähnlich, wie ich es hier für die Memberserver gezeigt habe, brauchen auch Domain Controller eine spezielle Härtungsrichtlinie. Hier beziehe ich die aktuelle SCT-Baseline von Microsoft: Download Microsoft Security Compliance Toolkit 1.0 from Official Microsoft Download Center. Im Downloadauswahldialog wähle ich „Windows Server 2025 Baseline“ aus.
Aus dem heruntergeladenen ZIP-File extrahiere ich die GPO-Sicherungen. Dann erstelle ich eine neue GPO als Pendant zu meiner bisherigen SCT-Richtlinie für Windows Server 2019 Domain Controller:
Dazu wähle ich nun den WMI-Filter für Windows Server 2025 aus und starte den Import-Assistenten:
Hier navigiere ich zu dem extrahierten GPO-Verzeichnis und wähle dann die GPO für Domain Controller aus:
Diese Meldung kann ich ignorieren, denn diese Sicherheitsprinzipale werden automatisch übersetzt:
Nun mappe ich noch meine neuen Richtlinien auf der OU „Domain Controller“ und bringe sie in die richtige Reihenfolge:
Transfer der letzten Dateien und Ordner
Jetzt stehe ich kurz vor dem Austausch. Da wird es Zeit, die lokalen Scripte und Logs vom alten DC auf ein zentrales Netzlaufwerk zu kopieren:
Migration
Maintenance im PRTG aktivieren
Im PRTG setze ich den alten WS-DC2 in die Wartung. Beim anderen DC pausiere ich den Replikationssensor und den Zeitsensor:
Trick: Maintenance im Active Directory aktivieren
Diesen Trick nutze ich ebenso gerne, wie den DNS-Forwarder-Trick.
Zusätzlich aktiviere ich nun noch die DNS-Maintenance für den auszutauschenden Domain Controller. Clients suchen über DNS die DCs. Wenn die dazugehörigen Records nicht mehr im DNS stehen, dann „vergessen“ die Clients nach spätestens 10 Minuten, dass ein DC existiert. So schaut es aktuell aus. Mein Client findet im DNS beide Domain Controller, da sich beide automatisch im DNS registrieren:
Mit diesem simplen Befehl lasse ich alle speziellen DNS-Records eines Domain Controllers löschen:
Die DNS-Server brauchen bis zu 2 Minuten, um diese Veränderung zu replizieren. Man kann das auch manuell beschleunigen:
Dann dauert es noch max. 10 Minuten, bis diese Information aus den DNS-ClientCaches abläuft. Dann finden alle nur noch den anderen Domain Controller:
Entfernen des alten Domain Controllers
Nun muss die Rolle „Active Directory Domanendienste“ vom alten DC deinstalliert werden. Dabei wird das der Assistent zum „tieferstufen“ des Domain Controllers gestartet:
Das Entfernen sollte hier nicht erzwungen werden!
Dies wird das neue Passwort des lokalen Admins vom Altserver:
Das Tieferstufen dauert einen Moment:
Direkt danach folgt ein automatischer Neustart. Hier bin ich aber schon mit dem nächsten Schritt vorbereitet…
Austausch des Servers
Ich warte bereits im Hyper-V-Manager auf das Neustartevent. Für beide Server (neu und alt) habe ich die Einstellungskonsole geöffnet. Beim alten entferne ich das VLAN und beim neuen trage ich eines ein – beide Aktionen ohne „anwenden“. In dem Moment, in dem der Server neustartet (erkennbar am Betriebszeitenzähler), bestätige ich beide Konfigurationen. So wird der alte DC isoliert und der neue wird aktiv:
Mein Adminserver verwendet für die primäre Namensauflösung den WS-DC2 – der ja nun kein Domain Controller mehr ist. Aber DNS-Anfragen kann er dank dem DNS-Forwarding immer noch beantworten:
Der DNS-Ausfall ist damit auf nahezu 0 begrenzt! 😉 Und dank der AD-Maintenance vermisst auch niemand den WS-DC2 als Domain Controller.
Bereitstellung des neuen DCs
Damit der neue Server ab der ersten Minute nur die GPO der Domain Controller verarbeitet, verschiebe ich sein AD-Computerkonto wieder zurück in die Organisationseinheit der DCs. Nach dem Demoting ist er dort raus geschoben worden:
Nun nehme ich den neuen Server als AD-Mitglied auf:
Der Neustart sollte recht schnell gehen. Bei mir hat das ca. 40 Sekunden gedauert. In der Zeit sollte es noch nicht zu DNS-Problemen kommen:
Ich melde mich nun das erste mal mit meiner Tier-0-Kennung auf dem neuen Server an. Dann installiere ich die Rolle „Active Directory Domänendienste“ mit den zugehörigen Verwaltungstools:
Mit dem Post-Deployment im Server-Manager starte ich dann die Heraufstufung als Domain Controller:
Die Optionen sind die gleichen wie bei den vorherigen Windows Server Versionen. Im ersten Fenster belasse ich die getroffenen Einstellungen:
Das Wiederherstellungskennwort für die AD-Dienste (DSRM) speichere ich in meinem Passwort-Safe ab. Auch der neue DC soll Global Catalog ausführen. Damit werde ich unabhängiger von der FSMO-Rolle „Infrastructure-Master“ und meine Exchange Server freuen sich über Redundanz und Lastverteilung:
Meine DNS-Domäne ws.its ist fiktiv. Für die Toplevel-Domain its gibt es keinen DNS-Server, den ich um Erlaubnis dazu fragen könnte. Also ignoriere ich die Warnung:
Danach muss ich nur noch durchbestätigen:
Nach der initialen Einrichtung und Replikation wird der Server automatisch neustarten.
Kontrolle der Replikation
Die AD-Replikation sollte einige Minuten Einrichtungszeit gebrauchen. Beide meiner Domain Controller werden den Konsistency-Check durchführen und dabei feststellen, dass sie keine Verbindungsobjekte haben. Das ist gut in der Konsole „AD Standorte und Dienste“ sichtbar. Hier habe ich 2 Konsolen gestartet und mit je einem der DCs verbunden:
Wenn ihr es eilig habt, dann könnt ihr das KCC selber starten. Dann wird auf dem dazugehörigen DC das Verbindungsobjekt automatisch angelegt:
Dank der AD-Replikation wird dieses Verbindungsobjekt dann auf den anderen DC repliziert:
Ebenso muss es aber auch eine Replikation in die andere Richtung geben. Diese ist bei mir ebenfalls schon da:
Final kontrolliere ich noch die AD-Replikation mit der PowerShell. Hier gibt es noch ein Problem, das aber gleich automatisch behoben sein wird:
Und so ist es dann auch:
Kontrolle der Eventlogs
Das wird gerne vergessen. Aber in den Eventlogs kann man schön nachvollziehen, ob alles passt. Hier sieht man z.B. die Automatik der Replikationseinrichtung:
Aber die Replikation ist nicht auf die AD-Datenbank beschränkt. Mit DFS-R werden die Dateien vom SYSVOL und NETLOGON synchronisiert. Hier muss dieses Event ohne nachfolgende Fehler gefunden werden:
Ohne die DFS-Replikation würde es massive Störungen bei der Gruppenrichtlinienverarbeitung geben. Daher muss hier zügig kontrolliert werden!
Und bitte kontrolliert hier auch gleich das DNS-Serverlog und sucht dieses Event:
Kontrolle der DNS-Integration und DNS-Konfiguration
Im DNS sollte nun wieder geprüft werden, ob die erforderlichen Service-Records automatisch angelegt wurden. Bei meinem kleinen AD hilft eine optische Kontrolle – wie bei der Vorbereitung gezeigt. Aber auch eine nltest-Abfrage kann hilfreich sein. Hier passt alles:
Nun stelle ich noch die DNS-Konfiguration wieder ein. Dazu nutze ich meine Aufzeichnung in dieser Dokumentation. Der DNS-Forwarder für die Übergangszeit kommt raus. Dafür kommen die beiden richtigen rein:
Mein C:\Admin-Verzeichnis kopiere ich vom Fileserver nach lokal:
Damit kann ich dann auch die DNS-Protokollierung wieder aktivieren und das Logfile fortschreiben:
Damit habe ich nun wieder 2 Domain Controller mit DNS. 🙂
Nacharbeiten
Monitoring konfigurieren
Wie bei den vorherigen Servern installiere ich meine PRTG-Hilfsscripte:
Dann beende ich die Wartung im PRTG und warte auf die ersten Ergebnisse. In meiner Server-Baseline wird wieder das fehlende Backup bemängelt:
Kontrolle der SIEM-Integration
Ereignisse auf den Domain Controllern sind für forensische Analysen extrem wertvoll. Daher kontrolliere ich, ob der neue DC Events zu meinem Elastic SIEM sendet. Der dafür erforderliche Elastic Agent sollte dank GPO mittlerweile automatisch installiert und konfiguriert sein. Im Menü Fleet sehe ich den alten und den neuen Server:
Den alten Agent entferne ich
Aufgaben importieren und Verknüpfungen anlegen
Ich importiere meine geplanten Aufgaben, die ich auf dem alten Server als xml-Dateien exportiert hatte:
Konfiguration der Datensicherung
Ich installiere das Windows Feature „Windows Server Backup“:
Die Sicherungsaufgabe habe ich bereits importiert. Nun stelle ich nur noch den gMSA-Account ein. Wie immer nutze ich dazu mein Script gMSA-Admin:
Die Sicherung wird dann in der Nacht ausgeführt.
JEA-Endpunkt für mein PAM
Meine PAM-Lösung basiert auf einem Just-Enough-Administration-Endpunkt (WS IT-Solutions · Privileged Access Management mit Just Enough Administration (Update V1.09)). Dieser muss auf allen Domain Controllern erstellt und aktiviert sein. Dafür habe ich mein Setup-Script auf meinem Fileserver. Darin ist die Installations-Funktion enthalten:
Updatekonfiguration
Im WSUS kontrolliere ich den Eintrag für meinen neuen DC. Ihm fehlen noch einige Updates. Die zieht er sich diese Nacht selber dank der Vollautomatik:
Bereinigung im Hyper-V
Dieser Schritt ist sehr einfach: Ich entferne die VM und die dazugehörigen Dateien und Verzeichnisse:
Abschluss
Das waren viele Arbeitsschritte! Die eigentliche Umstellung ist nicht viel. Aber mit den Vor- und Nacharbeiten ist man beschäftigt. Und dennoch würde ich diese Variante immer einem Inplace Upgrade vorziehen. Denn zusätzlich zur eigentlichen Migration kontrolliert man noch einmal viele Details und findet vielleicht sogar verborgene Fehlkonfigurationen, die schon seit Jahren im System versteckt sind. Lasst das einfach mal ordentlich sacken. Bei Unklarheiten lest meine Doku einfach noch einmal oder schreibt mich an. Ich helfe gerne.
Stay tuned.
Die Übersichtsseite zum meinem Migrationsprojekt findet ihr hier: Migration zu Windows Server 2025