Updates und Patching von Managed VMs¶
OS-Patches für Managed VMs werden mit dem Azure Update Manager installiert, einem Microsoft-Service. Eine Maintenance Configuration legt fest, wann und was installiert wird. Du weist VMs nicht von Hand zu: Ein Tag auf der VM wählt die Maintenance Configuration aus.
Zeitpläne sind Entscheidungen der Plattform
Die Zeitpläne, Namen und Zeiten unten sind ein Beispiel für einen verbreiteten Aufbau. Deine Plattform hat eigene Fenster. Frag dein Plattform-Team nach dem tatsächlichen Zeitplan. Die allgemeine Regel lautet: Die maßgebliche Quelle ist die Konfiguration der Maintenance Configurations im Code der Plattform, nicht diese Seite.
Was du bekommst¶
- Einheitliches Patching: Alle VMs mit dem richtigen Tag werden nach dem Zeitplan und mit den Update-Klassifizierungen ihrer Maintenance Configuration gepatcht.
- Keine manuelle Zuweisung: Nach dem Tagging wird die VM automatisch erfasst.
- Automatisches Onboarding: Neue Subscriptions und VMs werden ohne Änderungen an der Maintenance Configuration einbezogen.
Prioritäten und Zeitpläne¶
Systeme werden danach gruppiert, wie stark ein Ausfall oder ein verpasster Patch schadet. Eine übliche Klassifizierung orientiert sich an den Stufen für Verfügbarkeit und Integrität in deiner Sicherheitsklassifizierung:
| Gruppe | Typische Kriterien | Risikoprofil |
|---|---|---|
| Non-business-critical | Hostet einen Service mit der niedrigsten Klassifizierung (BIV 1) | Niedrig |
| Business-critical | Hostet einen Service mit höherer Klassifizierung (BIV 2 und 3) | Mittel |
| Internet-connected | Hostet einen Service, der aus dem Internet erreichbar ist | Hoch |
Typische Update-Frequenz: Patches mit normaler Dringlichkeit gehen zuerst an Non-business-critical-Systeme und eine Woche später an Business-critical-Systeme, sodass sich ein fehlerhaftes Update zuerst in der ersten Gruppe zeigt. Kritische (dringende) Patches gehen am selben Tag an Non-business-critical-Systeme und am Tag danach an Business-critical-Systeme.
Beispiel für zwei Maintenance Configurations:
| Konfiguration | Start | Wiederholung | Dauer | Zeitzone | Windows-Klassifizierungen | Linux-Klassifizierungen | Neustart |
|---|---|---|---|---|---|---|---|
| Non-business-critical | 01:00 | Monatlich, dritter Dienstag mit einem Offset von 5 Tagen | 2 Stunden | W. Europe Standard Time | Critical, Security, Definition, Updates, UpdateRollup | Critical, Security, Other | Falls erforderlich |
| Business-critical | 01:00 | Monatlich, vierter Dienstag mit einem Offset von 5 Tagen | 2 Stunden | W. Europe Standard Time | Critical, Security, Definition, Updates, UpdateRollup | Critical, Security, Other | Falls erforderlich |
Eine VM, die in kein Fenster passt (zum Beispiel wegen Jobs, die zuerst abgeschlossen sein müssen), kann eine eigene Maintenance Configuration bekommen. Frag dein Plattform-Team.
Deine VM taggen¶
Jede VM braucht einen Tag PatchPriority:
| Wert | Maintenance Configuration |
|---|---|
non-business-critical |
Die Non-business-critical-Konfiguration |
business-critical |
Die Business-critical-Konfiguration |
Für eine VM aus dem Managed-VM-Modul setzt du den Tag in der VM-Konfiguration und schaltest die moduleigene Standard-Maintenance-Configuration aus, damit der Tag entscheidet:
"disable_default_maintenance_configuration": true,
"tags": {
"PatchPriority": "non-business-critical"
}
Verwende die Feldnamen der Modulversion, die du einsetzt. Wenn du das Modul für eine VM nicht nutzt, setze den Tag von Hand oder in deinem eigenen Code. Die Zuweisung funktioniert für jede VM in den Subscriptions unter der Management Group, auf der die Plattform die Policy zugewiesen hat.
Orchestrierungsmodi
Der Update Manager unterstützt vom Kunden verwaltete Zeitpläne (der Ansatz auf dieser Seite) und, nur für Linux, die Image-Default-Patching-Konfiguration, die das Patching-Verhalten des Images verwendet.
Einstellungen einer VM-Konfiguration¶
| Einstellung | Bedeutung |
|---|---|
| Maintenance window | Wiederholung, Startzeit und Dauer, wenn du die plattformweiten Zeitpläne nicht nutzt. Der Standard des Moduls ist jeden Montag von 03:00 bis 05:00. |
| Allow update reboots | Ob die VM im Fenster neu starten darf. Ohne diese Einstellung wartet eine VM, die einen Neustart braucht, auf dich. |
| Exclude package names (Linux) | Packages, die nicht gepatcht werden. Wildcard * erlaubt. |
| Exclude KB numbers (Windows) | Bestimmte Updates, die nicht installiert werden. |
Die VM muss laufen¶
Eine VM muss 40 Minuten vor dem Start ihres Fensters laufen, sonst werden keine Updates installiert. Bei VMs mit einem Auto-Shutdown-Zeitplan übernimmt die Plattform das:
- Eine VM mit einem Tag
AutoShutdownSchedule, die zu Beginn des Fensters gestoppt ist, wird vor dem Patching gestartet und danach wieder gestoppt. - Eine VM, die du von Hand gestoppt hast, wird nicht gestartet und bekommt ihre Updates nicht.
Nutze für VMs, die du ausschalten willst, den Zeitplan-Tag und kein manuelles Stoppen.
Der Update Manager kann auch Pre-Events und Post-Events um ein Fenster herum ausführen. Beispiele: die VM vorher starten, nachher stoppen oder den Workload-Owner informieren, dass Updates installiert wurden. Plane für ein Pre-Event mindestens 40 Minuten vor Beginn des Fensters ein.
Prüfen, ob das Patching funktioniert hat¶
Sieh dir nach jedem Fenster das Ergebnis für deine VMs an:
- Öffne im Azure-Portal den Update Manager und dann Manage → History.
- Filtere Update operation auf Install updates und Resource type auf Azure Virtual Machine.
- Lies den Status pro VM:
| Status | Maßnahme |
|---|---|
| Succeeded | Keine |
| Failed | Nachverfolgen: Ursache finden und beheben, damit es nicht wiederkehrt |
| Completed with warnings | Updates wurden installiert, aber mit Problemen. Prüfe die Details. |
Lies auch die Anzahl der Updates. „8 of 10 updates installed“ bedeutet, dass zwei verpasst wurden, auch wenn die VM nicht als fehlgeschlagen markiert ist.
Prüfe unter Update Manager → Machines regelmäßig die Maschinen unter No updates data (entferne vorher die Filter). Diese VMs waren aus, haben keinen Agent oder kein Assessment. Sie werden nicht gepatcht.
Updates manuell installieren¶
Nutze das für VMs ohne Maintenance Configuration.
- Finde die VMs, denen Updates fehlen: Update Manager → Resources → Machines. Filtere die Update-Klassifizierungen auf Critical, Security, Update rollups und Definition updates (Windows) bzw. Security und Critical (Linux).
- Um zu sehen, welches Update auf welchen Maschinen fehlt, nutze Manage → Pending updates mit denselben Filtern. Die Spalte Machine(s) applicable listet sie auf.
- Öffne die VM, gehe zu Updates und wähle Check for updates, um ein neues Assessment auszuführen. Das kann dauern. Verfolge es im Benachrichtigungsbereich.
- Wähle One-time update. Füge mit Add machine weitere Maschinen hinzu, wenn du mehrere auf einmal aktualisierst.
- Wähle die Update-Klassifizierungen aus Schritt 1 (Select by update classification).
- Prüfe die Optionen, dann kontrolliere alles und wähle Install.
- Verfolge den Fortschritt auf dem Tab History der VM und prüfe, dass alle Updates installiert wurden.
Manche VMs werden bewusst von ihren Ownern gepatcht, zum Beispiel VMs, die meistens ausgeschaltet sind, Hosts, die einen geplanten Neustart brauchen, oder Domain Controller. Halte sie pro Workload fest, mit Ansprechpartner, Grund und Vorgehen für Updates, damit eine Patch-Runde sie nicht überspringt.
Siehe auch¶
- Kostenoptimierung: Auto-Shutdown
- Azure Arc für Server außerhalb von Azure
- Für Operatoren: Managed-VM-Modul (Plattformseite)