Teilen über

Übersicht über die Updateverwaltung

  • Artikel

Achtung

Dieser Artikel bezieht sich auf CentOS, eine Linux-Distribution, die den End-of-Life (EOL)-Status erreicht hat. Sie sollten Ihre Nutzung entsprechend planen. Weitere Informationen finden Sie im CentOS End-of-Life-Leitfaden.

Wichtig

Die Updateverwaltung für Automation wurde am 31. August 2024 eingestellt, und es wird empfohlen, Azure Update Manager zu verwenden. Befolgen Sie die Leitfäden für die Migration von der Automation-Updateverwaltung zu Azure Update Manager.

Wichtig

Azure Log Analytics-Agent (auch bezeichnet als Microsoft Monitoring Agent, MMA), wurde im August 2024 eingestellt. Die Azure Automation Update Management-Lösung basiert auf diesem Agenten und es kann zu Problemen kommen, sobald der Agent außer Betrieb genommen wird, da er nicht mit dem Azure Monitoring Agent (AMA) zusammenarbeitet. Wenn Sie daher die Azure Automation Update Management-Lösung verwenden, empfehlen wir Ihnen, für Ihre Softwareupdate-Anforderungen zum Azure Update Manager zu wechseln. Alle Funktionen der Azure Automation Update-Verwaltungslösung stehen vor dem Deaktivierungsdatum im Azure Update Manager zur Verfügung.

Mithilfe der Updateverwaltung in Azure Automation können Sie Betriebssystemupdates für Ihre virtuellen Windows- und Linux-Computer in Azure, in lokalen Umgebungen und in anderen Cloudumgebungen verwalten. Sie können den Status der verfügbaren Updates schnell auswerten und die Installation der für den Server erforderlichen Updates initiieren.

Als Dienstanbieter haben Sie möglicherweise mehrere Kundenmandanten in Azure Lighthouse integriert. Mit der Updateverwaltung können Updatebereitstellungen für Computer in mehreren Abonnements im selben Microsoft Entra-Mandanten oder über Mandanten hinweg mithilfe von Azure Lighthouse bewertet und geplant werden.

Microsoft bietet weitere Funktionen, mit denen Sie Updates für Ihre Azure-VMs oder für Ihre Azure-VM-Skalierungsgruppen verwalten können. Diese sollten Sie in Ihre gesamte Updateverwaltungsstrategie integrieren.

  • Wenn Sie Ihre Azure-VMs automatisch bewerten und aktualisieren möchten, um die Sicherheitskonformität mit den monatlichen kritischen Updates und Sicherheitsupdates zu gewährleisten, lesen Sie Automatische VM-Gastpatches. Hierbei handelt es sich um eine alternative Updateverwaltungslösung für Ihre Azure-VMs, damit diese außerhalb der Spitzenzeiten automatisch aktualisiert werden können. Auch VMs innerhalb einer Verfügbarkeitsgruppe, deren Updatebereitstellungen normalerweise manuell über die Updateverwaltung in Azure Automation verwaltet werden müssen, können so automatisch aktualisiert werden.

  • Wenn Sie Azure-VM-Skalierungsgruppen verwalten, informieren Sie sich darüber, wie Sie automatische Upgrades für Betriebssystemimages durchführen, um den Betriebssystemdatenträger für alle Instanzen der Skalierungsgruppe sicher und automatisch zu aktualisieren.

Machen Sie sich mit den Informationen in den folgenden Abschnitten vertraut, bevor Sie die Updateverwaltung bereitstellen und die Verwaltung auf Ihren Computern ermöglichen.

Informationen zur Updateverwaltung

Das folgende Diagramm veranschaulicht, wie die Updateverwaltung alle verbundenen Windows Server- und Linux-Server bewertet und Sicherheitsupdates darauf anwendet.

Updateverwaltungs-Workflow

