Servicing und Lebenszyklus

Patchen scheitert selten am Installieren. Es scheitert daran, dass drei verschiedene Zustände denselben Namen tragen: installiert, wirksam und freigegeben. Dieses Modul trennt sie und zeigt, warum das übliche Nachweiswerkzeug einen Teil der Updates gar nicht sehen kann, warum ein Aufräumbefehl den Rückweg aus einem schlechten Update dauerhaft schließt, und warum ein Server zu hundert Prozent aktuell gemeldet werden kann, während für seine wichtigste Anwendung nie ein Update synchronisiert wurde.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-03

Drei Zustände, die gern verwechselt werden

Zwischen „das Update ist installiert“ und „der Dienst ist freigegeben“ liegen zwei Grenzen, und beide werden von den üblichen Berichten übersprungen. Ein Patchbericht, der die Zahl erfolgreicher Installationen ausweist, beantwortet keine der drei Fragen, die ein Betrieb tatsächlich hat.

Installiert: Die Dateien liegen im Komponentenspeicher. Der Vorgang hat Erfolg gemeldet.
Wirksam: Der Neustart ist erfolgt, die neuen Binärdateien laufen. Vorher ändert sich am Verhalten nichts.
Freigegeben: Jemand hat geprüft, dass die Anwendung darauf weiterhin das tut, was sie soll.

Die drei Zustände haben verschiedene Nachweise und verschiedene Verantwortliche. Der Rest dieses Moduls handelt davon, wie man sie auseinanderhält — angefangen bei dem Werkzeug, das am häufigsten für den ersten Nachweis benutzt wird und ihn nicht liefern kann.

Die Verwechslung ist keine Nachlässigkeit, sondern eingebaut: Jedes Werkzeug meldet den Zustand, den es selbst herstellen kann, und keines meldet die beiden anderen. Der Update-Mechanismus weiß, ob er Dateien geschrieben hat. Ob jemand neu gestartet hat, weiß der Komponentenspeicher. Ob die Anwendung danach noch funktioniert, weiß nur, wer sie benutzt. Ein Patchbericht, der alle drei Fragen beantworten soll, müsste aus drei Quellen kommen — und tut es fast nie.

Das kumulative Modell

Windows Server bekommt Qualitäts- und Sicherheitskorrekturen als kumulatives Update: Jedes enthält alle Änderungen der vorherigen. Man muss also keine Kette nachinstallieren, sondern nur das jeweils aktuellste — das ist der wesentliche Unterschied zu den Einzel-Hotfixes früherer Zeiten.

Servicing Stack Update (SSU) — Ein Update des Mechanismus, der Updates installiert. Es verbessert die Zuverlässigkeit der Installation selbst — nicht das Betriebssystem, das damit versorgt wird.

Was sich 2021 geändert hatSeit Februar 2021 enthält das kumulative Update den jeweils aktuellen Servicing Stack; es gibt eine einzige kombinierte Nutzlast für Windows Update, WSUS und den Update-Katalog. Wer eine WSUS-gestützte Verwaltung benutzt, wählt und verteilt nur noch das monatliche kumulative Update — der Stack wird automatisch korrekt angewendet. Die alte Regel „erst SSU, dann CU“ ist damit für den Regelfall überholt. Ausnahmen bleiben: In seltenen Fällen erscheint ein vorausgesetztes SSU außer der Reihe, um ein Problem bei der Installation des monatlichen Updates zu beheben; solche Pakete sind als Sicherheitsupdate mit dem Schweregrad kritisch eingestuft.

Ein verwandtes Muster gibt es bei neueren Versionen: Ein kumulatives Update kann ein vorausgesetztes kumulatives Update haben, das zuerst installiert werden muss. Wer Pakete offline mit Dism /Add-Package einspielt, legt in solchen Fällen Ziel- und Voraussetzungspaket gemeinsam in den Quellordner und lässt DISM die Reihenfolge bestimmen, statt sie zu raten.

