Patch Management im Unternehmen: Updates kontrolliert ausrollen und nachweisen

In vielen Unternehmen werden Updates noch immer als technische Nebenaufgabe behandelt: Ein Wartungsfenster wird geplant, Richtlinien werden zugewiesen und anschließend gilt der Vorgang als abgeschlossen. Das ist operativ zu kurz gedacht. Geräte können offline sein, Installationen fehlschlagen, Wartungsfenster auslaufen und erforderliche Neustarts ausbleiben.

Ein belastbarer Update-Prozess verbindet deshalb technische Verteilung mit Risikobewertung, Freigaben, Nachkontrolle und Dokumentation. Server und Clients benötigen dabei unterschiedliche Steuerungsmodelle. Das Betriebsprinzip bleibt gleich: planen, testen, gestuft ausrollen, prüfen, Abweichungen bearbeiten und den erreichten Stand nachvollziehbar festhalten.

Patching ist ein kontinuierlicher Betriebsprozess

Microsoft veröffentlicht das monatliche kumulative Sicherheitsupdate für Windows in der Regel am zweiten Dienstag eines Monats. Zusätzlich gibt es optionale nicht sicherheitsrelevante Vorschaureleases, jährliche Featureupdates und bei besonderem Bedarf Out-of-Band-Releases. Der bekannte „Patch Tuesday“ bietet damit einen Taktgeber, bildet aber nicht sämtliche Updatefälle ab. [1]

Ebenso wenig ist „sofort alles installieren“ ein belastbares Verfahren. Updates können Neustarts auslösen, Anwendungsabhängigkeiten berühren oder bekannte Probleme verursachen. Geregeltes Patch Management bedeutet daher weder größtmögliche Verzögerung noch maximale Geschwindigkeit um jeden Preis. Erforderlich ist eine risikobasierte Vorgehensweise, die Sicherheitsrelevanz, Ausnutzbarkeit, Kritikalität des Systems und mögliche Betriebsfolgen gemeinsam bewertet.

Für akut ausgenutzte oder anderweitig besonders kritische Schwachstellen sollte ein beschleunigter Sonderprozess existieren. Dieser benötigt vorab definierte Entscheidungskompetenzen, verkürzte Test- und Freigabeschritte, klare Kommunikationswege und eine nachgelagerte Kontrolle. Dringlichkeit ist kein Argument für unkoordiniertes Handeln.

Server und Clients brauchen unterschiedliche Steuerung

Server und Arbeitsplatzgeräte unterscheiden sich bei Verfügbarkeit, Abhängigkeiten, Wartungsfenstern und Neustartverhalten. Ein einheitlicher Prozess ist sinnvoll. Ein einziges Werkzeug für sämtliche Systeme ist es nicht automatisch.

Im basecloud-Betrieb werden Server in Azure direkt über die dafür vorgesehenen Azure-Funktionen gepatcht. Für verwaltete Windows-Clients kommt dagegen ein RMM-System zum Einsatz. Damit bleiben die technischen Werkzeuge getrennt, während Planung, Freigabe, Kontrolle und Nachweis nach einem gemeinsamen Betriebsprinzip organisiert werden.

Server: Azure Update Manager

Azure Update Manager ist ein Azure-Dienst zur Bewertung und Steuerung von Betriebssystemupdates auf Windows- und Linux-Servern. Er unterstützt Azure-VMs sowie über Azure Arc angebundene Server in lokalen Rechenzentren oder anderen Cloud-Umgebungen. Bewertungen, sofortige Installationen und geplante Installationen lassen sich zentral verwalten. Der Dienst ist nicht von Azure Automation oder einem Log-Analytics-Arbeitsbereich abhängig. [2]

Wiederkehrende Installationen werden über Maintenance Configurations geplant. Dabei lassen sich Zeitplan, Wartungsfenster, Zielsysteme und einzubeziehende Updateklassifikationen beziehungsweise Pakete festlegen. Für Azure-VMs muss die Patch-Orchestrierung für diese Variante auf „Customer Managed Schedules“ eingestellt sein; für Arc-fähige Server gilt diese konkrete Voraussetzung nicht. Microsoft weist außerdem darauf hin, dass Azure Update Manager keine Treiberupdates unterstützt. [3]

Das Werkzeug ersetzt keine Betriebsentscheidung. Systeme mit gemeinsamen Abhängigkeiten müssen sinnvoll gruppiert werden, Neustarts sind einzuplanen und die Länge des Wartungsfensters muss realistisch sein. Wird das Fenster überschritten, beendet Azure Update Manager bereits laufende Installationen nicht; noch nicht gestartete Updates können jedoch ausbleiben. Eine geplante Ausführung ist daher kein Erfolgsnachweis. [3]