Die Updateverwaltung kann in Azure Monitor-Protokolle integriert werden, um Updatebewertungen und -bereitstellungsergebnisse als Protokolldaten von zugewiesenen Azure- und Nicht-Azure-Computern zu speichern. Um diese Daten zu sammeln, werden das Automation-Konto und der Log Analytics-Arbeitsbereich miteinander verknüpft. Darüber hinaus ist der Log Analytics-Agent für Windows und Linux auf dem Computer erforderlich, der so konfiguriert werden muss, dass er an diesen Arbeitsbereich meldet.

Die Updateverwaltung unterstützt das Sammeln von Informationen über Systemupdates von Agents in einer System Center Operations Manager-Verwaltungsgruppe, die mit dem Arbeitsbereich verbunden ist. Die Registrierung eines Computers für die Updateverwaltung in mehreren Log Analytics-Arbeitsbereichen (auch als „Multi-Homing“ bezeichnet) wird nicht unterstützt.

In der folgenden Tabelle sind die von der Updateverwaltung unterstützten verbundenen Quellen zusammengefasst.

Verbundene Quelle Unterstützt BESCHREIBUNG
Windows Ja Die Updateverwaltung sammelt Informationen zu Systemupdates aus Windows-Computern mithilfe des Log Analytics-Agents und initiiert die Installation von erforderlichen Updates.
Die Rechner müssen sich bei Microsoft Update oder Windows Server Update Services (WSUS) melden.
Linux Ja Die Updateverwaltung sammelt Informationen zu Systemupdates aus Linux-Computern mithilfe des Log Analytics-Agents und initiiert die Installation von erforderlichen Updates auf unterstützten Distributionen.
Die Rechner müssen an ein lokales oder entferntes Repository berichten.
Operations Manager-Verwaltungsgruppe Ja Die Updateverwaltung sammelt Informationen zu Softwareupdates von Agents in einer verbundenen Verwaltungsgruppe.

Es ist keine direkte Verbindung zwischen dem Operations Manager-Agent und Azure Monitor-Protokollen erforderlich. Protokolldaten werden von der Verwaltungsgruppe an den Log Analytics-Arbeitsbereich weitergeleitet.

Die Computer, die der Updateverwaltung zugeordnet sind, melden, auf welchem aktuellen Stand sie sind, und zwar basierend auf der Quelle, mit der sie sich synchronisieren sollen. Windows-Rechner müssen so konfiguriert werden, dass sie entweder an Windows Server Update Services oder Microsoft Update berichten, und Linux-Rechner müssen so konfiguriert werden, dass sie an ein lokales oder öffentliches Repository berichten. Sie können die Updateverwaltung ebenfalls mit Microsoft Configuration Manager verwenden. Weitere Informationen dazu finden Sie unter Integrieren der Updateverwaltung mit Windows Configuration Manager.

Wenn der Windows Update Agent (WUA) für das Senden von Meldungen an WSUS konfiguriert ist, können sich die Ergebnisse von den angezeigten Microsoft Update-Ergebnissen unterscheiden. Dies hängt davon ab, wann WSUS zuletzt mit Microsoft Update synchronisiert wurde. Dasselbe gilt für Linux-Computer, die für Meldungen an ein lokales Repository konfiguriert sind (anstatt an ein öffentliches Repository). Auf einem Windows-Computer wird der Konformitätsscan standardmäßig alle 12 Stunden ausgeführt. Für einen Linux-Computer wird der Konformitätsscan standardmäßig jede Stunde durchgeführt. Wenn der Log Analytics-Agent neu gestartet wird, wird ein Konformitätsscan innerhalb von 15 Minuten gestartet. Wenn ein Computer einen Scanvorgang abgeschlossen hat, um die Konformität für das Update zu überprüfen, leitet der Agent die Informationen gesammelt an Azure Monitor-Protokolle weiter.

Sie können Softwareupdates auf Computern bereitstellen und installieren, für die die Updates erforderlich sind, indem Sie einen geplante Bereitstellung erstellen. Updates, die als Optional klassifiziert sind, sind im Bereitstellungsumfang von Windows-Computern nicht enthalten. Nur erforderliche Updates sind im Bereitstellungsumfang enthalten.