Ein Nebeneffekt des kumulativen Modells verdient Beachtung: Weil jedes Paket seine Vorgänger enthält, wächst es über die Lebensdauer einer Version. Ein Server, der ein Jahr nicht gepatcht wurde, lädt nicht zwölf mittelgroße Pakete, sondern ein sehr großes — mit entsprechendem Bedarf an Bandbreite, Plattenplatz und Installationszeit im Wartungsfenster. Wer ein lange stehengebliebenes System einplant, plant deshalb nicht die übliche Fensterlänge ein.

`Get-HotFix` ist kein Patchstand

Der übliche Griff zum Nachweis ist Get-HotFix. Das Cmdlet liest die WMI-Klasse Win32_QuickFixEngineering aus — und deren Dokumentation nennt die Einschränkung ausdrücklich.

Was dort nicht auftauchtWin32_QuickFixEngineering liefert ausschließlich Updates, die über Component Based Servicing gekommen sind. Alles, was über den Windows Installer oder über die Update-Website eingespielt wurde, taucht nicht auf. Eine Liste aus Get-HotFix ist damit kein Inventar, sondern ein Ausschnitt — und man sieht ihm nicht an, was fehlt. Für einen Compliance-Nachweis ist das die falsche Quelle, und zwar unabhängig davon, wie plausibel die Ausgabe aussieht.

Dazu kommt eine zweite Schwäche: Weil jedes kumulative Update seine Vorgänger enthält, sagt die schiere Zahl der aufgeführten Einträge nichts über die Aktualität. Zwei Server mit derselben Zahl können Monate auseinanderliegen.

Was als Nachweis trägt

Belastbar ist, was der Servicing-Mechanismus selbst über seinen Zustand sagt. Zwei Quellen reichen für den Alltag.

Dism /Online /Get-Packages /Format:Table: Die installierten Pakete mit ihrem Zustand, direkt aus dem Komponentenspeicher.
Dism /Online /Get-PackageInfo /PackageName:<Name>: Einzelheiten zu einem bestimmten Paket.
Betriebssystemversion und Revision: Die eindeutige Aussage darüber, welcher Stand tatsächlich läuft — vergleichbar zwischen Servern.

Der praktische Unterschied zeigt sich beim Vergleich von zwanzig Servern: Eine Paketliste und eine Versionsnummer lassen sich sortieren und gegeneinanderhalten. Eine Liste von Hotfix-Kennungen unterschiedlicher Herkunft lässt sich das nicht.

Zwei Server, angeblich derselbe Stand

Szenario

Zwei Anwendungsserver sollen identisch gepatcht sein. Get-HotFix liefert auf beiden 41 Einträge, und der Patchbericht weist beide als aktuell aus. Eine Anwendung zeigt trotzdem nur auf einem der beiden ein Fehlverhalten, das laut Hersteller mit einem bestimmten kumulativen Update behoben wurde.

Anforderungen

Die Frage soll ohne Rückfrage beim Hersteller entschieden werden.
Das Ergebnis soll für weitere Server wiederholbar sein.

Schritte

Die Zahl der Einträge verwerfen — sie ist kein Maß, weil kumulative Updates einander enthalten.
Auf beiden Servern die Betriebssystemversion samt Revision ablesen und vergleichen.
Dism /Online /Get-Packages /Format:Table auf beiden ausführen und die Paketlisten gegeneinanderhalten.
Den Unterschied benennen: Ein Paket, das über den Windows Installer kam, taucht bei Get-HotFix gar nicht auf und erklärt die scheinbare Gleichheit.
Den Vergleich als Skript festhalten, damit er für die übrigen Server ohne Handarbeit läuft.

Merksatz: Die 41 Einträge waren nie falsch — sie waren nur keine Antwort auf die gestellte Frage. Ein Inventar, dessen Auslassungen man nicht sieht, ist gefährlicher als eines, das offen unvollständig ist.

Der Neustart, der noch aussteht

Nach einer Installation stehen Änderungen häufig als ausstehende Aktionen im Komponentenspeicher und werden erst beim Neustart abgeschlossen. Bis dahin ist das Update installiert, aber nicht wirksam — der zweite der drei Zustände vom Anfang.

