Windows Server 2016 | Noch 88 Tage Updates

Am 12. Januar 2027 liefert Microsoft das letzte Sicherheitsupdate für Windows Server 2016 aus. Das Datum ist der Januar-Patchday, ab dem 13. Januar bekommen 2016-Server ohne Extended Security Updates (ESU) keine monatlichen Patches mehr. Microsoft hat das mit MC1507705 am 14. Oktober 2026 noch einmal angekündigt. Ab heute, dem 16. Oktober, bleiben dir 88 Tage und genau drei Patchdays: 10. November, 8. Dezember und 12. Januar.

In vielen Umgebungen ist der Ausgangszustand derselbe: Irgendwo laufen noch 2016-Server, aber niemand weiß genau, wie viele, welche Edition und welche Rolle darauf hängt. Das Ziel bis Januar ist eine Liste, in der für jeden Server eine Entscheidung steht: In-Place-Upgrade, Neuaufbau, ESU als Brücke oder Umzug nach Azure. Der Weg dorthin hat fünf Schritte.

Laut Lifecycle-Seite endet der Extended Support für Windows Server 2016 am 13.01.2027 um 6:59:59 Uhr pazifischer Zeit, also mit Ablauf des 12. Januar in Redmond. Betroffen sind alle Editionen: Datacenter, Standard, Essentials und MultiPoint Premium. Für Essentials endet am selben Tag der Support für die Essentials-Funktionen, Microsoft nennt ausdrücklich Remote Web Access sowie remotewebaccess.com mit der zugehörigen DynDNS-Integration.

Die Edition entscheidet über deinen Spielraum. ESU gibt es nur für Standard und Datacenter. Ein Essentials-Server hat nach dem 12. Januar keinen Weg zu weiteren Sicherheitsupdates, und Microsoft schreibt selbst, dass es für das Essentials-Erlebnis keinen Eins-zu-eins-Ersatz gibt.

Microsoft empfiehlt als Ziel Windows Server 2025. Gegen 2022 als Zwischenlösung spricht der Kalender: Windows Server 2022 ist seit dem 13. Oktober 2026 im Extended Support (MC1507704) und erhält Sicherheitsupdates bis 14. Oktober 2031. Windows Server 2025 läuft bis 10. Oktober 2034. Wer heute auf 2022 migriert, steht in fünf Jahren wieder vor derselben Aufgabe.

Am selben 12. Januar endet übrigens auch Windows 10 Enterprise LTSC 2021 (MC1507706). Wenn du die Inventur ohnehin machst, nimm die LTSC-Clients gleich mit.

Das Hanser-Lehrbuch „IT-Sicherheit“ setzt im Patchmanagement-Prozess nach IEC 62443 an derselben Stelle an: Phase 1 ist eine möglichst automatisiert erstellte Inventarliste der eingesetzten Hard- und Software. Die schnellste belastbare Quelle dafür ist das Active Directory, weil jedes Domänenmitglied sein Betriebssystem im Attribut operatingSystem hinterlegt. Der Filter läuft serverseitig, du ziehst also nicht das komplette Computerverzeichnis über die Leitung.

Das Ergebnis enthält Karteileichen. LastLogonDate wird aus lastLogonTimestamp berechnet, das AD standardmäßig nur alle 9 bis 14 Tage aktualisiert. Für die Inventur reicht diese Unschärfe: Ein Konto, das seit Monaten keinen Logon hatte, ist ein Kandidat zum Aufräumen und nicht zum Migrieren. Was das AD nicht sieht, fehlt in der Liste: Server in Arbeitsgruppen, in DMZ-Forests oder beim Hoster. Diese Systeme trägst du aus der Virtualisierungs- oder CMDB-Sicht nach.

Hast du Server bereits an Azure Arc angebunden, zeigt dir das Portal die 2016-Maschinen gesondert an, sobald du den ESU-Bereich öffnest (siehe Schritt 4).