Die geplante Bereitstellung definiert, welche Zielcomputer die anwendbaren Updates erhalten. Hierzu werden entweder explizit bestimmte Computer angegeben, oder es wird eine Computergruppe ausgewählt, die auf Protokollsuchvorgängen einer bestimmten Gruppe von Computern basiert (oder auf einer Azure-Abfrage, die virtuelle Azure-Computer auf der Grundlage bestimmter Kriterien dynamisch auswählt). Diese Gruppen unterscheiden sich von der Bereichskonfiguration, mit der die Zielcomputer gesteuert werden, die die Konfiguration erhalten sollen, um die Updateverwaltung zu aktivieren. Dies verhindert, dass sie die Updatekonformität prüfen und melden und genehmigte erforderliche Updates installieren.

Beim Definieren einer Bereitstellung geben Sie außerdem einen Zeitplan an, um einen Zeitraum zu genehmigen und festzulegen, in dem Updates installiert werden dürfen. Dieser Zeitraum wird das Wartungsfenster bezeichnet. Zehn Minuten des Wartungsfensters sind für Neustarts reserviert (sofern ein Neustart erforderlich ist und Sie die entsprechende Neustartoption ausgewählt haben). Wenn das Patchen länger dauert als erwartet und im Wartungsfenster weniger als zehn Minuten verbleiben, wird kein Neustart durchgeführt.

Nachdem die Bereitstellung eines Updatepakets geplant wurde, dauert es 2 bis 3 Stunden, bis das Update bei Linux-Computern zur Bewertung angezeigt wird. Bei Windows-Computern dauert es 12 bis 15 Stunden, bis das Update nach der Veröffentlichung für die Bewertung angezeigt wird. Vor und nach der Updateinstallation wird eine Überprüfung der Updatekonformität durchgeführt und die Protokolldatenergebnisse werden an den Arbeitsbereich weitergeleitet.

Updates werden mit Runbooks in Azure Automation installiert. Sie können diese Runbooks nicht anzeigen, und für diese Runbooks ist keine Konfiguration erforderlich. Bei der Erstellung einer Updatebereitstellung wird ein Zeitplan erstellt, nach dem für die einbezogenen Computer zur angegebenen Zeit ein Masterrunbook für das Update gestartet wird. Das Master-Runbook startet auf jedem Agent ein untergeordnetes Runbook, das die Installation der erforderlichen Updates mit dem Windows Update-Agent (unter Windows) oder über den entsprechenden Befehl für die unterstützte Linux-Distribution initiiert.

Wenn die Datums- bzw. Uhrzeitangabe der Updatebereitstellung erreicht ist, führen die Zielcomputer die Bereitstellung parallel aus. Vor der Installation wird ein Scan ausgeführt, um sicherzustellen, dass die Updates weiterhin erforderlich sind. Für WSUS-Clientcomputer tritt ein Fehler bei der Updatebereitstellung auf, wenn die Updates in WSUS nicht genehmigt wurden.

Grenzwerte

Es folgen Grenzwerte, die für die Updateverwaltung gelten:

Ressource Begrenzung Hinweise
Anzahl der Computer pro Aktualisierungsbereitstellung 1000
Anzahl von dynamischen Gruppen pro Updatebereitstellung 500

Berechtigungen

Zum Erstellen und Verwalten von Updatebereitstellungen benötigen Sie bestimmte Berechtigungen. Weitere Informationen zu diesen Berechtigungen finden Sie unter Rollenbasierter Zugriff: Updateverwaltung.

Updateverwaltungskomponenten

Die Updateverwaltung verwendet die in diesem Abschnitt beschriebenen Ressourcen. Diese Ressourcen werden automatisch Ihrem Automation-Konto hinzugefügt, wenn Sie die Updateverwaltung aktivieren.

Hybrid-Runbook-Workergruppen

Nachdem Sie die Updateverwaltung aktiviert haben, werden alle direkt mit dem Log Analytics-Arbeitsbereich verbundenen Windows-Computer automatisch als System Hybrid Runbook Worker konfiguriert, um die Runbooks zu unterstützen, die die Updateverwaltung unterstützen.