Dass es diesen Zwischenzustand gibt, ist dokumentiert und wird von den Werkzeugen selbst berücksichtigt: Dism /Add-Package kennt den Schalter /PreventPending, der die Installation überspringt, wenn das Paket oder das Abbild bereits ausstehende Online-Aktionen hat. Auch Add-WindowsCapability meldet in seiner Ausgabe RestartNeeded : True, wenn ein Neustart nötig ist.

Wo die Quellenlage dünn istFür die Erkennung eines ausstehenden Neustarts kursieren Registry-Schlüssel, die in Skripten weit verbreitet sind. Microsoft dokumentiert sie nicht als zugesagte Schnittstelle — sie können sich also ändern, ohne dass es irgendwo angekündigt wird. Wer sie benutzt, sollte das wissen und die Prüfung als Heuristik kennzeichnen. Die belastbare Aussage kommt aus dem Rückgabewert des Werkzeugs, das die Installation durchgeführt hat: Es weiß, ob es einen Neustart angefordert hat.

Betrieblich folgt daraus eine unbequeme Konsequenz: Der Zeitpunkt der Installation und der Zeitpunkt der Wirksamkeit sind zwei Termine, und nur der zweite bringt die Sicherheitskorrektur. Ein Patchfenster, in dem installiert, aber nicht neu gestartet wird, verschiebt die Wirkung auf einen unbestimmten späteren Neustart — und in der Zwischenzeit weist jeder Bericht den Server als gepatcht aus. Wo Neustarts knapp sind, ist die ehrliche Kennzahl nicht die Zahl installierter Updates, sondern die Zeit zwischen Installation und Neustart.

Platz schaffen und dabei den Rückweg wegwerfen

Der Komponentenspeicher wächst mit jedem Update, weil er die ersetzten Versionen behält. Genau diese Kopien sind es, die ein Update später wieder deinstallierbar machen. DISM bietet zum Aufräumen mehrere Stufen — und die letzte ist endgültig.

/AnalyzeComponentStore: Meldet die Größe und ob eine Bereinigung empfohlen wird. Ändert nichts.
/StartComponentCleanup: Entfernt ersetzte Komponenten. Der Rückweg bleibt erhalten.
/StartComponentCleanup /ResetBase: Setzt die Basis zurück. Installierte Updates lassen sich danach nicht mehr deinstallieren.
/StartComponentCleanup /ResetBase /Defer: Verschiebt die langlaufenden Teile auf die nächste automatische Wartung.

Der Handgriff, den man nicht zurücknimmt/ResetBase ist der Befehl, der auf einem Server mit knapper Systemplatte am schnellsten Platz schafft — und der die Deinstallierbarkeit aller installierten Updates dauerhaft beendet. Wer ihn ausführt und drei Tage später feststellt, dass das letzte kumulative Update eine Anwendung stört, hat den einfachen Rückweg nicht mehr. Er gehört deshalb nicht in ein Aufräumskript, das nebenbei läuft, sondern hinter dieselbe Freigabe wie jede andere unumkehrbare Änderung.

Verwandt und ebenfalls endgültig ist /SPSuperseded: Der Schalter entfernt die Sicherungsdateien, die bei der Installation eines Service Packs entstanden sind — danach lässt sich das Service Pack nicht mehr deinstallieren. Beide Befehle folgen demselben Muster: Sie tauschen Plattenplatz gegen Umkehrbarkeit. Das kann die richtige Entscheidung sein, aber es ist eine Entscheidung, und sie gehört dokumentiert, weil man ihr am Server hinterher nichts mehr ansieht.

Wenn ein Update den Start verhindert

Für den schlimmsten Fall — der Server startet nach einem Update nicht mehr — gibt es Dism /Cleanup-Image /RevertPendingActions. Der Befehl nimmt alle ausstehenden Aktionen des letzten Servicing-Vorgangs zurück, weil genau diese die Startfehler verursachen können.

Zwei Einschränkungen, die man vorher kennen mussDie Dokumentation schreibt beides ausdrücklich: Der Schalter ist nicht auf einem laufenden Betriebssystem unterstützt und nicht auf einem Windows-PE- oder WinRE-Abbild. Er ist ausschließlich für den Wiederherstellungsfall gedacht — angewendet aus einer Wiederherstellungsumgebung heraus gegen das Abbild des defekten Systems. Wer ihn versuchsweise auf dem laufenden Server ausführt, benutzt ein Werkzeug außerhalb seines Einsatzbereichs; wer ihn aus WinRE gegen das eingehängte System richtet, benutzt es richtig.

