Windows Server: Hotpatch und clusterfähiges Aktualisieren

Server geraten vor allem aus einem Grund bei Patches in Rückstand: Ein Neustart kostet etwas. Ein monatlicher Neustart einer Datenbank, eines Dateiservers oder einer Fachanwendung braucht ein Fenster, einen Verantwortlichen und einen Rollback-Plan, und jeden Monat hat jemand einen Grund, ihn auszulassen. Der Grundlagenartikel zum Patching setzt Ziele für Server; dieser Leitfaden behandelt die beiden Windows Server-Funktionen, die diese Ziele realistisch machen, indem sie Ausfallzeiten verringern oder verbergen: Hotpatch und clusterfähiges Aktualisieren (Cluster-Aware Updating, CAU).

Wie Hotpatch funktioniert

Ein Hotpatch aktualisiert Code im Arbeitsspeicher für laufende Prozesse und auf dem Datenträger für den nächsten Start, ohne Neustart. Microsoft liefert Hotpatches in einem Quartalszyklus aus:

Ein per Hotpatch aktualisierter Server ist sicherheitstechnisch vollständig gepatcht, nicht „teilweise“. Der Kompromiss: Nicht sicherheitsbezogene Korrekturen warten auf die nächste Baseline, und alles außerhalb des kumulativen Betriebssystem-Updates (Treiber, Firmware, .NET, Drittanbietersoftware) folgt weiterhin dem normalen Prozess und kann den Server neu starten.

Schritt 1: Berechtigung prüfen

Hotpatch hängt von Edition, Standort und Sicherheitsfunktionen ab:

• Windows Server 2022 oder 2025 Datacenter: Azure Edition auf Azure-VMs oder Azure Local. Hotpatch ist enthalten und wird über Azure Update Manager verwaltet.
• Windows Server 2025 Standard oder Datacenter (Build 26100.1742 oder neuer, Desktopdarstellung oder Server Core) auf physischen oder virtuellen Rechnern außerhalb von Azure, mit Azure Arc verbunden, mit aktiviertem Hotpatch auf der Arc-Ressource. Seit Mai 2026 kostet das nichts extra; zuvor war es ein kostenpflichtiges Abonnement pro Kern.
• Virtualisierungsbasierte Sicherheit muss laufen, der Rechner braucht also UEFI mit Secure Boot (unter Hyper-V eine VM der Generation 2). Hotpatch nutzt VBS, um den Patchvorgang zu schützen, was es auch zu einem guten Begleiter von VBS und Speicherintegrität macht.
• Der Server muss auf der aktuellen Baseline sein; ein Rechner, der eine Baseline verpasst, kann die folgenden Hotpatches nicht aufnehmen und fällt auf vollständige kumulative Updates zurück, bis er aufgeholt hat.

Windows 11 Enterprise 24H2 und neuer kann Hotpatches ebenfalls über Windows Autopatch in Intune erhalten. Dieses Clientprogramm hat eigene Lizenz- und Gerätevoraussetzungen, getrennt vom hier beschriebenen Servermodell.

VBS auf einem Kandidatenserver prüfen:

Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus, SecurityServicesRunning
# VirtualizationBasedSecurityStatus = 2 bedeutet, dass VBS läuft

Ist VBS deaktiviert, aktivieren Sie es über Computer Configuration > Policies > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security, testen die Workload (manche älteren Treiber und hypervisorabhängigen Werkzeuge sträuben sich) und starten dann neu.

Schritt 2: Server registrieren

Azure-VMs mit Azure Edition: Wählen Sie ein Hotpatch-fähiges Image und verwenden Sie in den Patch-Einstellungen der VM das von Azure orchestrierte Patching mit aktiviertem Hotpatch. Azure Update Manager plant dann Baselines und Hotpatches für Sie.

Mit Arc verbundenes Windows Server 2025: Binden Sie den Rechner mit dem Connected Machine Agent an Azure Arc an, öffnen Sie dann im Azure-Portal Azure Arc > Machines, wählen Sie den Rechner, dann Hotpatch und anschließend Confirm. Die Änderung greift nach etwa 10 Minuten (das Portal prüft, ob VBS läuft, und schlägt sonst fehl). Der Server erhält dann ab dem nächsten Hotpatch-Monat Hotpatches, sofern er auf der aktuellen Baseline ist. Planen Sie die Baseline-Neustarts mit Azure Update Manager oder Ihrem bestehenden Werkzeug.