Nicht jede Rolle verträgt ein In-Place-Upgrade. Deshalb bestimmt die Rolle den Weg, nicht das Betriebssystem. Das folgende Skript fragt auf jedem erreichbaren Server die migrationsrelevanten Rollen und zwei Dienste ab: ADSync steht für Entra Connect Sync, MSExchangeIS für einen Exchange-Postfachserver. Beide sind keine Windows-Features und tauchen in Get-WindowsFeature deshalb nicht auf.

Get-WindowsFeature stammt aus dem ServerManager-Modul, das Skript läuft also auf einem Verwaltungsserver mit RSAT. Für Invoke-Command muss WinRM auf den Zielen offen sein. Die Zeilen mit „NICHT ERREICHBAR“ sind deine erste Nacharbeitsliste.

Die Migrationsmatrix von Microsoft ordnet die Rollen so ein:

Bei Exchange, Entra Connect und RDS reicht die Tabelle nicht. Exchange 2016 läuft auf Windows Server 2016, ist aber seit dem 14. Oktober 2025 selbst ohne Support. Exchange 2019 war auf Windows Server 2016 nie unterstützt, dafür sind 2019 oder neuer nötig. Exchange SE läuft nur auf 2019, 2022 und 2025, und ein In-Place-Upgrade des Betriebssystems mit installiertem Exchange unterstützt Microsoft nicht. Für Exchange heißt das immer: neue Server.

Für Entra Connect Sync empfiehlt Microsoft Windows Server 2025 oder 2022 mit Desktopdarstellung, Server Core ist nicht unterstützt. Für den Betriebssystemwechsel rät Microsoft zu einem neuen Server und einer Swing-Migration über den Staging-Modus. Ein In-Place-Upgrade von 2016 auf 2025 ist laut Microsoft Learn zwar unterstützt, beim neuen Server bleibt dir aber der alte als Rückfallebene. Der nächste Termin steht schon fest: Bis 7. April 2027 brauchst du Version 2.6.84.0 oder neuer mit anwendungsbasierter Authentifizierung.

Bei RDS hängt mehr dran als das Betriebssystem. Session Hosts auf 2025 brauchen RDS-CALs der Version 2025, und diese CALs lassen sich nur auf einem Lizenzserver mit 2025 installieren. Laut „Microsoft 365 for IT Pros 2027“ sind für die vollen Office-Clients Windows 11 sowie Windows Server 2025 und 2022 offiziell unterstützt, 2016 steht nicht auf der Liste. Ein Session Host auf 2016 mit Microsoft 365 Apps läuft damit schon heute außerhalb der Herstellerangaben.

Mit den beiden CSV-Dateien gehst du jeden Server einzeln durch. Die Reihenfolge der Fragen ist dabei nicht beliebig, weil jede Antwort Optionen ausschließt.

Die erste Frage lautet: Wird der Server noch gebraucht? Jede Anwendung, die du abschaltest, musst du weder migrieren noch per ESU bezahlen. Die zweite Frage betrifft die Edition. Bei Essentials fallen ESU weg, hier bleibt nur der Ersatz durch einen aktuellen Server oder einen Cloud-Dienst. Microsoft rät, Remote Web Access vorher durch einen unterstützten Fernzugang zu ersetzen und Backup sowie DNS und Zertifikate einzeln zu prüfen.

Die dritte Frage stellt die Rolle aus Schritt 2. AD DS, AD FS, Exchange, Druckdienste und Entra Connect landen beim Neuaufbau. Domänencontroller installierst du neu mit 2025, überträgst die FSMO-Rollen und stufst die alten DCs herab. Bei AD FS nimmst du neue 2025-Knoten in die Farm auf, entfernst die 2016-Knoten und hebst danach auf dem primären Knoten mit Test-AdfsFarmBehaviorLevelRaise und Invoke-AdfsFarmBehaviorLevelRaise das Farm Behavior Level an. Microsoft empfiehlt in derselben Anleitung ausdrücklich, statt eines AD-FS-Upgrades nach Entra ID zu migrieren. Die Autoren von „Microsoft 365 for IT Pros 2027“ sehen es ähnlich: Start mit Password Hash Sync, Föderation nur bei Anforderungen, die sich anders nicht lösen lassen.

