Hyper-V Server 2016 und System Center 2016: zwei Stichtage, ein Plattformwechsel

/01Was im Januar 2027 endet — und was nicht

Im Januar 2027 laufen zwei Microsoft-Produkte aus, die in vielen mittelständischen Umgebungen zusammen auftreten: der kostenlose Hyper-V Server 2016 als eigenständiger Hypervisor und die Verwaltungssuite System Center 2016. Für System Center 2016 ist der 11. Januar 2027 der letzte Supporttag, für Hyper-V Server 2016 der 12. Januar 2027 — danach gibt es laut Microsoft weder Sicherheits- noch sonstige Updates, keine kostenlose oder bezahlte Unterstützung und keine Aktualisierung der Online-Dokumentation mehr.

Hyper-V Server 2016 ist nicht dasselbe wie die Hyper-V-Rolle in Windows Server 2016. Er war eine kostenlose, abgespeckte Ausgabe ohne grafische Oberfläche, die nur den Hypervisor mitbrachte; die Gäste mussten trotzdem eigenständig lizenziert werden. Läuft Hyper-V als Rolle auf einem regulären Windows Server 2016, gilt dessen Lifecycle, und der fällt auf denselben Januar-Patchday. Die Lifecycle-Übersicht für 2027 führt beide Produkte in derselben Zeile mit Stichtag 12. Januar.

System Center 2016 besteht aus fünf Komponenten, die Microsoft einzeln führt: Virtual Machine Manager (VMM), Data Protection Manager (DPM), Operations Manager (SCOM), Orchestrator und Service Manager. Alle fünf enden am selben Tag. Wer nur VMM eingesetzt hat, hat ein kleineres Problem als ein Betrieb, der seine Sicherung über DPM und seine Überwachung über SCOM fährt.

Was dieser Beitrag nicht wiederholt: den Fahrplan für Domänencontroller, Fileserver und Windows-Server-Rollen. Der steht im Beitrag Windows Server 2016 Support-Ende 2027: Migrationsfahrplan, dessen Abschnitt zum Hyper-V-Host den Verbleib bei Microsoft behandelt. Hier geht es um die Gegenrichtung: Hypervisor, Verwaltung und Sicherung gemeinsam auf Proxmox zu verlegen, und um die Frage, welche Funktion dabei auf welches Werkzeug übergeht.

/02Die Zeitachse: 11. bis 13. Januar 2027

Microsoft gibt Lifecycle-Daten in Pacific Time an, und die Übersichtsseite und die Produktseiten zählen unterschiedlich: Die Übersicht nennt den letzten Supporttag, die Produktseite den Zeitpunkt, an dem der Support endet. Daraus entstehen die scheinbar widersprüchlichen Angaben „12. Januar" und „13. Januar", die beide richtig sind. Umgerechnet auf deutsche Winterzeit (neun Stunden Versatz zu Pacific Standard Time) sieht die Woche so aus:

Zwei Folgerungen ergeben sich daraus. Erstens: Das Januar-Update 2027 sollte auf jedem Hyper-V-Server-2016-Host noch eingespielt werden, bevor er abgelöst wird — es ist das letzte. Zweitens: Für System Center 2016 gibt es schon im Januar nichts mehr. Wer DPM-Agenten auf Windows-Servern betreibt, hat ab diesem Monat einen Agenten im Netz, dessen Hersteller keine Fehler mehr behebt.

Ein Wort zu ESU: Für Windows Server 2016 existiert ein Extended-Security-Updates-Programm, wie der Bestandsartikel ausführt. Für System Center 2016 und für den eigenständigen Hyper-V Server 2016 weisen die Lifecycle-Seiten kein solches Programm aus. Ob eine ESU-Lizenz für den Hypervisor greift, sollten Sie vor der Planung schriftlich bei Ihrem Lizenzpartner klären — als Rückfallposition taugt es erst, wenn das feststeht.

/03Bestandsaufnahme: welche Hosts und Werkzeuge betroffen sind

In der Praxis weiß selten jemand aus dem Stand, ob ein Host als Hyper-V Server 2016 oder als Windows Server 2016 mit Hyper-V-Rolle installiert wurde. Der Unterschied ist für die Lizenzfrage nach der Migration wichtig, nicht für das Datum. Drei Abfragen klären das auf jedem Host in wenigen Sekunden:

