Windows Server 2016 läuft aus — der Fahrplan von hinten gerechnet

/01Was am 13. Januar 2027 endet

Windows Server folgt wie jede Long-Term-Servicing-Version der festen Lifecycle-Politik von Microsoft: ein Start-Datum, ein Ende des Mainstream-Supports, ein Ende des Extended-Supports. Bei Windows Server 2016 liegen diese Marken auf dem 15. Oktober 2016, dem 12. Januar 2022 und dem 13. Januar 2027. Der Unterschied zwischen den letzten beiden Daten wird oft verwechselt: Mit dem Mainstream-Ende 2022 verlor die Version bereits neue Funktionen, kostenlose Supportanfragen und nicht sicherheitsrelevante Fixes — sie lief seither nur noch im Extended-Support, der ausschließlich noch CVE-relevante Updates liefert. Am 13. Januar 2027 endet auch das. Danach erscheinen keine Patches mehr für kritisch oder wichtig eingestufte Lücken, auch dann nicht, wenn eine davon aktiv ausgenutzt wird und in den KEV-Katalog der CISA aufgenommen würde.

Eine Randbemerkung, die in diesen Wochen selbst relevant wird: Auch Windows Server 2022 verliert am 14. Oktober 2026 seinen Mainstream-Support. Das ist kein Grund, von 2022 als Zielversion abzurücken — Extended Support läuft dort bis Oktober 2031, Sicherheitsupdates kommen also fünf weitere Jahre. Es zeigt nur, dass „Mainstream-Ende" nichts mit dem eigentlichen Sicherheitsrisiko zu tun hat, sondern mit Komfortleistungen, die zuerst wegfallen.

Für Windows Server 2016 existiert ein Extended-Security-Updates-Programm, das mit dem Ende des Extended Support beginnt. Was es nicht gibt, ist ein öffentlich einsehbarer Preis dafür — Stand 31.08.2026 keine öffentliche Preisangabe gefunden. Microsoft nennt zwei Bezugswege: kostenfrei inkludiert für Server, die als virtuelle Maschine nach Azure migriert werden, oder kostenpflichtig über Azure Arc im Pay-as-you-go-Modell beziehungsweise über das Volume Licensing Center mit einem eigenen Vertriebskontakt. Für die Budgetplanung heißt das: ESU ist eine reale Option, aber keine Zahl, die sich ohne Angebot seriös in eine Kalkulation schreiben lässt.

/02Der Rückwärtsplan: was die verbleibende Zeit hergibt

Vom Veröffentlichungsdatum dieses Artikels bis zum 13. Januar 2027 liegen rund achtzehn Wochen. Das ist die ehrliche Ausgangslage, und sie verlangt eine andere Planung als „wir migrieren dieses Jahr noch alle Server". Eine vollständige Migration von Domänencontrollern, Fileservern, Hyper-V-Hosts und sämtlicher Anwendungsserver in achtzehn Wochen gelingt bei einer Handvoll Systemen und einer eingespielten Betriebsmannschaft. Bei zehn oder mehr Servern, mehreren Standorten und gewachsenen Abhängigkeiten geht sie sich in dieser Zeit nicht mehr vollständig aus — und das ist keine Ausrede, sondern eine Rechnung, die man vor dem Projektstart machen sollte, nicht danach.

Ein Beispielplan für eine mittelständische Umgebung mit fünf bis acht Servern:

Was dieser Plan bewusst nicht enthält, ist eine Zeile für jede der drei bis fünf Altanwendungen, die in praktisch jeder gewachsenen Umgebung an einer alten Version hängen. Genau die sprengen den Achtzehn-Wochen-Rahmen am zuverlässigsten — Abschnitt sieben geht darauf ein. Wenn die eigene Bestandsaufnahme in Woche eins mehr als acht bis zehn Server oder mehr als zwei kritische Altanwendungen zeigt, ist der realistische Schluss nicht „schneller migrieren", sondern eine Prioritätenliste plus ESU als Brücke für das, was nicht rechtzeitig fertig wird. Für Betriebe mit NIS2-Pflichten ist das kein Detail: Ein Betriebssystem ohne Sicherheitsupdates ist im Ernstfall ein Befund, den eine Meldung schwerer macht, nicht leichter.

