Mit Azure Arc bekommt Windows Server 2025 Hotpatches ohne Neustart

Wer in den letzten Tagen mit Windows Server 2025 Standard oder Datacenter zu tun hatte, ist am Hotpatching außerhalb von Azure kaum vorbeigekommen. Kritische Updates ohne Neustart einzuspielen, blieb lange den Azure-VMs mit Windows Server Azure Edition vorbehalten. Mit Windows Server 2025 und Azure Arc funktioniert Hotpatching jetzt auch auf On-Premises-Servern, allerdings als kostenpflichtige Zusatzoption, für die der Server per Azure Arc angebunden sein muss. In vielen Umgebungen, die ich betreue, wird bereits intensiv über die Vorteile gesprochen. Es gibt weniger Wartungsfenster, die Verfügbarkeit steigt, und die leidigen Diskussionen darüber, wann der nächste Reboot ansteht, hören endlich auf.

Vor dem Enrollment braucht der Server eine Arc-Anbindung und aktives VBS

Ein paar Voraussetzungen müssen natürlich erfüllt sein. Als Erstes binden Sie den betreffenden Windows Server 2025 (Standard oder Datacenter, eine Azure Edition braucht es nicht) über Azure Arc an. Das erledigt man im Azure-Portal oder mit dem „azcmagent“-Tool. Technisch entscheidend ist außerdem Virtualization-Based Security (VBS), denn ohne aktiviertes VBS funktioniert Hotpatching nicht. Am schnellsten prüfe ich die VBS-Konfiguration per PowerShell direkt auf dem Zielsystem (mindestens PowerShell 5.1):

Get-CimInstance -ClassName Win32_DeviceGuard

Die Eigenschaft „SecurityServicesConfigured“ sollte mindestens den Wert „1“ (VBS aktiviert) enthalten. Fehlt er, muss VBS je nach Hardware im UEFI/BIOS und in Windows eingeschaltet werden. Viele Unternehmen setzen das ohnehin als empfohlene Härtungsmaßnahme um.

Stimmen die Voraussetzungen, folgt das Enrollment. Unter Azure-Portal → Azure Arc → Maschinen → (gewünschter Server auswählen) → Hotpatch gibt es die neue Option, mit der sich der Server für das Hotpatch-Programm registrieren lässt. Die Aktivierung selbst ist schnell erledigt. Für den produktiven Betrieb rate ich aber dazu, Azure Update Manager einzubinden. Wie das in der Praxis aussieht, beschreibe ich im Artikel Azure Update Manager: Updates zentral und einfach steuern. Anschließend orchestriert Update Manager die Hotpatches wie jedes andere Update und rollt sie in den Wartungsfenstern aus.

Baselines und Hotpatches wechseln sich im Patch-Zyklus ab

Hotpatching läuft anders ab als ein gewöhnliches Windows-Update. Baseline- und Hotpatch-Monate folgen einem festen Rhythmus. Im Baseline-Monat, in der Regel einmal im Quartal, installiert der Server ein vollständiges kumulatives Update, und dafür ist nach wie vor ein Neustart fällig. Die Monate dazwischen heißen „Hotpatch-Monate“. In dieser Zeit kommen die sicherheitskritischen Änderungen als Hotpatches und werden ohne Reboot direkt in die laufenden Prozesse injiziert. Möglich machen das spezielle Windows-Mechanismen, die Code im Arbeitsspeicher austauschen, während das System normal weiterarbeitet.

Im folgenden Diagramm sehen Sie den Ablauf aus Sicht eines per Arc angebundenen Systems mit Windows Server 2025:

flowchart TD
    Start["Arc-Anbindung"] --> VBS["VBS aktiviert"]
    VBS --> Enrollment["Hotpatch-Enrollment Portal"]
    Enrollment --> Baseline["Baseline-Monat: CU, Neustart"]
    Baseline --> Hotpatch["Hotpatch-Monate: Patch ohne Neustart"]
    Hotpatch --> Baseline