# 1. Welches Produkt läuft auf dem Host?
PS C:\> (Get-CimInstance Win32_OperatingSystem).Caption
Microsoft Hyper-V Server 2016

# 2. Welche System-Center-Komponenten sind installiert?
PS C:\> Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* |
>>   Where-Object DisplayName -like '*System Center*' |
>>   Select-Object DisplayName, DisplayVersion

# 3. Welche VMs, welche Generation, wo liegen die Platten?
PS C:\> Get-VM | Select-Object Name, Generation, State, Version
PS C:\> Get-VMHardDiskDrive -VMName * | Select-Object VMName, ControllerType, Path

Die erste Abfrage unterscheidet „Microsoft Hyper-V Server 2016" von „Microsoft Windows Server 2016 Standard" oder „Datacenter". Die zweite findet neben den Servern auch verwaiste Agenten — DPM- und SCOM-Agenten bleiben gern auf Maschinen liegen, deren Server längst abgebaut ist. Die dritte liefert die Spalte, die für den Umzug zählt: Die Generation entscheidet, ob die VM unter Proxmox mit klassischem BIOS (Generation 1) oder mit UEFI (Generation 2) startet.

Ergänzen Sie die Liste um eine Spalte, die keine Abfrage liefert: Welche Funktion von System Center wird tatsächlich genutzt? Viele Umgebungen haben VMM installiert, aber nur die Konsole zum Starten und Stoppen verwendet. Andere hängen an Vorlagen, Bibliotheken und Self-Service-Rollen. Das bestimmt den Aufwand im nächsten Abschnitt mehr als die Zahl der Hosts.

Prüfen Sie außerdem Get-VMReplication auf jedem Host. Läuft Hyper-V Replica zu einem zweiten Standort, ist das eine Notfallfunktion, die im Nachfolgekonzept einen eigenen Platz braucht — sie verschwindet sonst stillschweigend mit dem alten Host.

/04VMM, DPM, SCOM: welcher Nachfolger welche Funktion übernimmt

Die folgende Zuordnung ist das Arbeitsblatt, mit dem wir solche Umstiege beginnen. Sie ordnet jeder Funktion einen Nachfolger zu und benennt dort, wo es keinen gleichwertigen gibt, die Lücke ausdrücklich. Grundlage sind die Dokumentationen von Proxmox VE 9.2, Proxmox Datacenter Manager 1.1 und Proxmox Backup Server 4.2.

Drei Zeilen verdienen eine Erläuterung. Die Lastverteilung heißt unter Proxmox HA-gestützter Cluster Resource Scheduler; wie er arbeitet und wo er sich von VMMs dynamischer Optimierung unterscheidet, steht im Beitrag zur Proxmox-CRS-Lastverteilung. Die SCOM-Zeile ist die ehrlichste Lücke: Management Packs, die Anwendungen wie SQL Server oder Active Directory von innen überwachen, gibt es im Proxmox-Umfeld nicht. Proxmox liefert Metriken des Hypervisors; was in den Gästen passiert, muss ein eigenes Monitoring erfassen. Und Service Manager hat schlicht keinen Nachfolger im Hypervisor-Stack — das ist auch richtig so, ein Ticketsystem gehört nicht in die Virtualisierungsschicht.

/05Proxmox VE, Datacenter Manager und Backup Server im Zusammenspiel

Der Nachfolge-Stack besteht aus drei Produkten, die ohne zusätzliche Lizenzkosten nutzbar sind; eine Subskription bringt Zugang zum Enterprise-Repository und Herstellersupport. Proxmox VE (aktuell 9.2, veröffentlicht am 21. Mai 2026) ist Hypervisor und Clusterverwaltung in einem — anders als bei Hyper-V und VMM gibt es keinen getrennten Verwaltungsserver, jeder Knoten trägt die Weboberfläche selbst. Ein Cluster aus drei Knoten braucht also keinen vierten Server, der ihn verwaltet.