/03Domänencontroller zuerst

Die Reihenfolge ist keine Geschmacksfrage. Active Directory ist die Voraussetzung für praktisch jede andere Windows-Rolle — Anmeldung, Gruppenrichtlinien, DNS, Kerberos-Tickets. Ein Fileserver oder Hyper-V-Host auf neuer Version, der noch gegen einen Domänencontroller auf Windows Server 2016 authentifiziert, funktioniert zwar, aber er erbt das Sicherheitsniveau seines schwächsten Glieds. Deshalb steht AD DS am Anfang jedes ernsthaften Fahrplans, nicht weil es am dringendsten wäre, sondern weil alles andere davon abhängt.

Der erste Schritt ist eine Bestandsaufnahme, die sich mit Bordmitteln erledigen lässt:

PS C:\> Get-ADDomainController -Filter * |
  Select-Object HostName, OperatingSystem, Site

HostName                    OperatingSystem                 Site
--------                    ---------------                 ----
dc01.kunde.local            Windows Server 2016 Standard     Hauptsitz
dc02.kunde.local            Windows Server 2016 Standard     Hauptsitz
dc03.kunde.local            Windows Server 2022 Standard     Zweigstelle

Das übliche Vorgehen ist nicht das In-Place-Upgrade des bestehenden Domänencontrollers, sondern das Hinzufügen eines neuen DC auf der Zielversion, das Abwarten der vollständigen Replikation und erst danach das kontrollierte Herabstufen (Uninstall-ADDSDomainController) der alten Maschine. Der Grund: Ein neuer DC lässt sich vor der Übernahme in Ruhe testen, während ein fehlgeschlagenes In-Place-Upgrade eines produktiven Domänencontrollers im schlechtesten Fall die gesamte Authentifizierung eines Standorts mitreißt. Vor dem Hinzufügen eines DC auf Windows Server 2022 oder 2025 muss außerdem das Forest- und Domain-Functional-Level geprüft werden — beide dürfen die Zielversion nicht überschreiten, was bei Umgebungen, die seit Windows Server 2008 R2 gewachsen sind, gelegentlich eine eigene kleine Aufräumaktion nach sich zieht.

Wer FSMO-Rollen (Flexible Single Master Operations) auf dem alten DC hält — Schema-Master, Domain-Naming-Master, RID-Master, PDC-Emulator, Infrastructure-Master —, muss diese vor dem endgültigen Herabstufen explizit übertragen. Move-ADDirectoryServerOperationMasterRole erledigt das je Rolle; wer es vergisst, bemerkt es meist erst, wenn die alte Maschine bereits abgeschaltet ist und niemand mehr weiß, welcher DC gerade der PDC-Emulator ist.

/04Fileserver: Bestand, Berechtigungen, Übergabe

Der Fileserver ist technisch der unspektakulärste Teil des Fahrplans und praktisch der, an dem am meisten Zeit verloren geht — nicht wegen der Migration selbst, sondern wegen der Berechtigungen, die sich über Jahre angesammelt haben. Bevor eine einzige Datei kopiert wird, lohnt sich ein Export der bestehenden Freigaben und NTFS-Berechtigungen als Referenz, gegen die sich das Ergebnis später prüfen lässt. Robocopy mit den Schaltern /COPYALL /SEC /MIR überträgt Daten inklusive Berechtigungen, Eigentümer und Zeitstempeln — für die erste, noch produktive Kopie reicht ein Lauf ohne /MIR, für den finalen Umzugsschnitt am Wochenende dann mit Spiegelung.

Läuft der Fileserver bereits über einen DFS-Namespace, wird die Migration für die Nutzer unsichtbar: Ein neuer Zielordner wird als weiteres Replikationsziel eingebunden, DFS repliziert im Hintergrund, und erst wenn beide Seiten synchron sind, wird der alte Server aus dem Namespace entfernt — kein Laufwerksbuchstabe ändert sich, kein Nutzer merkt den Wechsel. Ohne DFS-Namespace, also bei klassischen UNC-Pfaden und Skript- oder GPO-verteilten Laufwerksverbindungen, ist der Umzug ein einmaliger Schnitt mit Downtime-Fenster, und jeder hartcodierte Pfad in einer Applikation oder einem Makro wird erst beim Testen sichtbar.