Jeder von der Updateverwaltung verwaltete Windows-Computer wird im Bereich „Hybrid Worker-Gruppen“ als Hybrid Worker-Systemgruppe für das Automation-Konto aufgeführt. Die Gruppen verwenden die Benennungskonvention Hostname FQDN_GUID. Es ist nicht möglich, diese Gruppen mit Runbooks in Ihrem Konto zu erreichen. Entsprechende Versuche sind nicht erfolgreich. Diese Gruppen sind nur für die ausschließliche Unterstützung der Updateverwaltung bestimmt. Weitere Informationen zur Anzeige der Liste von Windows-Computern, die als Hybrid Runbook Worker konfiguriert sind, finden Sie unter Anzeigen von Hybrid Runbook Workern.

Sie können die Windows-Computer einer System Hybrid Runbook Worker-Gruppe in Ihrem Automation-Konto hinzufügen, um Automation-Runbooks zu unterstützen, wenn Sie für die Updateverwaltung und die Mitgliedschaft in der Hybrid Runbook Worker-Gruppe dasselbe Konto verwenden. Diese Funktionalität wurde in Version 7.2.12024.0 des Hybrid Runbook Worker hinzugefügt.

Externe Abhängigkeiten

Azure Automation Update Management hängt von den folgenden externen Abhängigkeiten ab, um Software-Updates bereitzustellen.

  • Windows Server Update Services (WSUS) oder Microsoft Update wird für Software-Update-Pakete und für die Überprüfung der Anwendbarkeit von Software-Updates auf Windows-basierten Computern benötigt.
  • Der Windows Update Agent (WUA) Client wird auf Windows-basierten Rechnern benötigt, damit diese eine Verbindung zum WSUS-Server oder Microsoft Update herstellen können.
  • Ein lokales oder entferntes Repository zum Abrufen und Installieren von Betriebssystem-Updates auf Linux-basierten Rechnern.

Management Packs

Die folgenden Management Packs werden auf den Computern installiert, die von der Updateverwaltung verwaltet werden. Wenn Ihre Operations Manager-Verwaltungsgruppe mit einem Log Analytics-Arbeitsbereich verbunden ist, werden die Management Packs in der Operations Manager-Verwaltungsgruppe installiert. Für diese Management Packs fällt kein Konfigurations- oder Verwaltungsaufwand an.

  • Microsoft System Center Advisor Update Assessment Intelligence Pack (Microsoft.IntelligencePacks.UpdateAssessment)
  • Microsoft.IntelligencePack.UpdateAssessment.Configuration (Microsoft.IntelligencePack.UpdateAssessment.Configuration)
  • Update Deployment MP

Hinweis

Wenn Sie über eine Operations Manager 1807- oder 2019-Verwaltungsgruppe verfügen, die mit einem Log Analytics-Arbeitsbereich verbunden ist, und in der Verwaltungsgruppe Agents für die Erfassung von Protokolldaten konfiguriert sind, müssen Sie den Parameter IsAutoRegistrationEnabled außer Kraft setzen und in der Regel Microsoft.IntelligencePacks.AzureAutomation.HybridAgent.Init auf True festlegen.

Weitere Informationen zu Updates der Management Packs finden Sie unter Herstellen einer Verbindung zwischen Operations Manager und Azure Monitor-Protokollen.

Hinweis

Damit die Updateverwaltung Computer mit dem Log Analytics-Agent vollständig verwalten kann, müssen Sie auf den Log Analytics-Agent für Windows oder den Log Analytics-Agent für Linux aktualisieren. Informationen zum Aktualisieren des Agents finden Sie unter Aktualisieren eines Operations Manager-Agents. In Umgebungen, in denen Operations Manager verwendet wird, muss mindestens System Center Operations Manager 2012 R2 UR14 ausgeführt werden.

Häufigkeit der Datensammlung

Die Updateverwaltung überprüft verwaltete Computer auf Daten mithilfe der folgenden Regeln. Es kann zwischen 30 Minuten und 6 Stunden dauern, bis im Dashboard aktualisierte Daten von verwalteten Computern angezeigt werden.

  • Für jeden Windows-Computer: Die Updateverwaltung führt zweimal am Tag eine Überprüfung jedes Computers durch.

  • Für jeden Linux-Computer: Die Updateverwaltung führt jede Stunde eine Überprüfung durch.