Der Proxmox Datacenter Manager (aktuell 1.1, veröffentlicht am 28. Mai 2026) ist das Gegenstück zur VMM-Konsole für mehrere Cluster. Er bündelt mehrere Proxmox-VE-Cluster und seit Version 1.0 auch Backup-Server als „Remotes", zeigt Paketstände und ausstehende Updates aller Remotes an einer Stelle und erlaubt die Migration von Gästen zwischen Clustern. Er ist ausdrücklich ein Werkzeug für die Übersicht über viele Umgebungen; für einen einzelnen Cluster an einem Standort brauchen Sie ihn nicht.

Der Proxmox Backup Server (aktuell 4.2, veröffentlicht am 29. April 2026) übernimmt die VM-Sicherung. Er sichert inkrementell und dedupliziert, und mit installiertem Gast-Agent friert Proxmox beim Backup das Dateisystem des Gastes ein — unter Windows laut Proxmox-Wiki über den Volume Shadow Copy Service. Das liefert dateisystem- und datenbankkonsistente Sicherungen der ganzen VM. Was es nicht liefert: das gezielte Zurückspielen einer einzelnen SQL-Datenbank auf einen Zeitpunkt, wie DPM es für SQL Server vorsah. Wer das braucht, sichert die Datenbank zusätzlich mit Bordmitteln von SQL Server in eine Freigabe, die dann mitgesichert wird. Einen Vergleich mit anderen Sicherungsprodukten zieht der Beitrag Veeam vs. Proxmox Backup Server.

Für Hyper-V Replica gibt es einen Nachfolger mit Einschränkung: Die Speicherreplikation von Proxmox VE überträgt Gastplatten in festen Abständen auf einen anderen Knoten — laut Dokumentation standardmäßig alle 15 Minuten, minimal jede Minute. Sie funktioniert aber nur auf lokalem ZFS, und zwischen letztem Abgleich und Ausfall gehen Daten verloren. Für das RPO bedeutet das: Es liegt bei der gewählten Taktung, nicht bei null.

Für die Überwachung schreibt Proxmox VE Metriken an einen externen Metrikserver; daraus baut man mit Prometheus und Grafana Dashboards und Alarme. Wie das im Cluster aussieht, beschreibt der Beitrag Proxmox Monitoring mit Prometheus, Grafana und PDM. Das ersetzt SCOM für die Infrastruktur, nicht für die Anwendungen in den Gästen.

/06Migrationsweg: eine Hyper-V-VM nach Proxmox umziehen

Der Import-Assistent der Proxmox-Oberfläche hilft hier nicht: Er unterstützt laut Proxmox-Wiki VMware ESXi sowie OVA- und OVF-Dateien als Quelle, Hyper-V nicht. Der Weg führt über die Kommandozeile, und er ist kurz, weil qm disk import jedes Plattenformat liest, das qemu-img versteht — darunter VHDX. So läuft der Umzug einer Generation-2-VM mit Windows Server ab:

Schritt 1: Gast vorbereiten, solange er noch unter Hyper-V läuft

Installieren Sie die VirtIO-Treiber aus dem virtio-win-Paket im laufenden Gast (virtio-win-gt-x64.msi). Das Proxmox-Wiki führt mit Stand 10.09.2026 Version 0.1.271 als stabil und rät von der neueren 0.1.302 für Produktivsysteme noch ab. Entfernen Sie die Gastwerkzeuge des alten Hypervisors, soweit sie separat installiert sind, und notieren Sie die IP-Konfiguration: Die Netzwerkkarte bekommt nach dem Umzug einen neuen Namen, und eine statische Adresse auf dem alten, unsichtbaren Adapter führt zu Konfliktmeldungen. Dann fahren Sie den Gast herunter — sauber, nicht über den Hyper-V-Zustand „Gespeichert".

Schritt 2: VHDX bereitstellen und VM anlegen

Kopieren Sie die VHDX-Datei auf einen Speicher, den der Proxmox-Knoten lesen kann, etwa eine NFS-Freigabe oder ein lokales Verzeichnis. Dann legen Sie die VM an — mit UEFI (OVMF), weil die Quelle eine Generation-2-VM ist:

root@pve01:~# qm create 120 --name app01 --ostype win10 --machine q35 \
    --bios ovmf --efidisk0 local-zfs:1,efitype=4m,pre-enrolled-keys=1 \
    --cores 4 --memory 8192 --scsihw virtio-scsi-single \
    --net0 virtio,bridge=vmbr0 --agent enabled=1