Damit hängt dieses Modul an dem über Start und Wiederherstellung: Ob es diesen Rückweg für einen Server überhaupt gibt, entscheidet sich daran, ob eine Wiederherstellungsumgebung eingebunden und ein Konsolenzugang vorhanden ist. Beides steht lange vor dem Wartungsfenster fest.

WSUS: was der Katalog überhaupt enthält

Ein WSUS-Server verteilt nicht alles, was es gibt, sondern das, was jemand ausgewählt hat: Produkte bestimmen, für welche Software synchronisiert wird, Klassifizierungen bestimmen die Art der Updates, und die Sprachauswahl bestimmt den Rest.

Die Lücke, die niemandem auffälltFehlt ein Produkt in der Auswahl, meldet kein Client einen Fehler und kein Bericht eine Lücke — die Updates existieren für diesen WSUS schlicht nicht. Ein Server, der laut Bericht zu hundert Prozent aktuell ist, kann Monate an Korrekturen für eine Anwendung vermissen, deren Produkt nie ausgewählt wurde. In einer Hierarchie kommt hinzu, dass ein nachgelagerter Server nur eine Teilmenge der Sprachen des vorgelagerten anfordern kann: Was oben nicht synchronisiert wird, gibt es unten nicht.

Praktisch heißt das: Die Produkt- und Klassifizierungsauswahl gehört in dieselbe Prüfung wie die Genehmigungen, und sie gehört wiederholt geprüft. Neue Software im Haus bedeutet in der Regel ein neues Produkt im Katalog — und niemand meldet das dem WSUS. Der übliche Zeitpunkt, an dem es auffällt, ist eine Sicherheitsmeldung zu einer Anwendung, für die es seit Jahren keine Updates gab, weil sie nie synchronisiert wurden.

Zielgruppen: server- oder clientseitig

WSUS ordnet Rechner Computergruppen zu, und dafür gibt es zwei Verfahren. Sie schließen einander praktisch aus, und die Wahl bestimmt, wo künftig Änderungen gemacht werden.

Serverseitige Zuweisung: Die Voreinstellung. Zuordnung über die WSUS-Konsole. Flexibel, aber neue Rechner müssen von Hand aus Unassigned Computers geholt werden.
Clientseitige Zuweisung: Zuordnung über eine Richtlinieneinstellung auf dem Rechner selbst. Neue Rechner landen automatisch richtig.
Standardgruppen: All Computers und Unassigned Computers. Jeder Client landet beim ersten Kontakt in beiden.

Der Preis der bequemeren VarianteBei clientseitiger Zuweisung lassen sich Rechner nicht mehr über die WSUS-Konsole in eine andere Gruppe verschieben — das geht dann nur noch über die Richtlinie des Rechners. Im Vorfall bedeutet das: Einen Server schnell aus dem Patchring zu nehmen, ist keine Sache von zwei Klicks mehr, sondern ein Richtlinienwechsel mit der zugehörigen Verzögerung. Wer clientseitig zuweist, sollte diesen Weg einmal geübt haben, bevor er ihn braucht.

Der Replikatmodus und seine leeren Gruppen

In größeren Umgebungen laufen nachgelagerte WSUS-Server im Replikatmodus: Sie übernehmen Genehmigungen und Computergruppen von einem Verwaltungsserver, statt eigene zu führen. Die Genehmigung fällt damit an genau einer Stelle.

Was der Replikatmodus nicht mitbringtDie Dokumentation ist hier präzise: Übernommen werden die Computergruppen — die Mitgliedschaft wird nicht verteilt. Auf einem Replikatserver erscheinen die Gruppen des Verwaltungsservers, und sie sind leer. Wer sie nicht vor Ort befüllt, hat eine sauber wirkende Struktur, in der kein einziger Server einem Ring zugeordnet ist. Zweite Einschränkung: Der Replikatmodus lässt sich nur bei der Einrichtung von WSUS festlegen, nicht nachträglich umstellen.

