Managed-VM-Modul (Plattformseite)¶
Das Managed-VM-Modul deployt virtuelle Maschinen mit einer festen Baseline: Sicherheitseinstellungen, Owner-Gruppen, Monitoring, Backup und Patching. Workload-Teams nutzen es über Standardanfragen, siehe Managed Virtual Machines. Diese Seite richtet sich an das Plattform-Team: wie eine Anfrage zu einer Änderung wird, was regelmäßig zu prüfen ist und wie du die Release Notes des Moduls pflegst.
Optionales Modul
Das Modul ist nicht Teil des Kerncodes von hub und spoke. Seine Konfiguration liegt neben der spoke-Konfiguration, und seine eigenen releases und Release Notes sind getrennt. Prüfe, welche Version und welche Optionen deine Plattform einsetzt und welche pipeline es deployt.
Wie eine Anfrage zu einer Änderung wird¶
| Schritt | Wer | Was |
|---|---|---|
| 1 | Anfragender | Füllt die Anfrage aus (Anfragen und Änderungen) oder öffnet einen pull request auf die VM-Konfigurationsdatei, wenn er Zugriff hat |
| 2 | Plattform-Team | Prüft die Anfrage, bearbeitet die VM-Konfigurationsdatei für den spoke und die Umgebung, öffnet oder reviewt den pull request |
| 3 | Reviewer | Design-Review (zum Beispiel das Architekturteam des Kunden, wo der Vertrag es vorsieht) |
| 4 | Operator | Reviewt, merged und deployt mit der Modul-pipeline. Aktualisiert das Ticket. |
| 5 | Operator | Informiert den Anfragenden |
Es gibt pro spoke und Umgebung eine Konfigurationsdatei, in einem Ordner pro spoke. Ein neuer spoke-Ordner muss außerdem zur Liste der spokes in der Deployment-pipeline des Moduls hinzugefügt werden. Sonst wird nichts deployt und die pipeline bleibt grün. Nimm das in deine Checkliste für neue spokes auf (Neuer Spoke).
Lass Anfragende ihren pull request nicht selbst abschließen. Der Anfragende öffnet ihn, das Plattform-Team merged ihn. Siehe Änderungen sicher durchführen.
Die Checkliste für Reviewer und die Deployment-Schritte stehen in Managed-VM-Pull-Request-Review. Der Umfang des Services und seine Grenzen stehen in der Servicebeschreibung.
Änderungstypen, die zu einer Standardänderung passen¶
Diese Änderungen sind zu erwarten und gelten als Standardänderungen, solange sie über einen pull request laufen:
- eine neue VM-Konfiguration;
- Resizing (Änderung der SKU);
- Tag-Updates;
- Änderungen an Aufbewahrung oder Backup;
- Owner-Wechsel;
- eine Änderung der Anzahl der Instanzen;
- Access Packages ein- oder ausschalten.
Alles andere (eine neue Modul-Option, ein neues Image, eine Änderung an der Baseline) ist eine Änderung des Moduls, keine Standardänderung.
Anfragefelder¶
Die Felder stehen auf Anfragen und Änderungen. Behalte diese Tabelle für die weniger offensichtlichen:
| Feld | Zuordnung und Fallstricke |
|---|---|
| Workload-Kurzname + Konfigurations-Kurzname | Zusammen haben sie eine maximale Länge (8 Zeichen in Nicht-Produktion, 11 in Produktion im Quellmodul). Längere Namen brechen abgeleitete Ressourcennamen. Die Variable key_vault_name überschreibt den generierten Key-Vault-Namen, wenn der generierte falsch ist, zum Beispiel bei einem bestehenden Key Vault oder sehr langen Namen. |
| OS SKU | Ein interner SKU-Name, der auf ein Azure-Image abgebildet wird. Fehlt er, gilt das neueste. Die unterstützten Namen wachsen mit den Modulversionen. |
| Zu entfernende Datendisk | Der 0-basierte Index im Array data_disks. Das Entfernen einer Disk mitten in der Liste verschiebt die Indizes der anderen: Lies die Datei vorher neu ein. |
| Backup-RPO und Aufbewahrung | Getrennte Werte für jede Backup-Lösung. Der RPO des Backup Vaults lässt sich danach nicht mehr ändern. |
| Owners | E-Mail-Adressen, die in Entra ID existieren. owners_members setzt die Mitglieder der Owner-Gruppe. |
| Encryption at host | Braucht eine Feature-Registrierung auf der subscription, bevor es aktiviert werden kann. |
Wissenswerte Modul-Optionen¶
Diese Namen stammen aus den Release Notes des Moduls. Deine Version kann abweichen.
| Option | Zweck |
|---|---|
backup_solutions |
Liste mit BackupVault und RecoveryServicesVault |
rsv_alerts_for_all_job_failures_enabled, rsv_alerts_for_critical_operation_failures_enabled |
Alert bei Fehlern im Recovery Services vault |
disable_default_maintenance_configuration |
Schaltet die modulreigene Maintenance Configuration ab, sodass die per Policy zugewiesene gilt |
deploy_defender_plans |
Welche Defender-Pläne (Standard CloudPosture und VirtualMachines) |
deploy_change_tracking |
Change Tracking und Inventory |
custom_alert_rules |
Zusätzliche Alert-Regeln auf Log-Analytics-Daten |
encryption_at_host_enabled, disk_encryption_enabled |
Encryption at host und Azure Disk Encryption |
deploy_guest_configuration |
Guest-Configuration-Extension. Standardmäßig aus. Lass sie aus, wenn eine Azure Policy die Extension deployt. |
instances |
Anzahl identischer VMs einer Konfiguration. Bei einem Wert über 1 erhalten die VMs dieselbe Konfiguration und die Standardnamen mit aufsteigendem Suffix. |
useAccessPackages |
Access Packages in Entra ID, damit Owner im My-Access-Portal Nutzer zuweisen. Manche Plattformen verwenden sie nicht mehr. Wenn deine Plattform false bevorzugt, bitte den Anfragenden um Bestätigung, falls der pull request true setzt. |
license_type |
Hybrid Benefit für Windows- und Linux-VMs |
key_vault_name |
Expliziter Key-Vault-Name |
Patch-Zuweisung per Policy¶
VMs werden den Maintenance Configurations über Dynamic Scopes an den Maintenance Configurations zugewiesen. Die Scopes wählen
VMs über das Tag PatchPriority aus:
- Eine Azure-Policy-Initiative wird auf einer management group zugewiesen. Sie stellt sicher, dass jede subscription darunter im Dynamic Scope beider Maintenance Configurations liegt (nicht geschäftskritisch und geschäftskritisch), sodass neue subscriptions keine Änderung brauchen.
- Subscriptions außerhalb dieser management group (zum Beispiel direkt unter der Tenant Root Group) brauchen dieselbe Policy auf dieser Ebene, von Hand oder im Code zugewiesen.
- Die Managed Identity jeder Policy-Zuweisung braucht Rechte auf dem Scope der Zuweisung: Contributor (um bei Bedarf Remediation Tasks zu erstellen) und Scheduled Patching Contributor.
- Die Konfigurationsdateien im Code-Repository definieren die Zeitpläne. Dokumentation, die den Zeitplan wiederholt, ist eine Hilfe und kann veraltet sein.
Die Policy-Namen und Zuweisungsnamen sind deine eigenen. Nutze die Policy-Konventionen von Policy-Zuweisungen.
Niemand patcht eine VM ohne das Tag
Eine VM ohne PatchPriority (oder mit abweichender Schreibweise) liegt in keinem Dynamic Scope. Prüfe im Rahmen der regelmäßigen Kontrolle auf VMs ohne das Tag,
zum Beispiel mit einem Azure-Policy-Audit oder einer Resource-Graph-Abfrage.
Regelmäßige Kontrolle¶
Nach jedem Patch-Fenster (zum Beispiel am nächsten Arbeitsmorgen):
- Öffne Update Manager → Manage → History, filtere Update operation auf Install updates und Resource type auf Azure Virtual Machine.
- Suche nach Failed und Completed with warnings. Vergleiche installed mit total Updates: „8 of 10“ ist ein Fehlschlag.
- Sieh bei Machines nach No updates data (entferne vorher die Filter). Diese Maschinen waren aus oder haben keine Bewertung.
- Erstelle für jeden Fehler eine Aufgabe, kontaktiere den Workload-Owner und behebe die Ursache.
Ein Monatsbericht hat dieselbe Form: die Liste der Managed VMs pro Umgebung, Patch-Status (ausstehend, fehlgeschlagen, installiert, ausgenommen, Datum), Backup-Status und offene Folgeaufgaben. Kopiere keine Kundendaten in gemeinsame Dokumentation.
Führe außerdem eine Liste von VMs mit Sonderbehandlung: VMs, die von ihren Ownern gepatcht werden, VMs, die nicht automatisch neu starten dürfen, und VMs, die meist ausgeschaltet sind. Die Kontakte der Owner gehören in diese Liste.
Regelmäßige Kontrolle: Backups¶
- Prüfe die fehlgeschlagenen Backup-Jobs und Alert-Regeln der Recovery Services vaults.
- Teste eine Wiederherstellung mindestens einmal für jeden Workload-Typ, gemäß Backup und Wiederherstellung.
Release Notes¶
Führe Release Notes pro Modulversion und lege sie dort ab, wo die Workload-Teams sie lesen können. Ein bewährtes Muster:
- Eine Überschrift pro Version mit dem release-Monat:
## Version 1.4.11 (June 2025). - Aufzählungspunkte pro Änderung, beginnend mit Add, Change, Fix oder Ignore.
- Die neuen Optionsnamen im Codeformat, mit einem Link zur Microsoft-Dokumentation, wenn ein Feature eine Voraussetzung auf subscription-Ebene hat.
- Eine Zeile für jede Verhaltensänderung, die bestehende VMs betrifft (Standardwerte, Aufbewahrung, Rollen), denn diese Änderungen bemerken die Nutzer.
Auszug wichtiger Änderungen, um den Detailgrad zu zeigen:
| Version | Änderung |
|---|---|
| 1.1.0 | Change Tracking und Inventory, Custom Alert Rules. VM-Owner erhalten die Rolle Virtual Machine Administrator |
| 1.2.0 | Auswahl der Defender-Pläne |
| 1.3.0 | Recovery Services vault als Backup-Lösung (der Backup Vault war aus Kompatibilitätsgründen der Standard), Optionen für die Aufbewahrung |
| 1.3.1 | Boot Diagnostics; Administratoren erhalten Virtual Machine Contributor, damit sie die Serial Console nutzen können |
| 1.3.7 | license_type für Hybrid Benefit |
| 1.3.9 | Das Staging Storage Account des Recovery Services vaults verweigert öffentlichen Zugriff |
| 1.4.0 | Tags auf VMs; disable_default_maintenance_configuration |
| 1.4.4 | Encryption at host, Azure Disk Encryption, Guest Configuration, Owner-Mitglieder; Storage Account ohne öffentlichen Zugriff oder Shared Keys |
| 1.4.5 | Alerts für Job-Fehler im Recovery Services vault |
| 1.4.9 | Standard-Backup-Lösung auf Recovery Services vault geändert |
| 1.4.11 | Windows Server 2025, Ubuntu 24.04, weitere RHEL-Versionen |
Siehe auch Was zu tun ist, wenn eine neue Version veröffentlicht wird, wie neue Plattformversionen ausgerollt werden, und Abwärtskompatibilität, wie Änderungen von Standardwerten angekündigt werden.