Abbildung: Hotpatch-Zyklus für Windows Server 2025 mit Arc-Anbindung

Im Betrieb heißt das: Auch im Hotpatch-Modus muss alle paar Monate ein gezielter Reboot eingeplant werden. Die meisten kritischen Updates kommen aber ohne jede Ausfallzeit auf den Server. Bei Systemen, die rund um die Uhr laufen müssen, ist das ein großer Vorteil.

Azure Update Manager übernimmt inzwischen die Orchestrierung

Azure Update Manager ist mittlerweile die zentrale Stelle für die Patch-Orchestrierung, und zwar in Azure ebenso wie für Server, die über Arc verbunden sind. Verwalten lässt sich alles über Azure-Portal → Update Manager, alternativ per Policy, REST-API oder PowerShell (Azure-Az-Module ab Version 10). Nach dem Enrollment erkennt Update Manager die Hotpatch-Fähigkeit automatisch. Wartungsfenster planen, Updates gezielt auf Servergruppen verteilen, Berichte abrufen: Das alles funktioniert wie gewohnt über Update Manager. Mehr Details zu Update Manager finden Sie hier: https://learn.microsoft.com/en-us/azure/update-manager/overview.

Mein Tipp aus der Praxis:

Wer mit Hotpatch keine bösen Überraschungen erleben will, kündigt die Baseline-Monate rechtzeitig an und plant sie fest in die Orchestrierung ein. Wenn nach drei, vier Monaten dann doch ein Reboot fällig wird, kann niemand eine ungeplante Downtime gebrauchen.

Nicht jeder Workload profitiert gleichermaßen vom Hotpatch-Modell

Der Nutzen hängt stark davon ab, welche Rolle ein Server spielt. Am meisten bringt Hotpatching bei klassischen File- und Printservern, Webservern (IIS), AD-Domain-Controllern, Remote-Desktop-Servern und Systemen, die kritische Dienste mit maximaler Verfügbarkeit bereitstellen. Auch SQL-Server-Instanzen bleiben auf diese Weise länger online. In vielen Projekten erlebe ich allerdings Zurückhaltung, sobald Altlasten, Spezialtreiber oder proprietäre Dienste im Spiel sind. Dann sollten Sie vorher einen Testlauf machen.

Klassische Patch-Compliance und eine Sicherheitsstrategie macht Hotpatching nicht überflüssig. Einerseits werden nicht alle Updates hotpatchfähig sein (vor allem Treiber, Kernel-Komponenten oder tief integrierte Systemtools), andererseits bleibt der Neustart alle paar Monate Pflicht. Wer Hotpatch aktiviert, sollte deshalb weiterhin sauber überwachen und das gewohnte Patch-Reporting beibehalten. Ob Hotpatches tatsächlich angewendet wurden, sehen Sie schnell am Update-Status im Azure-Portal oder über eine gezielte Abfrage im Update Manager. Technische Hintergründe und weitere Details zum Hotpatching hat Microsoft hier zusammengestellt: https://learn.microsoft.com/en-us/windows-server/get-started/hotpatch.

Hotpatch mit Arc bringt Admins einen echten Fortschritt

Mit Hotpatching über Arc für Windows Server 2025 erfüllt Microsoft einen Wunsch, den viele Admins seit Langem äußern: Windows-Server-Updates mit deutlich weniger Downtime, und das auch außerhalb von Azure. Sicher, die Option kostet Geld und löst nicht jedes Problem. Für viele kritische Systeme lohnt sie sich trotzdem spürbar. Wer Arc bisher nicht im Einsatz hat, sollte das Thema spätestens jetzt auf die Roadmap nehmen. Und wie immer gilt: zuerst auf Testsystemen anfangen, dann schrittweise in die Produktion gehen und die Baseline-Termine nie aus den Augen verlieren.