Das Onboarding in Arc gibt einem lokalen Server eine Azure-Identität. Behandeln Sie den Dienstprinzipal für das Onboarding und die Berechtigungen auf der Arc-Ressource als privilegiert: Eine Rolle, die auf Arc-Rechnern Befehle ausführen oder Erweiterungen installieren kann, ist faktisch administrativ auf diesen Servern. Begrenzen Sie Azure RBAC mit derselben Sorgfalt wie beim Admin-Tiering und binden Sie Domänencontroller nie in ein Abonnement ein, das von Admins niedrigerer Tiers verwaltet wird.

Schritt 3: den Patchkalender um die Baselines planen

Mit Hotpatch ändert sich die Form des Monatsplans:

• Baseline-Monate: derselbe Prozess wie heute. Patchgruppen, Wartungsfenster, Anwendungsverantwortliche in Bereitschaft. Planen Sie diese Fenster ein Jahr im Voraus, da die Monate feststehen.
• Hotpatch-Monate: innerhalb weniger Tage nach dem Patch Tuesday installieren, auf allen berechtigten Servern gleichzeitig, sofern Ihre Tests es zulassen, da kein Neustart koordiniert werden muss. Halten Sie eine kleine Pilotgruppe ein bis zwei Tage voraus.
• Ungeplante Baselines: Halten Sie ein Verfahren für Notfallfenster bereit, damit eine Baseline außerhalb des Zyklus nicht bis zum nächsten Quartal wartet.

Trennen Sie im Reporting für Hotpatch registrierte Server von den übrigen. Ein Server, der stillschweigend aus dem Hotpatch-Pfad gefallen ist und nun jeden Monat einen Neustart braucht, wird leicht übersehen.

Schritt 4: clusterfähiges Aktualisieren für Clusterrollen

Für Failovercluster (Hyper-V-Hosts, Dateiserver, SQL Server-Failoverclusterinstanzen) automatisiert CAU das rollierende Muster: einen Knoten entleeren, seine Rollen verschieben, Updates installieren, neu starten, fortsetzen, zum nächsten Knoten wechseln. Es funktioniert mit oder ohne Hotpatch und ist Teil des Features Failoverclustering (Modul ClusterAwareUpdating).

Prüfen Sie zuerst die Bereitschaft und fügen Sie dann die CAU-Clusterrolle im Selbstaktualisierungsmodus hinzu:

Test-CauSetup -ClusterName FS-CLU01

Add-CauClusterRole -ClusterName FS-CLU01 `
  -DaysOfWeek Tuesday -WeeksOfMonth 3 `
  -MaxFailedNodes 0 -MaxRetriesPerNode 2 -RequireAllNodesOnline `
  -EnableFirewallRules -Force

Wichtige Parameter:

• -RequireAllNodesOnline verweigert den Start, wenn ein Knoten bereits ausgefallen ist, sodass ein Update-Lauf einen beeinträchtigten Cluster nie weiter schwächt.
• -MaxFailedNodes 0 stoppt den Lauf beim ersten fehlgeschlagenen Knoten, statt weiterzumachen.
• -PreUpdateScript und -PostUpdateScript führen Ihre eigenen Prüfungen aus, zum Beispiel die Bestätigung, dass eine SQL-Verfügbarkeitsgruppe fehlerfrei ist, bevor der nächste Knoten an die Reihe kommt.
• Das Standard-Plug-in Microsoft.WindowsUpdatePlugin verwendet den Windows Update-Agent und die Quelle, für die die Knoten konfiguriert sind (Windows Update, WSUS). Microsoft.HotfixPlugin installiert Pakete von einer Dateifreigabe, die Sie kontrollieren.

Für einen einmaligen Lauf bei Bedarf, von einem Verwaltungsrechner statt von einem Clusterknoten:

Invoke-CauScan -ClusterName FS-CLU01 -CauPluginName Microsoft.WindowsUpdatePlugin
Invoke-CauRun  -ClusterName FS-CLU01 -CauPluginName Microsoft.WindowsUpdatePlugin `
  -MaxFailedNodes 0 -RequireAllNodesOnline -Force

Das CAU-Computerobjekt und das Konto, das den Remoteaktualisierungsmodus ausführt, haben administrativen Zugriff auf jeden Knoten. Ordnen Sie den Cluster und seinen Verwaltungsrechner dem richtigen Tier zu und begrenzen Sie die Firewallregeln von CAU auf das Managementnetz (siehe Firewall-Härtung).

Azure Local-Cluster verwenden ihren eigenen Lifecycle Manager für Betriebssystem-, Treiber- und Firmware-Updates; folgen Sie dort diesem Prozess, statt CAU direkt zu konfigurieren.

Schritt 5: den Rest des Servers aktuell halten

Hotpatch und CAU kümmern sich um das kumulative Betriebssystem-Update. Die anderen Schichten brauchen weiterhin ihren eigenen Prozess:

• Firmware und Treiber: Herstellerwerkzeuge (zum Beispiel die Update-Suite des Serverherstellers) im Rhythmus der Baseline-Monate, damit ihre Neustarts mit dem ohnehin anstehenden zusammenfallen. Bei mit BitLocker geschützten Servern muss der Schutz ggf. für einen Neustart angehalten werden.
• .NET und andere Microsoft-Produkte: Microsoft Update in Ihrer Update-Quelle zulassen; .NET-Updates erfordern meist einen Neustart der nutzenden Anwendungen, manchmal des Servers.
• Serverrollen und Anwendungen: Kumulative Updates für SQL Server, Exchange, IIS-Module und Drittanbieter-Agenten folgen den Zeitplänen der Hersteller. Richten Sie sie, wo möglich, an den Baseline-Monaten aus.
• Hyper-V-Hosts: Gäste profitieren nur von Hotpatch, wenn das Gastbetriebssystem berechtigt ist; der Neustart des Hosts verschiebt oder pausiert weiterhin VMs, und genau hier hilft CAU.

Ziel ist ein geplanter Neustart pro Quartal, der alles aufnimmt, statt mehrerer ungeplanter.

Überprüfung

Prüfen Sie auf einem Server die Build-Revision und den Update-Verlauf:

$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
'{0}.{1}' -f $cv.CurrentBuild, $cv.UBR
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5 HotFixID, Description, InstalledOn
(Get-CimInstance Win32_OperatingSystem).LastBootUpTime

Ein per Hotpatch aktualisierter Server zeigt eine neue Build-Revision, während LastBootUpTime bei der letzten Baseline bleibt. Vergleichen Sie die Revision mit der in Microsofts Versionshinweisen für den Hotpatch des Monats angegebenen. Installationsergebnisse stehen im System-Log unter Microsoft-Windows-WindowsUpdateClient (Ereignis 19 Erfolg, 20 Fehler). In Azure Update Manager zeigt der Update-Verlauf des Rechners Hotpatch- und Baseline-Installationen getrennt an.

Für CAU prüfen Sie den letzten Lauf und die Ereignisprotokolle:

Get-CauReport -ClusterName FS-CLU01 -Last -Detailed
Get-WinEvent -LogName 'Microsoft-Windows-ClusterAwareUpdating/Admin' -MaxEvents 20

Was kaputtgeht

• VBS durch einen Treiber oder eine BIOS-Änderung deaktiviert. Der Server ist dann stillschweigend nicht mehr für Hotpatch berechtigt. Überwachen Sie VirtualizationBasedSecurityStatus.
• Verpasste Baseline. Ein Server, der den Quartalsneustart auslässt, fällt auf vollständige kumulative Updates zurück. Behandeln Sie Baseline-Fenster als verbindlich.
• Manuelle Installation kumulativer Updates. Ein eigenständiges Paket außerhalb der Reihenfolge kann einen Rechner aus dem Hotpatch-Pfad werfen; überlassen Sie die Installation dem Orchestrierungswerkzeug.
• CAU-Läufe, die hängen bleiben, weil ein Knoten sich nicht entleeren lässt, oft wegen einer Rolle mit bevorzugten Besitzern oder einer VM, die sich nicht live migrieren lässt. Beheben Sie das Integritätsproblem des Clusters; erhöhen Sie nicht MaxFailedNodes.
• Cluster, die sowohl von CAU als auch von einem anderen Werkzeug gepatcht werden. Zwei Orchestratoren starten Knoten unabhängig voneinander neu und können das Quorum zu Fall bringen. Nehmen Sie Clusterknoten aus clientartigen Ringrichtlinien wie den Windows Update-Richtlinien aus.

Checkliste

• Serverbestand klassifiziert: Azure Edition, mit Arc verbundenes 2025, nicht berechtigt
• VBS läuft auf Hotpatch-Kandidaten und wird überwacht
• Onboarding-Identität und RBAC für Arc als privilegierter Zugriff eingegrenzt
• Baseline-Fenster für Januar, April, Juli und Oktober geplant
• Hotpatch-Monate innerhalb weniger Tage installiert, Pilotgruppe zuerst
• Cluster per CAU mit RequireAllNodesOnline und MaxFailedNodes 0 aktualisiert
• Integritätsskripte vor und nach dem Update für kritische Clusterrollen
• Reporting trennt per Hotpatch aktualisierte, nur per Baseline aktualisierte und nicht konforme Server

Hotpatch und CAU entkräften für die meisten Server den Einwand gegen Neustarts. Der Rest des Prozesses, von Ringen bis zu Drittanbietersoftware, steht im Bereich Patches und Updates.