Ringe: repräsentativ heißt nicht unauffällig

Ein Patchring ist kein Zeitplan, sondern eine Wette: Wenn dieses Update auf dieser Gruppe funktioniert, funktioniert es auch auf der nächsten. Die Wette geht nur auf, wenn die erste Gruppe die zweite tatsächlich abbildet.

Ein Ring trägt nur, wenn seine Mitglieder die nachfolgenden Ringe in ihren Eigenschaften vertreten.

In der Praxis wird der Pilotring gern aus den Servern gebildet, deren Ausfall am wenigsten weh tut — also aus den unwichtigsten, ältesten oder am schwächsten genutzten. Das ist verständlich und macht die Aussage wertlos: Ein Update, das auf einem unbenutzten Server ohne die kritische Anwendung durchläuft, hat nichts über die Produktion bewiesen. Repräsentativ heißt: dieselbe Rolle, dieselbe Anwendung, dieselbe Hardware- oder Hostgeneration, echte Last.

Und das Stoppsignal gehört dazuEin Ring ohne definiertes Abbruchkriterium ist kein Gate, sondern eine Verzögerung. Vor dem Lauf muss feststehen, welches Signal den nächsten Ring blockiert — und wer es feststellen darf. Sonst entscheidet im Zweifel derjenige, der am meisten Termindruck hat.

Ein zweiter, unterschätzter Punkt ist die Zeit zwischen den Ringen. Sie muss länger sein als die Zeit, in der sich ein Problem zeigen würde. Ein Fehler, der erst beim Monatsabschluss auftritt, wird von einem Pilotfenster über drei Tage nicht gefunden — dann ist der Ring zwar sauber durchgelaufen und trägt trotzdem keine Aussage. Die Frage lautet deshalb nicht „wie lange warten wir“, sondern „welcher Ablauf müsste im Pilotring einmal stattgefunden haben“.

Das Ende der Strecke: Kanal, Support und Upgrade

Jeder Server hat ein Datum, ab dem er keine Sicherheitsupdates mehr bekommt. Es ergibt sich aus Version und Release-Kanal — und der Kanal steht nicht im Produktnamen.

Long-Term Servicing Channel: Neue Hauptversion typischerweise alle zwei bis drei Jahre, fünf Jahre Mainstream plus fünf Jahre erweiterter Support.
Annual Channel: Neue Version typischerweise jährlich, 18 Monate Mainstream plus sechs Monate erweiterter Support.
Kanal feststellen: Über die Betriebssystemversion, etwa mit Get-ComputerInfo. Der Produktname unterscheidet die Kanäle nicht.

Steht das Ende bevor, gibt es zwei Wege: ein In-Place-Upgrade auf derselben Maschine oder ein Neubau mit anschließender Migration der Rolle. Der zweite Weg kostet mehr und liefert eine saubere Ausgangslage; der erste ist schneller und trägt die Altlasten mit.

Was ein In-Place-Upgrade nicht kannDie Dokumentation nennt die Grenzen ausdrücklich: Ein Wechsel zwischen Server Core und Desktop Experience ist beim Upgrade nicht unterstützt, ein Upgrade von einer Vorabversion nicht, und ein Upgrade auf eine Evaluierungsversion ebenfalls nicht. Dazu kommt ein Detail, das leicht untergeht: Das App Compatibility Feature on Demand überlebt ein In-Place-Upgrade nicht und muss danach neu installiert werden. Wer diese Punkte vor dem Wartungsfenster prüft, entscheidet über den Weg — wer sie danach prüft, entscheidet über einen Rückfall.

Der Lebenszyklus gehört ins Inventar, nicht in den Kalender einer Person. Was ein Server ist, welche Version er trägt und wann sein Support endet, sind drei Felder, die zusammen gepflegt werden müssen — sonst fällt das Ende erst auf, wenn die monatlichen Updates ausbleiben. Und das fällt es nicht: Ein Server ohne verfügbare Updates meldet sich als vollständig aktuell.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität10 Primärquellen · zuletzt geprüft: 2026-09-03