Azure Updateverwaltung versus Azure Update Manager

Die beiden in der Werkzeuge Azure Updateverwaltung und Azure Update Manager dienen der Bereitstellung, Installation und Verwaltung von Updates für Server, die in Azure und (mit Hilfe der Azure Arc-Unterstützung) On Premise ausgeführt werden. Die Azure Updateverwaltung wird allerdings im August dieses Jahres außer Dienst gestellt. Du solltest die Unterschiede trotzdem kennen, insbesondere wenn du selbst oder deine Kunden die Migration der Azure Udapteverwaltung zum Azure Update Manager planen.

Passende Schulungen

AZ-104 Microsoft Azure Administrator (AZ-104T00)

AZ-104 Microsoft Azure Administrator (AZ-104T00): Azure Administration für Profis

AZ-305 – Designing Microsoft Azure Infrastructure Solutions (AZ-305T00)

Dieser Beitrag widmet sich also in erster Linie der Frage, worin der Unterschied zwischen der „Azure Updateverwaltung“ (Azure Automation Update Management) und dem „Azure Update Manager“ liegt. Wie im Teaser zu lesen wird das Azure Automation Update Management am 31. August 2024 eingestellt. Diese traditionelle Lösung basiert auf einer Kombination der Azure-Dienste „Azure Automation“ und „Log Analytics“. Dass das Azure Update Management zum 31. August 2024 abgekündigt ist, liegt natürlich auch daran, dass Microsoft den Log Analytics Agent zum gleichen Datum einstellt. Da die Update Management-Lösung zwingend den Log Analytics Agent voraussetzt, kann es zu Problemen kommen, sobald der Agent außer Betrieb genommen wird, weil das Azure Update Management nicht mit dem neueren AMA-Agent (Azure Monitoring Agent) zusammenarbeitet. Im Übrigen kümmern sich beide Lösungen um das Bereitstellen und Installieren von Updates für Windows- und/oder Linux-Server. Für Clients (Windows 10 / 11, Linux) ist entweder Intune oder Windows Update, bzw. die Update-Verwaltung deiner Linux-Distribution zuständig.

Übersicht der Azure-VM-Agents

Bevor ich dir also zeige, wie der neue Azure Update Manager funktioniert ist es hilfreich, wenn du dir die Einsatzbereiche und Abhängigkeiten der zahlreichen Agenten für virtuelle Maschinen in Azure und On Premise in Erinnerung rufst.

Der Azure Monitor Agent (AMA) ersetzt den Log Analytics Agent (auch bekannt als MMA und OMS) für Windows- und Linux-Maschinen, sowohl in Azure als auch in Nicht-Azure-Umgebungen, einschließlich On-Premises und Drittanbieter-Clouds. Der AMA-Agent führt eine vereinfachte und flexible Methode zur Konfiguration der Datensammlung mit Hilfe von Datensammlungsregeln (Data Collection Rules, DCRs) ein. Der Azure Monitor-Agent (AMA) ist ein separater Agent, der Überwachungsdaten sammelt. Er ersetzt in hybriden Umgebungen nicht den Connected Machine-Agent (Arc-Agent). Er ersetzt lediglich den Log Analytics-Agent, die Diagnoseerweiterung (für Azure VMs Windows oder Linux) und den Telegraf-Agent für Linux-Computer.

Der Azure Arc Agent ist erforderlich, um Nicht-Azure- und On-Premises-Server zu überwachen. Der Arc-Agent macht deine On-Premises-Server als Ressource sichtbar, die Azure ansteuern kann. Eine weitere Komponente des Arc-Agents ist der Erweiterungs-Agent, der für die Verwaltung von VM-Erweiterungen zuständig ist. Seine Aufgaben umfassen die Installation, Deinstallation und das Upgrade von so genannten VM-Erweiterungen. Dann gibt es noch den klassischen Azure-VM-Agenten. Er dient dem Starten, Ausführen und Überwachen von VM-Erweiterungen, welche dann bestimmte Aufgaben auf dem virtuellen Computer ausführen. VM-Erweiterungen sind kleine Anwendungen, die Konfigurations- und Automatisierungsaufgaben auf virtuellen Azure-Computern nach der Bereitstellung ermöglichen.