root@pve01:~# qm disk import 120 /mnt/hv/app01.vhdx local-zfs
...
Successfully imported disk as 'unused0:local-zfs:vm-120-disk-1'

# Erster Start über SATA, weil Windows VirtIO SCSI noch nicht bootet
root@pve01:~# qm set 120 --sata0 local-zfs:vm-120-disk-1 --boot order=sata0
root@pve01:~# qm start 120

Der Typ win10 steht in Proxmox für Windows 10, 2016 und 2019 als Gastsystem. Eine Generation-1-VM legen Sie ohne --bios ovmf und ohne EFI-Platte an; dann startet sie mit SeaBIOS, dem Standard. Die Proxmox-Dokumentation ist an dieser Stelle eindeutig: BIOS-Gäste brauchen SeaBIOS, UEFI-Gäste OVMF. Wer das verwechselt, sieht einen Bootbildschirm ohne Betriebssystem.

Schritt 3: auf VirtIO SCSI umstellen

Läuft der Gast über SATA, prüfen Sie im Geräte-Manager, dass der VirtIO-SCSI-Treiber geladen ist. Bewährt hat sich, vorher eine kleine zusätzliche Platte am SCSI-Controller anzuhängen, damit Windows den Treiber sicher aktiviert. Danach fahren Sie den Gast herunter und hängen die Systemplatte um:

root@pve01:~# qm set 120 --delete sata0
root@pve01:~# qm set 120 --scsi0 local-zfs:vm-120-disk-1,discard=on \
    --boot order=scsi0
root@pve01:~# qm start 120
root@pve01:~# qm guest cmd 120 ping && echo "Gast-Agent antwortet"

Antwortet der Gast-Agent, ist die Grundlage für konsistente Sicherungen gelegt. Erst jetzt nehmen wir die VM in den Backup-Plan auf, testen eine Wiederherstellung und schalten die alte VM unter Hyper-V endgültig ab. Die alte VHDX bleibt bis zur Abnahme liegen: Sie ist der Rückweg, falls im Fachbereich etwas auffällt, das der Funktionstest nicht abgedeckt hat.

/07Wo es hakt: Grenzen und Stolpersteine

vTPM und BitLocker. Generation-2-VMs mit aktiviertem virtuellem TPM und BitLocker im Gast lassen sich nicht einfach umhängen: Der Schlüsselschutz im vTPM zieht nicht mit. Halten Sie vor dem Umzug den Wiederherstellungsschlüssel bereit oder setzen Sie BitLocker im Gast vorübergehend aus. Proxmox kann selbst ein vTPM bereitstellen; es ist aber ein neues, kein übernommenes.

Secure Boot. Der Schalter pre-enrolled-keys=1 legt die Microsoft-Standardschlüssel in die EFI-Platte. Damit startet ein mit Secure Boot installierter Windows Server wie vorher. Linux-Gäste mit eigenem Bootloader testen Sie trotzdem einzeln, bevor Sie sie in Serie umziehen.

Gesicherter Zustand und Prüfpunkte. Eine VM im Zustand „Gespeichert" oder mit offenen Prüfpunkten (Checkpoints) hat ihre Daten über mehrere Dateien verteilt. Die Basis-VHDX allein ist dann nicht der aktuelle Stand. Prüfpunkte vor dem Umzug zusammenführen, VM sauber herunterfahren — sonst importieren Sie einen veralteten Stand.

Lizenzen der Gäste. Der Hypervisor kostet nichts mehr, die Windows-Gäste weiterhin. Wer bisher Windows Server Datacenter auf dem Hyper-V-Host lizenziert hat, um beliebig viele Gäste abzudecken, muss diese Rechnung für die Proxmox-Hosts neu aufmachen, denn die Lizenz hängt an der physischen Hardware, nicht am Hypervisor. Die Mindestmengen je Server nennt der Bestandsartikel zu Windows Server 2016.

Ein Werkzeug weniger, eine Disziplin mehr. SCOM hat vieles gemeldet, ohne dass jemand die Schwellwerte je angefasst hat. Nach dem Wechsel gibt es diese Vorbelegung nicht. Wer Monitoring nur nachbaut, was die Hypervisor-Metriken hergeben, merkt den Ausfall einer Anwendung im Gast erst, wenn der Fachbereich anruft. Das ist kein Proxmox-Problem, aber ein typischer Folgefehler solcher Umstiege.

