Windows Server 2016: der 12. Januar 2027 ist näher als er wirkt
Am 12. Januar 2027 endet der Extended Support für Windows Server 2016. Danach gibt es keine kostenlosen Sicherheitsupdates mehr – neu entdeckte Lücken bleiben offen, werden aber weiterhin öffentlich beschrieben. Sechzehn Monate klingen komfortabel. Für eine Domänencontroller-Migration inklusive Anhebung der Funktionsebene sind sie es nicht.
Bei Anwendungsservern migriert man ein System. Bei Domänencontrollern migriert man die Grundlage, auf der alle anderen Systeme laufen.
Warum 2016 ein besonderer Fall ist
Server 2016 ist in vielen Umgebungen die Generation, mit der das Active Directory zuletzt grundlegend angefasst wurde. Entsprechend häufig finden sich dort die Domänencontroller, die Zertifizierungsstelle und der Fileserver mit den gewachsenen Berechtigungen. Gleichzeitig hat sich um diese Systeme herum einiges verändert:
- SQL Server 2016 ist seit dem 14. Juli 2026 ohne Support – häufig auf demselben Server.
- Office und Exchange 2016/2019 haben ihr Supportende bereits erreicht.
- Funktionsebenen stehen oft noch auf 2008 R2 oder 2012 R2 und blockieren moderne Sicherheitsfunktionen.
- SYSVOL-Replikation über FRS ist in einigen Altumgebungen nie auf DFSR migriert worden – ein Blocker für jeden neueren DC.
- Hardware aus der Anschaffungswelle 2016/2017 erreicht parallel ihr Wartungsende.
Schritt 1: Bestand mit Rollen erfassen
Nicht die Anzahl der 2016er-Server bestimmt den Aufwand, sondern deren Rollen. Ein Druckserver ist an einem Nachmittag ersetzt, ein Domänencontroller mit FSMO-Rollen und einer angebundenen Zertifizierungsstelle ist ein Projekt.
# ISW - Server 2016: Bestand, Rollen und Migrationshuerden
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
Import-Module ActiveDirectory
$ziel = Get-ADComputer -Filter 'OperatingSystem -like "*Server 2016*" -and Enabled -eq $true' `
-Properties OperatingSystem, OperatingSystemVersion, DNSHostName, LastLogonDate |
Where-Object { $_.LastLogonDate -gt (Get-Date).AddDays(-45) }
foreach ($s in $ziel) {
$o = [ordered]@{
Server = $s.Name
OS = $s.OperatingSystem
LetzteAnm = $s.LastLogonDate
IstDC = $false
Rollen = 'n/a'
CPU_Kerne = 'n/a'
RAM_GB = 'n/a'
Erreichbar = $false
}
try {
$roll = Invoke-Command -ComputerName $s.DNSHostName -ErrorAction Stop -ScriptBlock {
(Get-WindowsFeature | Where-Object { $_.Installed -and $_.FeatureType -eq 'Role' }).Name
}
$cs = Get-CimInstance Win32_ComputerSystem -ComputerName $s.DNSHostName -ErrorAction Stop
$o.Rollen = ($roll -join ', ')
$o.IstDC = ($roll -contains 'AD-Domain-Services')
$o.CPU_Kerne = $cs.NumberOfLogicalProcessors
$o.RAM_GB = [math]::Round($cs.TotalPhysicalMemory/1GB,0)
$o.Erreichbar = $true
} catch {
$o.Rollen = "Abfrage fehlgeschlagen: $($_.Exception.Message)"
}
[pscustomobject]$o
}Für die Domänencontroller kommt eine zweite Prüfung dazu. Diese vier Abfragen entscheiden darüber, ob die Migration ein Standardvorgang oder ein Vorprojekt wird:
# Funktionsebenen und FSMO - vor jeder DC-Migration pruefen Get-ADForest | Select-Object Name, ForestMode, SchemaMaster, DomainNamingMaster Get-ADDomain | Select-Object Name, DomainMode, PDCEmulator, RIDMaster, InfrastructureMaster # Replikationsstatus aller DCs repadmin /replsummary # Passen SYSVOL-Replikation und DFSR? (FRS ist seit Server 2019 nicht mehr unterstuetzt) dfsrmig /getglobalstate
Schritt 2: Die richtige Reihenfolge
- Replikation und SYSVOL in Ordnung bringen. Alles Weitere setzt eine fehlerfreie Replikation voraus.
- Neue Domänencontroller unter Server 2025 hinzufügen, mindestens zwei, in unterschiedlichen Fehlerdomänen.
- FSMO-Rollen übertragen und den DNS-Verweis in DHCP und Clients kontrollieren – der häufigste Stolperstein nach der Übertragung.
- Alte DCs herabstufen und aus der Domäne entfernen, nicht einfach abschalten.
- Funktionsebenen anheben, sobald kein alter DC mehr existiert. Erst danach stehen neuere Sicherheitsfunktionen zur Verfügung.
- Mitgliedsserver in Wellen nachziehen, beginnend mit denen ohne Branchenanwendung.
- Die Zertifizierungsstelle gesondert planen – eine CA-Migration ist ein eigenes Vorhaben mit eigenem Testlauf.
Schritt 3: Der Weg, wenn es nicht reicht
| Option | Wann sinnvoll | Zu beachten |
|---|---|---|
| Migration auf Windows Server 2025 | Der Regelfall – neue Hardware oder Virtualisierung vorhanden | Funktionsebenen und Anwendungsverträglichkeit vorab prüfen |
| Verlagerung nach Azure | Wenn ohnehin eine Cloud-Strategie besteht | Sicherheitsupdates für Altsysteme sind dort ohne Zusatzkosten enthalten – das kann eine Übergangsphase entlasten |
| Kostenpflichtige ESU | Branchenanwendung ohne Nachfolger, Ersatz in Arbeit | Maximal drei Jahre, nur sicherheitskritische Patches, laufende Kosten pro Jahr |
| Isolieren und weiterbetreiben | Einzelsystem ohne Alternative | Netzsegmentierung, keine Internet-Erreichbarkeit, dokumentierte Risikoübernahme durch die Geschäftsleitung |
Ein Punkt, der in der Budgetdiskussion regelmäßig hilft: Cyberversicherer prüfen im Schadensfall, ob bekannte Risiken bewusst in Kauf genommen wurden. Der Betrieb eines Systems nach dessen öffentlich bekanntem Supportende ist ein solches Risiko – mit möglichen Folgen für die Schadensregulierung. Das ist ein Argument, das in der Geschäftsleitung oft besser trägt als jede technische Begründung.