Die durchschnittliche Datennutzung von Azure Monitor-Protokollen für einen Computer mit Updateverwaltung beträgt etwa 25 MB pro Monat. Dieser Wert ist lediglich eine Schätzung und kann sich abhängig von Ihrer Umgebung ändern. Es empfiehlt sich, die Umgebung zu überwachen, um die exakte Nutzung nachzuverfolgen. Weitere Informationen zum Analysieren der Datennutzung von Azure Monitor-Protokollen finden Sie unter Azure Monitor-Protokolle: Preisdetails.

Updateklassifizierungen

In der folgenden Tabelle sind die Klassifizierungen definiert, die von der Updateverwaltung für Windows-Updates unterstützt werden.

Klassifizierung BESCHREIBUNG
Kritische Updates Ein Update für ein bestimmtes Problem, mit dem ein entscheidender, nicht sicherheitsrelevanter Fehler behoben wird.
Sicherheitsupdates Ein Update für ein produktspezifisches, sicherheitsrelevantes Problem.
Updaterollups Eine kumulative Gruppe von Hotfixes, die zur Vereinfachung der Bereitstellung gebündelt sind.
Feature Packs Neue Produktfeatures, die nicht im Rahmen eines Produktreleases verteilt werden.
Service Packs Eine kumulative Gruppe von Hotfixes, die auf eine Anwendung angewendet werden.
Definitionsupdates Ein Update für virenbehaftete oder andere Definitionsdateien.
Tools Ein Hilfsprogramm oder Feature, mit dem mindestens eine Aufgabe ausgeführt werden kann.
Aktualisierungen Ein Update für eine Anwendung oder Datei, die zurzeit installiert ist.

In der nächsten Tabelle sind die für Linux-Updates unterstützten Klassifizierungen definiert.

Klassifizierung BESCHREIBUNG
Kritische Updates und Sicherheitsupdates Updates für ein spezielles oder produktspezifisches, sicherheitsrelevantes Problem.
Andere Updates Alle anderen Updates, die nicht kritisch sind oder bei denen es sich nicht um Sicherheitsupdates handelt.

Hinweis

Die Updateklassifizierung für Linux-Computer ist nur verfügbar, wenn sie in den unterstützten öffentlichen Azure-Cloudregionen verwendet wird. Es gibt keine Klassifizierung von Linux-Updates bei Verwendung der Updateverwaltung in den folgenden Regionen mit nationalen Clouds:

  • Azure US Government
  • 21Vianet in China

Anstatt klassifiziert zu werden, werden Updates unter der Kategorie Andere Updates gemeldet.

Die Updateverwaltung verwendet Daten, die von den unterstützten Verteilungen veröffentlicht werden, insbesondere in deren veröffentlichten OVAL-Dateien (Open Vulnerability and Assessment Language). Da der Internetzugriff aus diesen nationalen Clouds eingeschränkt ist, kann die Updateverwaltung nicht auf diese Dateien zugreifen.

Logik der Klassifizierung von Linux-Updates

  1. Zu Bewertungszwecken klassifiziert die Updateverwaltung Updates in drei Kategorien: Sicherheit, Kritisch oder Andere. Diese Klassifizierung von Updates entspricht den Daten aus zwei Quellen:

    • OVAL-Dateien (Open Vulnerability and Assessment Language) werden vom Linux-Distributionsanbieter bereitgestellt, der Daten zu Sicherheitsproblemen oder Sicherheitsrisiken einschließt, die durch das Update behoben werden.
    • Der Paket-Manager auf Ihrem Computer, z. B. YUM, APT oder ZYPPER.

  2. Zum Patchen klassifiziert die Updateverwaltung Updates in zwei Kategorien: Kritisch und Sicherheit oder Andere. Diese Klassifizierung von Updates basiert ausschließlich auf Daten von Paket-Managern wie YUM, APT oder ZYPPER.