Physische Windows-Server mit DPM-Agent. Sie fallen aus dem Raster: Proxmox Backup Server hat keinen Windows-Client, der Roadmap-Eintrag „Backup clients for other operating systems" ist ein Vorhaben ohne Datum. Für diese Maschinen braucht es entweder eine Virtualisierung im Zuge des Umzugs oder ein separates Sicherungsprodukt.

/08Wenn der Januar nicht reicht: die Übergangsordnung

Vom Erscheinen dieses Beitrags bis zum 11. Januar 2027 bleiben gut neun Wochen, darin die Feiertage. Für eine Handvoll VMs reicht das. Für eine Umgebung mit mehreren Hosts, DPM-Sicherung und SCOM-Überwachung reicht es nicht vollständig, und das sollte man vor dem Projektstart sagen, nicht im Dezember. Die vernünftige Antwort ist eine Reihenfolge nach Risiko statt nach Bequemlichkeit:

• Zuerst die Sicherung. Ein Backup-Werkzeug ohne Herstellerpflege ist das größere Risiko als ein Hypervisor ohne Pflege, weil es im Ernstfall funktionieren muss. Proxmox Backup Server lässt sich parallel aufbauen und für die ersten migrierten VMs nutzen, während DPM den Rest weiter sichert.
• Dann die Hosts, die aus dem Internet erreichbare Dienste tragen. Eine VM mit Webdienst oder VPN-Endpunkt auf einem ungepflegten Hypervisor ist ein anderes Risiko als ein interner Lizenzserver.
• Zuletzt die Verwaltung. VMM ohne Support ist lästig, aber keine offene Angriffsfläche, solange die Konsole nicht aus dem Netz erreichbar ist. Er kann bis zum Abschluss der Migration weiterlaufen.

Was im Januar noch auf Hyper-V Server 2016 läuft, gehört in ein eigenes Netzsegment, mit eingespieltem Januar-Update und einem festen Abschaltdatum im Runbook. Das ist keine Dauerlösung, sondern eine dokumentierte Ausnahme mit Ablaufdatum — genau so lässt sie sich auch gegenüber einem Prüfer oder einer Cyberversicherung vertreten.

Wichtig ist der Unterschied zwischen „läuft weiter" und „ist abgesichert". Am 13. Januar fällt kein Host aus, keine VM bleibt stehen. Aber jede Sicherheitslücke, die ab Februar im Hypervisor bekannt wird, bleibt offen — und Hypervisor-Lücken sind die, bei denen ein Angreifer aus einem Gast heraus alle anderen erreicht. Das Patch-Management hat für diese Hosts ab Februar schlicht nichts mehr zu tun, und genau das sollte im Bericht auffallen.

/09Wann der Wechsel lohnt — und wann Hyper-V bleiben sollte

Ehrlich: Nicht jede Umgebung mit Hyper-V Server 2016 gehört auf Proxmox. Die Entscheidung hängt weniger an der Technik als an dem, was ohnehin bezahlt wird.

Wann das Thema für Sie irrelevant ist: Wenn Hyper-V als Rolle auf Windows Server 2016 läuft, System Center nie eingesetzt wurde und die Hosts ohnehin auf eine neue Windows-Server-Version gehoben werden, betrifft Sie nur das Windows-Server-Ende — dafür reicht der Bestandsartikel. Ebenso, wenn die Gäste schon unter VMware oder in einer Cloud liegen und der Hyper-V-Host nur noch als Testsystem dient: Abschalten ist dann die ganze Migration.

Für die übrigen Fälle zeigt die Erfahrung aus unseren Umstiegen ein Muster: Der Hypervisor selbst ist selten das Problem. Die Arbeit steckt in der Sicherung, im Monitoring und in den drei, vier Altanwendungen, die niemand mehr ganz versteht. HostSpezial betreibt Proxmox-Cluster für Kunden im Rechenzentrum SÜC Coburg mit Ausweichstandort Neustadt; wer den Betrieb danach nicht selbst übernehmen will, findet unter Virtualisierung das Betriebsmodell dazu.

/10Häufige Fragen