Mit dem Arc-Agent hingegen kannst du auf Arc-fähigen Servern Azure-VM-Erweiterungen für nicht in Azure gehostete Windows- und Linux-VMs bereitstellen, entfernen und aktualisieren. Der Azure Arc-Agent enthält mehrere logische Komponenten, darunter den Erweiterungs-Agent, der VM-Erweiterungen verwaltet, einschließlich Installation, Deinstallation und Upgrade. Der Azure Arc-Agent unterstützt das Azure-VM-Erweiterungsframework, das Konfigurations- und Automatisierungsaufgaben nach der Bereitstellung bietet. Wolltest du mit der alten Azure Updateverwaltung Updates auf lokalen Maschinen installieren, brauchtest du dazu einen so genannten Hybrid-Runbook-Worker.

Passende Schulungen

AZ-900 (2-tägig) – Microsoft Azure Fundamentals (AZ-900T00)

Während die Themen Monitoring und Updateverwaltung für VMs in Azure und On Premise im Zusammenhang stehen, gibt es natürlich noch weitere VM-Agenten, die mit dem Thema eher nichts zu tun haben wie z. B. den Azure-Backup-Agent, der das Installieren der VM-Snapshot-Erweiterung nach sich zieht oder der Network-Watcher-Agent für das Netzwerk-Monitoring. Rein auf das Überwachen von Performance-Daten und Protokollen (VM-Host, OS und/oder Applikation) bezogen, hilft dieser Tabelle vom Microsoft, hier etwas Überblick zu behalten:

Hier ist vor allem die Kategorie „Unterstützte Dienste und Features“ von Interesse: Hier liest du: „Verwaltung von Automatisierungsupdates – In Azure Update Manager verschoben“. Du siehst also auch hier, dass die Zukunft der Updateverwaltung beim Azure Update Manager liegt, unabhängig davon, ob die Server in Azure oder On Premise (Azure Arc) betrieben werden. Konkret bedeutet das:

• Die „alte“ Azure Updatewaltung basiert auf Azure Automation sowie Log Analytics und verwendet aktuell neuen Azure Monitor Agent AMA (optional bis August 2024 den Log-Analytics Agent) zur Verwaltung von Updates auf Servern in Azure.
• Zur Verwaltung lokaler Server mit der Azure Updateverwaltung muss ein so genannte Hybrid Worker eingerichtet werden. Der Hybrid Worker ist Teil von Azure Automation und erlaubt das Ausführen so genannter Runbooks (Powershell oder Python) direkt auf einer Azure- oder Nicht-Azure-Maschine, einschließlich Servern, die mit Azure Arc-fähigen Servern registriert sind. Von der Maschine oder dem Server, der die Rolle hostet, können Runbooks direkt gegen sie und gegen Ressourcen in der Umgebung ausgeführt werden, um diese lokalen Ressourcen zu verwalten. Azure Automation speichert und verwaltet Runbooks und liefert sie dann an eine oder mehrere ausgewählte Maschinen. Es gibt zwei Arten von Hybrid Runbook Workers:
• Agentenbasiert (V1): Dieser Typ wurde nach Abschluss des Log Analytics-Agenten installiert, der an einen Azure Monitor Log Analytics-Arbeitsbereich berichtet.
• Erweiterungsbasiert (V2): Dieser Typ wurde mit der Hybrid Runbook Worker VM-Erweiterung installiert, ohne dass eine Abhängigkeit vom Log Analytics-Agenten besteht, der an einen Azure Monitor Log Analytics-Arbeitsbereich berichtet.

Beide Hybrid Runbook Worker-Typen können auf derselben Maschine koexistieren, allerdings wird auch der agentenbasierte User Hybrid Runbook Worker (Windows und Linux) am 31. August eingestellt und nach diesem Datum nicht mehr unterstützt. Daher müssen bestehende agentenbasierte User Hybrid Runbook Workers vor dem 31. August 2024 auf erweiterungsbasierte Worker migriert werden.