Bei Exchange gibt es eine Abkürzung, die vom Zweck abhängt. Viele Hybrid-Umgebungen halten den letzten Exchange-Server nur für die Empfängerverwaltung, weil das AD die Quelle der Exchange-Attribute ist. Mit dem Attribut IsExchangeCloudManaged verschiebst du diese Hoheit pro Postfach nach Exchange Online, Voraussetzung ist Entra Connect Sync ab Version 2.5.190.0. Dient der Server dagegen als SMTP-Relay für Geräte und Anwendungen, brauchst du weiter einen lokalen Exchange-Server, dann eben neu mit Exchange SE auf 2025.

Die vierte Frage ist technisch: Erlaubt die Konstellation ein In-Place-Upgrade? Laut Microsofts Tabelle geht ein nicht geclusterter 2016-Server direkt auf 2025, ohne Zwischenschritt über 2019 oder 2022. Einschränkungen gibt es trotzdem. Die Edition bleibt standardmäßig erhalten (Standard nach Datacenter geht, zurück nicht), ein Wechsel zwischen Server Core und Desktopdarstellung ist nicht möglich, NIC-Teaming musst du vorher deaktivieren, und eine Evaluierungsversion taugt nicht als Upgrade-Ziel. Jedes Upgrade braucht eine eigene Lizenz. Cluster sind der Sonderfall: Das Cluster OS Rolling Upgrade geht nur eine Version pro Schritt, von 2016 bis 2025 sind das drei Durchläufe. Ein neuer Cluster auf 2025, auf den du die Rollen migrierst, ist hier oft der kürzere Weg.

Die fünfte Frage stellst du nur, wenn alle anderen Wege bis Januar nicht fertig werden: ESU oder Azure. Beides ist eine Brücke, kein Ziel.

ESU für Windows Server 2016 liefern laut Microsoft Learn bis zu drei Jahre lang kritische und wichtige Sicherheitsupdates, also bis 2030. Neue Funktionen und Fehlerbehebungen ohne Sicherheitsbezug enthalten sie nicht. Microsoft beschreibt drei Bezugswege.

Über Azure Arc kaufst du ESU monatlich nach Verbrauch und ohne Produktschlüssel. Die Lizenzen lassen sich seit dem 3. August 2026 im Portal einrichten, abgerechnet wird ab dem 13. Januar 2027. Du brauchst Software Assurance über einen Volumenlizenzvertrag (etwa EA, EAS, SCE) oder Open Value. Bei Lizenzierung über SPLA oder Server Subscription entfällt diese Voraussetzung. Der Connected Machine Agent muss mindestens Version 1.62 haben.

Beim Anlegen wählst du die SKU (Standard oder Datacenter) und die Zahl der Kerne. Du kannst die Lizenz deaktiviert anlegen, dann löst sie noch keine Abrechnung aus. Unter „Eligible resources“ markierst du die Arc-Server, wählst „Enable ESUs“, die Lizenz und den Kerntyp (physisch oder virtuell). Auf dem Server bestätigt azcmagent show im Abschnitt Extended Security Updates den Status „Active“. Die Regeln zur Mindestzahl an Kernen findest du in den Lizenzrichtlinien zu Arc-ESU, die Arc-Anleitung nennt dazu keine Werte.

Der klassische Weg läuft über die Volumenlizenzierung mit jährlicher Abrechnung, dafür verweist Microsoft auf den Kontakt zum Microsoft-Vertrieb. Der dritte Weg ist Azure selbst: Für Workloads in Azure-VMs, Dedicated Host, Azure VMware Solution und dem Azure-Stack-Portfolio nennt Microsoft drei zusätzliche Jahre ESU. Ob das für 2016 wie bei 2012 und 2012 R2 ohne Aufpreis gilt, belegt die 2016-Seite nicht ausdrücklich [ungeprüft]. Preise veröffentlicht Microsoft auf keiner der geprüften Seiten, kalkuliere also erst mit einem Angebot.

