WSUS wird nicht mehr weiterentwickelt: wie du Server künftig patchst

Was nicht mehr weiterentwickelt bei Microsoft tatsächlich bedeutet

Microsoft führt in einer eigenen Übersicht zwei getrennte Listen: Funktionen, die nicht mehr weiterentwickelt werden, und Funktionen, die entfernt wurden. Zur ersten Liste steht dort die Definition, die den Unterschied trägt: Eine solche Komponente wird weiterhin in Windows Server ausgeliefert, für Produktivbereitstellungen unterstützt und erhält Sicherheits- und Qualitätsupdates entlang des Produktlebenszyklus. Sie kann in künftigen Versionen entfernt werden, ist es aber nicht.

WSUS steht in dieser ersten Liste, und zwar mit dem Zusatz, dass alle vorhandenen Funktionen und Inhalte weiterhin für Bereitstellungen zur Verfügung stehen. Auch in der Rollenübersicht selbst hält Microsoft fest, dass WSUS abgekündigt ist und keine neuen Funktionen mehr bekommt, dass es aber weiterhin für Produktivbereitstellungen unterstützt wird. Die Rolle ist in Windows Server 2025 in allen Editionen vorhanden und lässt sich installieren wie zuvor.

Wer diese Sätze im Haus zitiert, nimmt der Diskussion die Panik und behält trotzdem das Argument. Denn die praktische Folge der Einstufung ist real: Eine Komponente ohne Weiterentwicklung bekommt keine Antworten auf neue Anforderungen mehr, und alles, was in einer Umgebung darauf aufsetzt, wächst in eine Richtung, aus der es später zurückgebaut werden muss. Der richtige Umgang damit ist eine eigene Frist mit eigener Begründung, nicht ein erfundener Stichtag.

Die Wege für Server, nebeneinandergestellt

Der Azure Update Manager ist der Weg, den Microsoft für Server in den Vordergrund stellt. Er überwacht und verteilt Updates für Windows- und Linux-Server in Azure, im eigenen Rechenzentrum und in anderen Clouds, wobei alles außerhalb von Azure über Azure Arc angebunden wird. Er kann Updates sofort ausbringen oder in festgelegten Wartungsfenstern planen, führt regelmäßige Bewertungen im Abstand von vierundzwanzig Stunden durch, gruppiert Maschinen dynamisch nach Kriterien und regelt Berechtigungen über die rollenbasierte Zugriffssteuerung von Azure. Bemerkenswert für die Umstellung: Er kann auch Updates ausbringen, die auf einem WSUS-Server veröffentlicht sind.

Configuration Manager bleibt für Häuser, die es einsetzen, der umfassendste Weg, weil dieselbe Umgebung neben Updates auch Softwareverteilung, Betriebssystembereitstellung und Bestandsführung abdeckt. Wichtig für die Erwartungshaltung ist, dass der Softwareupdatepunkt WSUS voraussetzt. Wer also von WSUS weg will und dabei an Configuration Manager denkt, verlagert die Steuerung, nicht die Grundlage. Für die Beurteilung heißt das: Die Frage lautet nicht, ob Configuration Manager WSUS ersetzt, sondern ob es die Steuerung so viel besser macht, dass sich der Betrieb der Umgebung lohnt.

WSUS selbst bleibt der Weg für alles, was keine Verbindung nach außen hat oder haben darf. Für diese Zonen ist der sinnvolle nächste Schritt nicht der Ersatz, sondern die Ertüchtigung: Datenbank auf einen regulären SQL Server, regelmäßige Bereinigung, verschlüsselte Übertragung und ein sauber dokumentierter Freigabeprozess. Microsoft empfiehlt für den Verteildienst ausdrücklich die Absicherung über TLS, und seit den Änderungen von September 2020 verhalten sich Server ohne diese Absicherung beim Abruf über einen Benutzerproxy zurückhaltender.

Für Clients und Microsoft-365-Anwendungen liegt der Weg woanders. Windows Autopatch automatisiert Updates für Windows, Microsoft 365 Apps for enterprise, Microsoft Edge und Microsoft Teams, arbeitet mit gestaffelten Bereitstellungsringen und wird über das Intune Admin Center gesteuert. Für den Serverbetrieb ist das kein Kandidat, für die Clientseite dagegen die naheliegende Antwort. Halt diese beiden Vorhaben im Plan getrennt, auch wenn dieselben Leute daran arbeiten.

Was der Wechsel an Anbindung und an Geld kostet

Die Anbindung ist der eigentliche Aufwandstreiber. Azure Arc verlangt einen Agenten auf jeder Maschine und einen Pfad nach außen, wobei Microsoft mehrere Varianten unterstützt: einen öffentlichen Endpunkt, einen Proxy, ein Azure Arc Gateway oder einen privaten Endpunkt. Zusätzliche Endpunkte müssen für die Verwaltungsleistungen nicht freigegeben werden. Unterstützt werden Maschinen ab Windows Server 2012 in den Editionen Standard und Datacenter, in Umgebungen mit Hyper-V, VMware, System Center Virtual Machine Manager, Azure Local, Azure VMware Solution und auf physischer Hardware.