• Du kannst die Azure Updateverwaltung auch über das Windows Admin Center einrichten, um deine im Admin Center verwalteten Server auf dem neuesten Stand zu halten. Allerdings müssen auch dazu ein Azure Automation Account und Log Analytics Workspace existieren.
• Der (neue) Azure Update Manager hingegen ist ein einheitlicher Dienst zur Verwaltung und Steuerung von Updates für alle deine Server. So kannst du die Compliance sämtlicher Windows- und Linux-Updates deiner Server für ihre Bereitstellungen in Azure, lokal und auf anderen Cloud-Plattformen über ein einzelnes Dashboard überwachen. Microsoft sichert derzeit zu, dass sämtliche Funktionen der Azure Automation Updateverwaltung „vor“ dem Deaktivierungsdatum im Azure Update Manager zur Verfügung stehen werden. Im Gegensatz zum Azure Updatemanagement interagiert der Azure Update Manager ausschließlich mit dem Azure-VM-Agent für Azure-VM oder dem Azure-Arc-Agent für Arc-fähige Maschinen. Der Azure Update Manager installiert dabei eine Erweiterung (Extension), die mit dem VM-Agenten oder Arc-Agenten kommuniziert, um Updates abzurufen und zu installieren. Schauen wir uns also das Azure Update Management in der Praxis an:

Azure Update Manager

Du kannst den Azure Update Manager von zwei Seiten aus ansteuern, bzw. einrichten. Entweder startest du mit der VM, die du anbinden willst und klickst im Blade der betreffenden VM im Abschnitt „Vorgänge“ auf „Updates“

.. und richtest hier individuell die Update für diesen Server ein oder du startest direkt mit dem Portal des Azure Update Manager im Azure-Portal, von wo aus du alle deine Server verwalten kannst.

Dort sind auch unsere beiden Test-Server unmittelbar nach deren Bereitstellung aufgeführt. Solltest du Client-Systeme in deinem Bestand haben, steht in der Spalte „Status aktualisieren“ der Eintrag „Nicht unterstützt“.

Achte außerdem auf die Spalten „Patchorchestrierung“ und „Status“. Ersteres steht mit der gleichnamigen Funktion in Verbindung, die du beim Neuerstellen einer VM im Azur-Portal im Schritt „Verwaltung“ (des VM-Bereitstellungsassistenten) im Abschnitt „Updates für das Gastbetriebssystem“ findest.

Hier solltest du wann immer möglich „Azure-orchestriert“ bevorzugen.

• Dieser Modus wird sowohl für Linux- als auch für Windows-VMs unterstützt und ermöglicht das automatische Patchen des Gast-OS orchestriert durch die Azure-Plattform. Wählst du diesen Modus für deine Azure-Server-VMs werden die nativen automatischen Updates auf dem virtuellen Windows-Computer deaktiviert, um Duplizierung zu vermeiden. Dieser Modus wird nur für VMs unterstützt, die mithilfe der unterstützten Betriebssystem-Plattformimages erstellt wurden. Welche das sind findest du auf der zugehörigen https://learn.microsoft.com/en-us/azure/virtual-machines/automatic-vm-guest-patching#supported-os-images Dokumentationsseite für Virtuelle Maschinen in Azure. Möchtest du Patches sofort nach deren Verfügbarkeit anwenden, ist dieser Modus zwingend.
• Der Modus „Automatisch durch Betriebssystem (automatische Windows-Updates)“ wird nur für virtuelle Windows-Computer unterstützt und delegiert die Patch-Orchestrierung an Windows-Update. Dann verschwindet auch das Listenauswahlfeld „Neustarteinstellungen“, weil du bei automatischen Windows-Updates nicht mehr die Wahl hast zu entscheiden, ob und wann Server neu gestartet werden; ein weiterer Grund auf „Azure orchestriert“ zu setzen.
• Möchtest du automatische Neustarts deiner Server vermeiden, wählst du entweder „Azure orchestriert“ (wenn möglich) oder „Manuell“. In diesem Fall kannst du immer noch klassisch deinen WSUS anbinden.
• „Standardwert des Images“ gilt nur für Linux-Server. Hier entscheidet der in deinem Linux-Maschine-Image voreingestellte Mechanismus deiner Linux-Distribution über das Patchen. 

Die Funktion „Hot-Patching“ ist übrigens ausschließlich für das Image „Windows Server 2022 Datacenter: Azure Edition Hotpatch – X64 Gen2“ verfügbar, das es nur in Azure gibt. Hier können Patches eingespielt werden, ohne die VM komplett neu zu starten.