Die drei Patchdays geben das Raster vor, weil jeder Server bis zum letzten Update auf aktuellem Stand sein muss, sonst startet er mit einer Lücke in die ESU-Phase oder in die Abschaltung.

Bis Ende Oktober steht die Inventur: beide CSV-Dateien, ein Verantwortlicher pro Server und das Ergebnis der Frage, ob der Server noch gebraucht wird. Bis zum Patchday am 10. November entscheidest du für jeden Server den Weg. ESU-Kandidaten bindest du direkt danach an Azure Arc an und legst die Lizenzen deaktiviert an. Das kostet bis Januar nichts, weil die Abrechnung erst am 13. Januar beginnt, und du merkst früh, ob Proxy oder Firewall den Agenten blockieren.

Zwischen 10. November und 8. Dezember laufen die Neuaufbauten mit Abhängigkeiten nach außen: Entra Connect per Swing-Migration auf 2025, gleich mit Blick auf den 7. April 2027, dann die AD-FS-Knoten und die neuen Domänencontroller. Danach folgen In-Place-Upgrades der einfachen Rollen. Plane die Weihnachtswochen nicht als Arbeitszeit ein, in vielen Häusern gilt dann ein Change-Freeze, und die Leute sind im Urlaub.

Im Januar spielst du das letzte Update vom 12. Januar auf alle verbliebenen 2016-Server ein und aktivierst die vorbereiteten ESU-Lizenzen, damit der erste ESU-Patchday im Februar die Server erreicht. Was danach ohne ESU und ohne Migration übrig bleibt, gehört in die Risikoliste, mit Namen des Verantwortlichen und Abschaltdatum.

88 Tage klingen nach viel. Zählst du die Wochen bis zum 18. Dezember und ziehst die beiden Patchday-Wochen im November und Dezember ab, bleiben rund sieben Arbeitswochen, und die erste davon geht für die Inventur drauf. Der Engpass liegt selten bei der Technik, sondern bei der Frage, wem ein Server gehört und ob die Anwendung darauf noch jemand braucht. Deshalb steht die Inventur am Anfang, und deshalb gehört eine Spalte „Verantwortlich“ in die CSV.

Den größten Aufwand verursachen die Identitätsrollen. Domänencontroller und AD FS lassen sich nicht per In-Place-Upgrade hochziehen, Entra Connect sollte es nicht, und ein Fehler bei einer dieser Rollen trifft Anmeldung oder Synchronisation aller Benutzer. Gleichzeitig ist die Migration die Gelegenheit, Altlasten loszuwerden. Ein AD FS, das nur noch für Microsoft 365 läuft, ist auf neuen Servern genauso ein Tier-0-Ziel wie auf alten. Der Wechsel auf Password Hash Sync spart dir die Farm komplett.

ESU über Azure Arc ist bequem, weil du monatlich abrechnest und ohne Schlüssel arbeitest. Die Bequemlichkeit hat einen Haken: Ein Server, der „nur kurz“ per ESU laufen soll, hat ohne festes Enddatum keinen Grund mehr, abgeschaltet zu werden. Die Updates enden spätestens 2030, und die Sicherheitslage alter Systeme wird mit jedem Jahr schlechter. Das Hanser-Lehrbuch zur IT-Sicherheit beschreibt das am Beispiel langlebiger Anlagen: Je länger ein System im Betrieb bleibt, desto weniger Hersteller warten es, und später bekannt gewordene Schwachstellen werden nie mehr behoben. Leg für jeden ESU-Server ein Abschaltdatum fest, bevor du die Lizenz aktivierst.

Essentials-Server sind der härteste Fall, weil weder ESU noch ein direkter Nachfolger existieren. Wenn du davon noch einen betreibst, fang mit ihm an. Remote Web Access und die DynDNS-Adresse fallen am 12. Januar weg, und mit ihnen der Fernzugang deiner Anwender.