Ein Punkt, der regelmäßig übersehen wird: Freigabeberechtigungen (Share Permissions) und NTFS-Berechtigungen sind zwei getrennte Ebenen, und beide müssen mitziehen. Wer nur die NTFS-ACLs kopiert und die Freigabe am neuen Server mit den Standardrechten „Jeder: Lesen/Schreiben" neu anlegt, öffnet Daten, die vorher enger begrenzt waren — ein stiller Rückschritt, der erst bei der nächsten Prüfung auffällt, wenn überhaupt.

/05Hyper-V-Host: die Virtualisierungsschicht mitziehen

Wenn der Windows-Server-2016-Host gleichzeitig Hyper-V-Hypervisor ist, betrifft das Support-Ende nicht nur das Gastbetriebssystem, sondern die Schicht, auf der alle virtuellen Maschinen laufen. Die Migration hat hier zwei saubere Wege. Der erste ist Live Migration in einen bestehenden oder neuen Cluster: Läuft der Zielhost bereits, lassen sich VMs ohne spürbare Downtime auf ihn verschieben, vorausgesetzt beide Hosts sind Mitglied desselben Clusters oder zumindest per Shared-Nothing-Live-Migration erreichbar. Der zweite Weg ist Export/Import: Die VM wird auf dem alten Host exportiert, die Konfigurationsdateien und virtuellen Festplatten wandern auf den neuen Host, dort erfolgt der Import — mit Downtime in der Größenordnung der Kopierzeit, aber ohne Cluster-Voraussetzung.

Ein Cluster-Betrieb (Failover-Clustering) erlaubt zusätzlich das Cluster-OS-Rolling-Upgrade: Knoten werden nacheinander aus dem Cluster genommen, neu installiert und wieder aufgenommen, während die VMs auf den verbleibenden Knoten weiterlaufen. Der Haken dabei — und Microsoft benennt ihn ausdrücklich —: Ein Cluster-Rolling-Upgrade überspringt immer nur eine Version auf einmal. Von Windows Server 2016 auf 2025 ist damit ein Zwischenschritt über 2019 oder 2022 nötig, während ein nicht geclusterter Host per Installationsmedium direkt springen darf. Wer im Cluster fährt, plant also zwei Etappen ein, nicht eine.

Wer die Gelegenheit ohnehin zum Plattformwechsel nutzen will, findet den entsprechenden Abschnitt unter /08 — dort geht es um den Wechsel auf Proxmox statt auf eine neuere Hyper-V-Version. Wer bei Microsoft bleibt, aber zusätzlich VMware im Haus hat, sollte den Hyper-V-Umstieg nicht isoliert planen: Zwei Hypervisor-Stacks parallel zu pflegen kostet auf Dauer mehr Betriebsaufwand, als eine der beiden Plattformen konsequent zu konsolidieren.

/06In-Place-Upgrade gegen Neuaufbau

Microsoft lässt bei Windows Server 2016 mehr direkte Sprünge zu, als viele Administratoren erwarten. Über Installationsmedien ist das In-Place-Upgrade von 2016 direkt auf 2019, auf 2022 und auf 2025 möglich — ohne Zwischenschritt. Über Windows Update funktioniert der Weg dagegen nur für 2019 und 2022 als Ausgangsversion in Richtung 2025; Windows Server 2016 ist davon ausgenommen und braucht in jedem Fall die Installationsmedien.

Das ist die technische Erlaubnis — nicht automatisch die richtige Wahl. Ein In-Place-Upgrade behält Rollen, Einstellungen und Daten auf derselben Installation und ist der schnellste Weg auf neuer Software, aber auch der Weg, der jeden ungepflegten Zustand der alten Installation mitnimmt: veraltete Treiber, Registry-Leichen, Softwarereste von Programmen, die niemand mehr braucht. Ein Neuaufbau auf frischer Hardware oder frischer VM mit anschließender Rollenmigration dauert länger, verlangt eine Downtime-Planung, liefert aber einen dokumentierten, sauberen Ausgangszustand — und ist bei Domänencontrollern ohnehin der empfohlene Weg, wie Abschnitt drei zeigt.