Zurück zum Azure Update Manager. Klickst du im Menü „Verwalten / Computer“ auf die gewünschte VM in der Liste, landest du wieder in der gleichen Ansicht wie oben, wenn du die Update-Verwaltung von der VM aus starten würdest. So oder so kannst du jetzt z. B. auf „Auf Updates prüfen“ klicken, womit du ein „Assessment“ auslöst.

Das Ergebnis könnte so aussehen:

Mit einem Klick auf „Einmaliges Update“ kannst du die ermittelten Patches installieren. Es startet ein Assistent, der dir im ersten Tab „Computer“ die ausgewählte Quell-VM zeigt, im Beispiel mit 5 ausstehenden Updates.

Der nächste Schritt „Updates“ zeigt dir eine Vorschau der zu installierenden Updates. Außerdem kannst du hier eingreifen und auf Wunsch Updates nach „Updateklassifizierung“, „KB-ID“ oder dem maximalen Patchveröffentlichungsdatum“ ein- oder ausschließen.

Im nächsten Schritt „Eigenschaften“ kannst du die „Neustartoption“ auswählen, genauso wie bei einer neu bereitzustellenden VM.

Im letzten Schritt „Überprüfen und Installieren“ klickst du nur noch auf „Installieren“.

Updates planen

Selbstverständlich kannst du Updates auch für eine spezifische VM oder eine größere Anzahl von VM planen. Klicke dazu z. B. ausgehend von der Übersichtseite des Update Manager auf „Updates planen“. Du landest im Assistenten „Wartungskonfiguration erstellen“. Wähle zuerst eine Ressourcengruppe für deine neue Wartungskonfiguration, gebe ihr einen Namen und wähle deine gewünschte Neustarteinstellung. Wähle außerdem den gewünschten „Wartungsbereich“. Du hast die Wahl zwischen „Host“, Betriebssystemimage“, „Gast“ oder „Netzwerkgateway“. Wähle z. B. „Gast“, wenn du nur Azure-VMs patchen möchtest. Mit einem Klick auf den gleichnamigen Link kannst du nun einen „Zeitplan hinzufügen“ optional mit oder ohne Enddatum, einem Wartungsfenster und einer Widerholungseinstellung. Die Optionen sind selbsterklärend, bzw. laden zum Experimentieren ein.

Im nächsten Schritt „Dynamische Bereiche“ kannst du mit einem Klick auf „+ Dynamischen Bereich hinzufügen“ einen solchen einfügen oder (falls vorhanden) entfernen. Du kannst das aber auch hier überspringen und später tun. Hier kannst du die Ziel-Ressourcen mit diversen Filtermöglichkeiten gezielt einschränken.

Das Ergebnis deiner Suche könnte z. B. so aussehen:

Klickst du auf „Speichern“ landest du bei „Azure-VMs für Zeitplanupdates konfigurieren“. Hier erfährt du auch, ob die von dir ausgewählten VMs mit den erforderlichen Optionen konfiguriert sind, um die Unterstützung deines Zeitplans sicherzustellen. Du kannst dann entweder „Nur mit unterstützen fortfahren“ oder mit der voreingestellten Option, die erforderlichen Optionen noch ändern.

Du landes wieder im Abschnitt „Dynamische Bereiche“ gehst dann weiter zum nächsten Schritt „Resources“. Hier kannst du deine Wartungskonfiguration den gewünschten Ziel-Ressourcen zuweisen, indem du auf „+ Ressourcen hinzufügen“ klickst. Das Ergebnis könnte so aussehen:

Klicke auf „Überprüfen + erstellen“ und nach der anschließenden Prüfung auf „Erstellen“. Du findest deinen Wartungstask anschließend im Azure-Portal als eigenständige Ressource wieder:

Klickst du nun im Azure Update Manager im Menü „Verwalten“ auf „Updates“ siehst du in unserem Beispiels einen Computer mit „keinen ausstehenden Updates“ – die VM, die wir soeben manuell gepatcht haben  –  und einen Computer mit „Ausstehenden Windows-Updates“, der aktuell auf seinen Wartungstask wartet. Ganz unten sind die ausstehenden Updates aufgeführt:

Du kannst auch in das Portal deiner Wartungskonfiguration wechseln und dort nach Bedarf den Zeitplan anpassen, wenn du Updates schneller anwenden möchtest. Natürlich kannst du trotzdem auch weiterhin die betreffende VM manuell patchen.