Windows-Clients: Patch Management über RMM

Bei Windows-Clients nutzt basecloud kein Windows Autopatch. Die Steuerung des Patchings erfolgt über das eingesetzte Remote-Monitoring-and-Management-System, kurz RMM.

Die technische Umsetzung unterscheidet sich damit vom Server-Patching in Azure. Der betriebliche Anspruch bleibt jedoch derselbe: Updates müssen einem definierten Gerätebestand zugeordnet, kontrolliert verteilt und anschließend auf ihren tatsächlichen Installationsstatus überprüft werden.

Entscheidend ist dabei weniger, welches Werkzeug einen Installationsauftrag auslöst, sondern wie der gesamte Prozess organisiert ist. Für verwaltete Clients müssen unter anderem geklärt sein:

• welche Geräte zum vereinbarten Patch-Scope gehören
• welche Updatearten durch den regulären Prozess abgedeckt werden
• welche Geräte oder Gruppen zuerst aktualisiert werden
• welche Fristen für Installation und Neustart gelten
• wie mit nicht erreichbaren Geräten umgegangen wird
• wann ein Fehler oder eine Ausnahme eskaliert werden muss
• wie der tatsächlich erreichte Patch-Stand dokumentiert wird

Der konkrete Funktionsumfang für Freigaben, Zeitpläne, Reports und Automatisierungen hängt vom eingesetzten RMM-System und der jeweiligen Konfiguration ab. Deshalb sollte der technische Werkzeugumfang im Betriebsmodell ebenso eindeutig festgelegt sein wie Zuständigkeiten und Zielzeiten.

Was einen belastbaren Update-Zyklus ausmacht

• Scope und Bestand: Es ist bekannt, welche Server und Clients zum Prozess gehören, wer Eigentümer ist und welches System die Updates steuert.
• Risikobewertung: Sicherheitsrelevanz, bekannte Ausnutzung, Systemkritikalität und mögliche Betriebsfolgen bestimmen die Zielzeit.
• Teststufe: Eine repräsentative Gruppe erhält Updates zuerst. Sie bildet relevante Anwendungen, Gerätetypen, Rollen und Betriebsmodelle ab.
• Freigabekriterien: Beobachtungsdauer, tolerierbare Fehler, Abbruchkriterien und Entscheidungsbefugnisse sind vor dem Rollout festgelegt.
• Produktionswellen: Die Verteilung erfolgt in definierten Gruppen mit ausreichender Beobachtungszeit zwischen den Stufen.
• Wartung und Neustart: Zeitfenster, Nutzerkommunikation, Abhängigkeiten und Neustartverhalten sind vor der Installation geklärt.
• Ausnahmen und Eskalation: Offline-Geräte, Fehler und bewusste Ausnahmen erhalten eine Frist, eine Begründung und einen Verantwortlichen.
• Nachkontrolle: Berichte und technische Prüfungen zeigen, ob Updates wirksam installiert wurden, ein Neustart aussteht oder Handlungsbedarf besteht.

Test und Produktion müssen tatsächlich getrennt sein

Eine Testgruppe erfüllt ihren Zweck nur, wenn sie die Produktion ausreichend repräsentiert. Einige technisch affine Freiwillige reichen nicht, wenn geschäftskritische Anwendungen, besondere Hardware, unterschiedliche Gerätemodelle oder verschiedene Arbeitsweisen fehlen. Die Teststufe sollte klein genug für schnelle Bewertung, aber breit genug für relevante Fehlersignale sein.

Zwischen den Stufen braucht es ein dokumentiertes Freigabekriterium: Welche Fehler sind akzeptabel? Wie lange wird beobachtet? Wer darf einen Rollout anhalten? Bei einer aktiv ausgenutzten Schwachstelle kann die Beobachtungszeit deutlich kürzer ausfallen. Die kontrollierte Reihenfolge bleibt dennoch bestehen, gegebenenfalls als beschleunigte Test- und Produktionswelle.

Ein Wartungsfenster belegt noch keine erfolgreiche Installation

Ein geplanter Lauf zeigt zunächst nur, dass eine Installation vorgesehen war. Server können ein Wartungsfenster überschreiten. Clients können ausgeschaltet, nicht verbunden oder aus anderen Gründen zum vorgesehenen Zeitpunkt nicht erfolgreich aktualisiert worden sein. Auch ein ausstehender Neustart kann bedeuten, dass eine Korrektur noch nicht vollständig wirksam ist.

Der Prozess endet daher nicht mit Ablauf des Zeitfensters. Er endet mit der Auswertung, der Bearbeitung fehlgeschlagener oder nicht erreichbarer Systeme und einer dokumentierten Entscheidung zu verbleibenden Risiken. Für Systeme außerhalb des definierten Zielzustands braucht es eine Frist und eine erneute Prüfung, nicht lediglich einen Eintrag in einer Ausnahmeliste.