Wer auf neue Hardware wechselt, sollte zwei Anforderungen der aktuellen Versionen vorher prüfen, nicht danach: Secured-Core-Funktionen unter Windows Server 2022 und 2025 setzen ein TPM-2.0-Modul und aktivierten Secure Boot voraus; ohne beides lässt sich zwar weiterhin ein normaler Server betreiben, aber eine der wirksamsten Firmware-Schutzschichten bleibt ungenutzt. Die zweite Anforderung betrifft das Lizenzbudget: Windows Server 2025 ist core-basiert lizenziert, mit einem Minimum von acht Core-Lizenzen je Prozessor und sechzehn Core-Lizenzen je physischem Server — auch bei einem einzelnen Prozessor —, verkauft in Paketen zu zwei und zu sechzehn Lizenzen. Für Standard- wie für Datacenter-Edition kommt zusätzlich eine CAL je Nutzer oder Gerät hinzu. Laut Microsofts eigener Preisseite liegt der Herstellerpreis (MSRP, US-Dollar) für ein 16-Core-Paket bei 1.176 US-Dollar (Standard) beziehungsweise 6.771 US-Dollar (Datacenter) — als Orientierung, nicht als deutscher Straßenpreis, der je nach Vertriebsweg abweicht.

/07Altanwendungen, die den Zeitplan sprengen

Der Rückwärtsplan aus Abschnitt zwei geht nur auf, wenn nichts blockiert. In der Praxis blockiert fast immer etwas, und es ist selten der Fileserver. Fünf wiederkehrende Fälle:

Fachanwendungen mit fest verdrahteter Windows-Server-2016-Abhängigkeit

Branchensoftware, die vor Jahren gegen eine bestimmte .NET-Framework-Version oder eine bestimmte IIS-Konfiguration eingerichtet wurde und deren Hersteller die neuere Windows-Server-Version nicht offiziell freigegeben hat. Eine Migration ohne Freigabe des Herstellers ist möglich, aber im Supportfall steht man allein da — das gehört vor Projektstart auf den Tisch, nicht danach.

Mail-Systeme im Übergang

Wer noch einen lokalen Exchange-Server betreibt, hat parallel eine eigene Migrationsfrist zu beachten — der Pflicht-Migrationspfad ist in Exchange Server SE: Der Pflicht-Migrationspfad 2026 beschrieben. Zwei Migrationsprojekte gleichzeitig auf denselben achtzehn Wochen sind selten realistisch; hier muss priorisiert werden, welches zuerst kommt.

Druckserver und Gerätetreiber

Ältere Druckertreiber, die unter 2016 noch liefen, fehlen unter 2022/2025 oft als Inbox-Treiber. Das ist kein Show-Stopper, aber ein Punkt, der Wochen kosten kann, wenn er erst am Umzugstag entdeckt wird statt in der Bestandsaufnahme.

32-Bit-Dienste und veraltete Authentifizierung

Dienste, die NTLMv1 statt Kerberos erwarten, oder Anwendungen, die noch SMBv1 voraussetzen — beides ist unter neueren Versionen standardmäßig deaktiviert und lässt sich zwar reaktivieren, sollte aber als das behandelt werden, was es ist: eine Notlösung mit eigenem Sicherheitsrisiko, nicht ein Zielzustand.

Fehlendes Testsystem

Der häufigste eigentliche Grund für Verzug ist banal: Es gibt keine Umgebung, in der sich die neue Version gegen die Altanwendung testen lässt, ohne den Produktivbetrieb zu riskieren. Eine Testumgebung — und sei es nur eine einzelne VM mit einer Kopie der Anwendung — gehört an den Anfang des Fahrplans, nicht an dessen Ende.

Für alle fünf Fälle gilt dieselbe Empfehlung: Wenn eine Altanwendung den Achtzehn-Wochen-Rahmen sprengt, ist ESU für genau diesen einen Server die ehrlichere Lösung als ein Migrationstermin, der ohnehin reißt. Das gilt besonders, wenn ungepatchte Patch-Management-Lücken auf diesem System ein Compliance-Risiko wären — dann ist eine befristete, bezahlte Brücke besser als ein unbefristetes, unbezahltes Risiko.