CentOS: Im Gegensatz zu anderen Distributionen stehen bei CentOS keine Klassifizierungsdaten aus dem Paket-Manager zur Verfügung. Wenn Sie CentOS-Computer so konfiguriert haben, dass für den folgenden Befehl Sicherheitsdaten zurückgegeben werden, kann die Updateverwaltung basierend auf Klassifizierungen Patchvorgänge ausführen.

sudo yum -q --security check-update

Hinweis

Aktuell gibt es keine unterstützte Methode, mit der unter CentOS die Verfügbarkeit nativer Klassifizierungsdaten aktiviert werden kann. Für Kunden, die diese Funktion möglicherweise selbst aktiviert haben, bieten wir derzeit nur eingeschränkten Support.

RedHat: Sie müssen das YUM-Sicherheits-Plug-In installieren, um Updates in Version 6 von Red Hat Enterprise zu klassifizieren. Unter Red Hat Enterprise Linux 7 ist das Plug-In bereits Teil von YUM selbst, und Sie müssen nichts installieren. Weitere Informationen finden Sie im folgenden Knowledge-Artikel zu Red Hat.

Integrieren der Updateverwaltung in Configuration Manager

Kunden, die in Microsoft Configuration Manager zur Verwaltung von PCs, Servern und mobilen Geräten investiert haben, verlassen sich auch bei der Verwaltung von Softwareupdates auf die Stärke und Ausgereiftheit von Configuration Manager. Informationen zur Integration von Updateverwaltung mit Configuration Manager finden Sie unter Integration von Update Management mit Windows Configuration Manager.

Drittanbieterupdates unter Windows

In der Updateverwaltung wird das lokal konfigurierte Updaterepository verwendet, um unterstützte Windows-Systeme zu aktualisieren, entweder WSUS oder Windows Update. Mit Tools wie System Center Updates Publisher können Sie benutzerdefinierte Updates mit WSUS importieren und veröffentlichen. Dadurch kann die Updateverwaltung Computer, auf denen Configuration Manager als Updaterepository verwendet wird, mit Software von Drittanbietern aktualisieren. Informationen zum Konfigurieren von Updates Publisher finden Sie unter Installieren von Updates Publisher.

Aktualisieren des Windows Log Analytics-Agent auf die neueste Version

Für die Updateverwaltung ist der Log Analytics-Agent für seine Funktion erforderlich. Wir empfehlen Ihnen, den Windows Log Analytics Agent (auch bekannt als Windows Microsoft Monitoring Agent (MMA)) auf die neueste Version zu aktualisieren, um Sicherheitslücken zu schließen und von Fehlerbehebungen zu profitieren. Log Analytics-Agent-Versionen vor 10.20.18053 (Bundle) und 1.0.18053.0 (Erweiterung) verwenden eine ältere Methode der Zertifikatsbehandlung und daher wird es nicht empfohlen. Ältere Windows Log Analytics-Agents konnten keine Verbindung mit Azure herstellen, und die Updateverwaltung funktioniert nicht mehr für sie.

Sie müssen den Log Analytics-Agent mit den folgenden Schritten auf die neueste Version aktualisieren:

  1. Überprüfen Sie die aktuelle Version des Log Analytics-Agent für Ihren Computer: Wechseln Sie zum Installationspfad – C:\ProgramFiles\Microsoft Monitoring Agent\Agent und klicken Sie mit der rechten Maustaste auf HealthService.exe, um die Eigenschaften zu überprüfen. Auf der Registerkarte Details enthält das Feld Produktversion die Versionsnummer des Log Analytics-Agent.

  2. Wenn Ihre Log Analytics-Agent-Version vor 10.20.18053 (Bundle) und 1.0.18053.0 (Erweiterung) liegt, führen Sie ein Upgrade auf die neueste Version des Windows Log Analytics-Agent durch und befolgen Sie diese Richtlinien. 

Hinweis

Während des Upgradevorgangs können Aktualisierungsverwaltungszeitpläne fehlschlagen. Achten Sie darauf, dies zu tun, wenn kein Zeitplan vorhanden ist.

Nächste Schritte