Reporting ist eine Datenquelle, aber noch kein Auditnachweis

Azure Update Manager zeigt den jüngsten Bewertungsstand und die Installationshistorie. Dabei sind zeitliche Grenzen zu beachten: Microsoft dokumentiert, dass die jüngsten Bewertungsdaten in Azure Resource Graph sieben Tage gespeichert werden; die Kachel zum Installationsstatus zeigt standardmäßig die letzten 30 Tage. [4]

Auch beim Client-Patching über ein RMM-System ist ein technischer Statusbericht zunächst nur eine Datenquelle. Welche Informationen verfügbar sind, wie lange sie vorgehalten werden und wie detailliert Installationsfehler oder Neustartzustände nachvollzogen werden können, hängt vom eingesetzten System und dessen Konfiguration ab.

Für eine belastbare Betriebs- oder Auditspur sollten relevante Ergebnisse deshalb regelmäßig in die Ticket-, Change- oder Betriebsdokumentation übernommen beziehungsweise entsprechend der geforderten Aufbewahrungsdauer gesichert werden.

Dokumentiert werden sollten mindestens Scope, Zielupdate oder KB, Rollout-Gruppe beziehungsweise Maintenance Configuration, Zeitpunkt, Ergebnis, Neustartstatus, Fehler, genehmigte Ausnahmen, verantwortliche Rolle und abschließende Nachkontrolle.

Erst diese Verbindung zeigt, ob ein Update nur geplant, angeboten oder tatsächlich wirksam installiert wurde.

So organisiert basecloud Patch Management als Betriebsleistung

Wir behandeln Patch Management als wiederkehrenden Prozess mit eindeutig vereinbartem Scope. Gemeinsam mit unseren Kunden legen wir fest, welche Server und verwalteten Endgeräte einbezogen sind und welche Zielzeiten, Wartungsfenster, Rollout-Stufen und Eskalationswege gelten.

Für Azure-Server nutzen wir Azure Update Manager. Windows-Clients werden über unser RMM-System in den Patch-Prozess eingebunden. Damit setzen wir je nach Systemklasse unterschiedliche technische Werkzeuge ein, halten die betrieblichen Anforderungen an Kontrolle und Nachvollziehbarkeit aber einheitlich.

Im laufenden Betrieb bewerten wir nicht nur technische Statusanzeigen. Wir verfolgen fehlgeschlagene Installationen, nicht erreichbare Systeme, ausstehende Neustarts und genehmigte Ausnahmen innerhalb des vereinbarten Leistungsumfangs nach. Für besonders kritische Updates kann ein beschleunigter Prozess greifen, ohne Test, Freigabe und Nachvollziehbarkeit vollständig aufzugeben.

Die Leistungsgrenzen werden ausdrücklich dokumentiert. Standardzyklen, Sonderwartungen, Anwendungsupdates, Firmware und Treiber sowie Produkte außerhalb des vereinbarten Patch-Scopes sind keine austauschbaren Aufgaben. Erst eine klare Abgrenzung verhindert blinde Flecken und macht Patch Management als Managed Service steuerbar.

Fazit: Regelmäßigkeit und Nachkontrolle schließen die Lücke

Patch Management ist nicht mit der Verteilung von Updates erledigt. Entscheidend ist, ob die Organisation den gesamten Zyklus beherrscht: Bestand, Priorisierung, Test, Rollout, Neustart, Fehlerbearbeitung und Nachweis.

Azure Update Manager für Server und ein RMM-System für Windows-Clients übernehmen dabei unterschiedliche technische Aufgaben. Die Verantwortung für Scope, Freigaben, Ausnahmen und Reaktion bleibt dennoch Teil des Betriebs.

Eine aussagekräftige Kennzahl lautet daher nicht nur: „Wie viele Geräte sind aktuell?“ Entscheidend ist auch: Wie lange dauert es von der Veröffentlichung beziehungsweise Priorisierung bis zur nachgewiesenen Installation auf allen relevanten Systemen und wie werden verbleibende Ausnahmen behandelt?

Microsoft-Quellen

[1] Microsoft Learn: Update release cycle for Windows clients, aktualisiert am 27. März 2025

[2] Microsoft Learn: What is Azure Update Manager?, aktualisiert am 18. November 2025

[3] Microsoft Learn: Schedule recurring updates for machines by using the Azure portal and Azure Policy, aktualisiert am 21. August 2025

[4] Microsoft Learn: Manage multiple machines with Azure Update Manager, abgerufen am 3. August 2026