Die Kostenfrage hängt an der Lizenzlage. Microsoft fasst mehrere Leistungen unter dem Namen Windows Server Management enabled by Azure Arc zusammen, darunter den Azure Update Manager, und stellt sie ohne zusätzliche Kosten bereit, wenn die Windows-Server-Lizenzen über aktive Software Assurance oder aktive Abonnementlizenzen verfügen. Der Haken ist die Formalie: Die Berechtigung muss ausdrücklich bestätigt werden, im Portal oder per PowerShell, und sie leitet sich nicht aus der bloßen Anbindung an Azure Arc ab. Wer nicht bestätigt und nicht am nutzungsabhängigen Modell teilnimmt, kann den Azure Update Manager auch einzeln erwerben.

Der dritte Kostenpunkt ist der Prozess selbst. Eine Umstellung, die den bisherigen Freigabeprozess eins zu eins nachbaut, wird teuer und unbefriedigend, weil beide Werkzeuge unterschiedlich denken. WSUS-Umgebungen arbeiten mit Gruppen und Freigaben je Update, Azure Update Manager mit Wartungsfenstern, dynamisch gebildeten Gruppen und Bewertungsläufen. Nutz die Umstellung, um die Frage neu zu stellen, welche Freigabe im Haus tatsächlich eine Entscheidung ist und welche nur ein Häkchen, das jemand jeden Monat setzt.

Hotpatch: der Grund, warum sich der Weg über Arc auch technisch rechnet

Hotpatching installiert Sicherheitsupdates, indem es den Code laufender Prozesse im Speicher ändert, ohne dass die Maschine neu startet. Microsoft nennt dafür mehrere Vorteile: weniger Binärdateien und damit schnellere Installation bei geringerem Verbrauch an Speicherplatz und Rechenzeit, weniger Auswirkung auf die Last und ein kürzeres Zeitfenster, in dem ein System ungeschützt ist.

Der Ablauf ist an eine Basis gebunden. Hotpatch setzt zunächst auf dem aktuellen kumulativen Update auf, und diese Basis wird alle drei Monate erneuert. Zwischen zwei Basen liegen zwei Monate mit Hotpatch-Veröffentlichungen. Ein geplantes Jahr kommt damit auf vier Basen und acht Hotpatch-Veröffentlichungen. Die Basen erfordern einen Neustart, die Hotpatch-Veröffentlichungen nicht. Kommt ein wichtiges Update dazwischen, das sich nicht als Hotpatch ausliefern lässt, ersetzt eine ungeplante Basis die Veröffentlichung dieses Monats, und dann steht ebenfalls ein Neustart an.

Wichtig für die Erwartung: Hotpatch deckt Sicherheitsupdates für Windows ab und hält dabei inhaltlich mit dem regulären Kanal Schritt. Nicht enthalten sind Updates ohne Sicherheitsbezug, Aktualisierungen des .NET Framework und alles, was nicht von Windows selbst kommt, also insbesondere Treiber und Firmware. Für diese Anteile bleibt ein Neustartfenster nötig. Ein automatisches Zurückrollen gibt es nicht: Wenn nach einem Update etwas nicht stimmt, deinstallierst du es und installierst die letzte funktionierende Basis, und dafür muss die Maschine neu starten.

Für Arc-verbundene Maschinen mit Windows Server 2025 stellt Microsoft Hotpatch ohne zusätzliche Kosten bereit, und zwar sowohl für die Standard- als auch für die Datacenter-Edition. Wer also ohnehin über die Anbindung an Azure Arc nachdenkt, sollte diesen Punkt in die Rechnung nehmen, denn eingesparte Neustartfenster sind in vielen Häusern die knappere Währung als Lizenzkosten.

Die Umstellung ohne Lücke im Patchstand

Der gefährlichste Moment einer Umstellung ist der Übergang, in dem das alte Werkzeug schon abgeschaltet und das neue noch nicht vollständig zuständig ist. Vermeide diesen Moment, indem du beide Wege für eine Zeit nebeneinander betreibst und die Zuständigkeit je Server ausdrücklich zuweist, statt sie aus der Konfiguration abzuleiten. Ein Server, für den beide Wege sich zuständig fühlen, ist harmlos, ein Server, für den sich keiner zuständig fühlt, ist der Befund im nächsten Prüfbericht.

Bau die Umstellung entlang von Zonen und nicht entlang von Systemklassen. Nimm zuerst eine Zone, die vollständig angebunden ist und in der ein Ausfall vertretbar wäre, und führ dort den kompletten Kreis durch: Anbindung, Bewertung, ein geplantes Wartungsfenster, ein Bericht über den erreichten Stand. Erst wenn dieser Kreis einmal ohne Handarbeit durchgelaufen ist, lohnt sich die zweite Zone. Wer parallel in fünf Zonen anfängt, hat fünf halbfertige Anbindungen und keinen belastbaren Bericht.

Halt während der Umstellung eine gemeinsame Kennzahl über beide Wege hinweg, und leite sie nicht aus dem jeweiligen Werkzeug ab. Die Frage lautet: Wie viele Server haben die Sicherheitsupdates des letzten Monats installiert, und welche nicht? Diese Zahl muss unabhängig davon ermittelbar sein, über welchen Weg der jeweilige Server versorgt wird, sonst misst du Werkzeuge statt Zustände. Und dokumentier die Zonen ohne Anbindung ausdrücklich als dauerhaften Sonderfall mit eigenem Verfahren, statt sie als Restarbeit zu führen, die irgendwann verschwindet.