/08Rollen ablösen statt migrieren

Nicht jede Rolle muss auf die neue Windows-Server-Version mitwandern. Ein wachsender Teil der KMU, die 2026 vor dem Windows-Server-2016-Ende stehen, nutzt den Zwangspunkt, um bestimmte Rollen ganz zu ersetzen statt sie zu migrieren — und das ist keine Notlösung, sondern für einzelne Rollen oft die günstigere Rechnung.

Beim Fileserver ist die naheliegende Alternative ein Umzug auf Nextcloud oder SharePoint/OneDrive. Beide lösen das klassische Freigabe-Modell durch Dateisynchronisation mit Web- und Mobilzugriff ab; Berechtigungen werden nicht mehr über NTFS-ACLs, sondern über Gruppen im Identitätsanbieter gepflegt — meist Entra ID, wenn ohnehin Microsoft 365 im Einsatz ist. Der Umstieg lohnt sich vor allem dort, wo Homeoffice und mobiler Zugriff ohnehin schon über VPN-Notlösungen laufen: Ein Fileserver, der nur noch über eine Fernzugriffs-Krücke erreichbar ist, hat seine eigentliche Daseinsberechtigung als lokaler Dateiserver bereits verloren.

Beim Hyper-V-Host ist die Alternative Proxmox: eine Open-Source-Virtualisierungsplattform auf KVM- und LXC-Basis, ohne Lizenzkosten pro Core oder CAL-Pflicht. Der Umstieg bedeutet, alle Gast-VMs von Hyper-V nach KVM zu konvertieren — technisch machbar, aber mit echtem Migrationsaufwand pro VM, nicht mit einem Klick erledigt. Er lohnt sich, wenn ohnehin neue Hardware ansteht und die laufenden Windows-Server-Lizenzkosten für den Host selbst spürbar sind — bei einem einzelnen Zwei-VM-Host mit wenig Wachstumsdruck ist der Aufwand des Wechsels dagegen oft größer als der eingesparte Betrag.

Die Entscheidung läuft auf drei Fragen hinaus. Erstens: Ist die Rolle noch das, was sie vor zehn Jahren war, oder hat sich der Bedarf dahinter verschoben — vom lokalen Fileserver zum Zugriff von überall, vom Einzelserver zur wachsenden VM-Flotte? Zweitens: Steht ohnehin ein Hardwarewechsel an, der die Migrationskosten der neuen Plattform ohnehin anfallen lässt? Drittens: Ist die interne oder eingekaufte Kompetenz für die neue Plattform vorhanden, oder kommt zur Migration noch eine Lernkurve dazu, die den Achtzehn-Wochen-Rahmen zusätzlich belastet? Zwei Ja bei diesen drei Fragen sprechen für das Ablösen. Weniger als zwei Ja, und die vertraute Migration auf eine neue Windows-Server-Version ist der Weg mit dem kleineren Risiko im verbleibenden Zeitfenster.

/09Der Fahrplan im Ganzen

Zusammengefasst ergibt sich eine Reihenfolge, die sich unabhängig von der Unternehmensgröße wiederholt: Zuerst die Bestandsaufnahme, die auch die Altanwendungen aus Abschnitt sieben ehrlich mit erfasst. Dann die Domänencontroller, weil alles andere von ihnen abhängt. Dann Fileserver und Hyper-V-Host parallel, wenn genug Personal dafür da ist, sonst nacheinander in dieser Reihenfolge. Für jede Rolle einzeln die Frage aus Abschnitt acht: migrieren oder ablösen. Und für alles, was bis zum 13. Januar 2027 nachweislich nicht fertig wird, ESU als befristete, dokumentierte Brücke statt eines Termins, der ohnehin reißt.

Was diesen Fahrplan von einem reinen Alarmruf unterscheidet, ist die Reihenfolge selbst: Sie sorgt dafür, dass im Zweifel die Systeme zuerst geschützt sind, die am meisten Schaden anrichten, wenn sie es nicht sind. Ein ungepatchter Fileserver ist ein Risiko. Ein ungepatchter Domänencontroller ist ein Risiko für jedes System, das sich gegen ihn authentifiziert — und das ist am Ende jedes andere System im Netz.

/10Häufige Fragen