• Das AWS Systems Manager CloudWatch Dashboard wird nach dem 30. April 2026 nicht mehr verfügbar sein. Kunden können weiterhin die CloudWatch Amazon-Konsole verwenden, um ihre CloudWatch Amazon-Dashboards anzusehen, zu erstellen und zu verwalten, so wie sie es heute tun. Weitere Informationen finden Sie in der [Amazon CloudWatch Dashboard-Dokumentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). 

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# AWS Systems Manager Patch Manager
<a name="patch-manager"></a>

Patch Manager, ein Tool in AWS Systems Manager, automatisiert das Patchen von verwalteten Knoten sowohl mit sicherheitsrelevanten Updates als auch mit anderen Arten von Updates.

**Anmerkung**  
Systems Manager bietet Unterstützung für *Patch-Richtlinien* in Quick Setup, einem Tool in AWS Systems Manager. Die Verwendung von Patch-Richtlinien ist die empfohlene Methode zur Konfiguration Ihrer Patching-Vorgänge. Mit einer einzelnen Patch-Richtlinienkonfiguration können Sie Patches für alle Konten in allen Regionen in Ihrer Organisation, nur für die von Ihnen ausgewählten Konten und Regionen oder für ein einzelnes Konto-Region-Paar definieren. Weitere Informationen finden Sie unter [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md).

Sie können Patch Manager verwenden, um Patches sowohl für Betriebssysteme als auch für Anwendungen durchzuführen. (Unter Windows Server ist der Anwendungssupport auf Updates für Microsoft-Anwendungen beschränkt.) Sie können mit Patch Manager Service Packs auf Windows-Instances installieren und Nebenversionsupgrades auf Linux-Knoten ausführen. Sie können Flotten von Amazon Elastic Compute Cloud (Amazon EC2) -Instances, Edge-Geräten, lokalen Servern und virtuellen Maschinen (VMs) nach Betriebssystemtyp patchen. Dazu gehören unterstützte Versionen mehrerer Betriebssysteme, wie unter [Patch Manager-Voraussetzungen](patch-manager-prerequisites.md) aufgeführt. Sie können Instances nur auf Patches hin durchsuchen und dann einen Bericht zu fehlenden Patches anzeigen oder automatisch alle fehlenden Patches installieren. Um mit Patch Manager zu beginnen, öffnen Sie die [Systems-Manager-Konsole](https://console.aws.amazon.com//systems-manager/patch-manager). Wählen Sie im Navigationsbereich **Patch Manager** aus.

AWS testet Patches nicht, bevor sie in verfügbar gemacht werden. Patch Manager Unterstützt auch Patch Manager nicht die Aktualisierung von Hauptversionen von Betriebssystemen, wie Windows Server 2016 bis Windows Server 2019 oder Red Hat Enterprise Linux (RHEL) 7.0 auf RHEL 8.0.

Für Linux-basierte Betriebssysteme, die einen Schweregrad für Patches melden, verwendet Patch Manager den vom Software-Publisher gemeldeten Schweregrad für den Update-Hinweis oder den einzelnen Patch. Patch Manager leitet keinen Schweregrad aus Drittquellen wie dem [Common Vulnerability Scoring System](https://www.first.org/cvss/) (CVSS) oder aus Metriken ab, die von der [National Vulnerability Database](https://nvd.nist.gov/vuln) (NVD) veröffentlicht werden.

## Welche Vorteile bietet Patch Manager meiner Organisation?
<a name="how-can-patch-manager-benefit-my-organization"></a>

Patch Manager automatisiert den Prozess des Patchens verwalteter Knoten sowohl mit sicherheitsrelevanten Updates als auch mit anderen Arten von Updates. Er bietet mehrere große Vorteile:
+ **Zentralisierte Patching-Kontrolle** – Mit Patch-Richtlinien können Sie wiederkehrende Patches für alle Konten in allen Regionen in Ihrer Organisation, für bestimmte Konten und Regionen oder für ein einzelnes Konto-Region-Paar einrichten.
+ **Flexible Patching-Vorgänge** – Sie können Instances nur auf Patches hin durchsuchen und dann einen Bericht zu fehlenden Patches anzeigen oder automatisch alle fehlenden Patches installieren.
+ **Umfassende Compliance-Berichterstattung** – Nach dem Scannen können Sie detaillierte Informationen darüber abrufen, für welche verwalteten Knoten die Patch-Konformität nicht eingehalten wurde und welche Patches fehlen.
+ **Plattformübergreifende Unterstützung** – Patch Manager unterstützt mehrere Betriebssysteme, einschließlich verschiedener Linux-Distributionen, macOS, und Windows Server.
+ **Benutzerdefinierte Patch-Baselines** – Mithilfe von benutzerdefinierten Patch-Baselines, die angeben, welche Patches für die Installation zugelassen sind, können Sie definieren, was Patch-Compliance für Ihr Unternehmen bedeutet.
+ **Integration mit anderen AWS Diensten** — Patch Manager lässt sich in AWS Organizations, AWS Security Hub CSPM, und integrieren AWS CloudTrail, AWS Config um Verwaltung und Sicherheit zu verbessern.
+ **Deterministische Upgrades** – Support für deterministische Upgrades über versionierte Repositorys für Betriebssysteme wie Amazon Linux 2023.

## An wen richtet sich Patch Manager?
<a name="who-should-use-patch-manager"></a>

Patch Manager ist auf die folgenden Anwendungsfälle ausgelegt:
+ IT-Administratoren, die die Patch-Compliance für ihre gesamte Flotte verwalteter Knoten sicherstellen müssen
+ Betriebsmanager, die Einblick in den Status der Patch-Compliance in ihrer gesamten Infrastruktur benötigen
+ Cloud-Architekten, die automatisierte Patching-Lösungen in großem Umfang implementieren möchten
+ DevOps Techniker, die Patching in ihre betrieblichen Arbeitsabläufe integrieren müssen
+ Unternehmen mit Bereitstellungen mit mehreren Konten oder mehreren Regionen, die ein zentrales Patch-Management benötigen
+ Jeder, der für die Aufrechterhaltung der Sicherheitslage und des Betriebszustands von AWS verwalteten Knoten, Edge-Geräten, lokalen Servern und virtuellen Maschinen verantwortlich ist

## Was sind die Hauptfeatures von Patch Manager?
<a name="what-are-the-main-features-of-patch-manager"></a>

Patch Manager bietet mehrere wichtige Features:
+ **Patch-Richtlinien** — Konfigurieren Sie Patch-Operationen über mehrere AWS-Konten Regionen hinweg mithilfe einer einzigen Richtlinie durch Integration mit. AWS Organizations
+ **Benutzerdefinierte Patch-Baselines** – Definieren Sie Regeln für die automatische Genehmigung von Patches innerhalb weniger Tage nach ihrer Veröffentlichung, zusammen mit genehmigten und abgelehnten Patches.
+ **Verschiedene Patching-Methoden** – Wählen Sie je nach Ihren spezifischen Anforderungen zwischen Patch-Richtlinien, Wartungsfenstern oder On-Demand-Vorgängen „Jetzt patchen“.
+ **Compliance-Berichte** – Generieren Sie detaillierte Berichte zum Patch-Compliance-Status, die im CSV-Format an einen Amazon-S3-Bucket gesendet werden können.
+ **Plattformübergreifende Unterstützung** – Patchen Sie sowohl Betriebssysteme als auch Anwendungen auf Windows Server, verschiedenen Linux-Distributionen und macOS.
+ **Flexibilität bei der Terminplanung** – Legen Sie mithilfe benutzerdefinierter CRON- oder Rate-Ausdrücke unterschiedliche Zeitpläne für das Scannen und Installieren von Patches fest.
+ **Lebenszyklus-Hooks** – Führen Sie benutzerdefinierte Skripts vor und nach Patch-Vorgängen mithilfe von Systems-Manager-Dokumenten aus.
+ **Sicherheitsfokus** – Der Schwerpunkt von Patch Manager liegt standardmäßig auf sicherheitsrelevanten Updates und nicht auf der Installation aller verfügbaren Patches.
+ **Ratenkontrolle** – Konfigurieren Sie Schwellenwerte für Parallelität und Fehler bei Patch-Vorgängen, um die Auswirkungen auf den Betrieb zu minimieren.

## Worin besteht Compliance in Patch Manager?
<a name="patch-manager-definition-of-compliance"></a>

Der Maßstab dafür, was die *Patch-Compliance* für die verwalteten Knoten in Ihren Systems Manager Manager-Flotten ausmacht AWS, wird nicht von Betriebssystemanbietern (OS) oder von Dritten wie Sicherheitsberatungsfirmen definiert.

Stattdessen definieren Sie in einer *Patch-Baseline*, was Patch-Compliance für verwaltete Knoten in Ihrer Organisation oder Ihrem Konto bedeutet. Eine Patch-Baseline ist eine Konfiguration, die Regeln festlegt, nach denen Patches auf einem verwalteten Knoten installiert werden müssen. Ein verwalteter Knoten ist patch-konform, wenn er über alle Patches auf dem neuesten Stand ist, die die in der Patch-Baseline angegebenen Genehmigungskriterien erfüllen. 

Beachten Sie, dass *die Einhaltung* einer Patch-Baseline nicht bedeutet, dass ein verwalteter Knoten unbedingt *sicher* ist. Konformität bedeutet, dass die in der Patch-Baseline definierten Patches, die sowohl *verfügbar* als auch *genehmigt* sind, auf dem Knoten installiert wurden. Die Gesamtsicherheit eines verwalteten Knotens wird von vielen Faktoren bestimmt, die nicht in den Anwendungsbereich von Patch Manager fallen. Weitere Informationen finden Sie unter [Sicherheit in AWS Systems Manager](security.md).

Jede Patch-Baseline ist eine Konfiguration für einen bestimmten unterstützten Betriebssystemtyp (OS), z. B. Red Hat Enterprise Linux (RHEL), macOS oder Windows Server. Eine Patch-Baseline kann Patchregeln für alle unterstützten Versionen eines Betriebssystems definieren oder nur auf die von Ihnen angegebenen beschränkt sein, z. B. RHEL 7.8 und RHEL 9.3.

In einer Patch-Baseline könnten Sie angeben, dass alle Patches mit bestimmten Klassifizierungen und Schweregraden für die Installation zugelassen werden. Sie könnten beispielsweise alle als `Security` klassifizierten Patches einbeziehen, andere Klassifizierungen wie `Bugfix` oder `Enhancement` jedoch ausschließen. Und Sie könnten alle Patches mit einem Schweregrad von `Critical` einbeziehen und andere ausschließen, z. B. `Important` und `Moderate`.

Sie können Patches auch explizit in einer Patch-Baseline definieren, indem Sie sie IDs zu Listen bestimmter Patches hinzufügen, die genehmigt oder abgelehnt werden sollen, z. B. `KB2736693` `dbus.x86_64:1:1.12.28-1.amzn2023.0.1` für Windows Server oder für Amazon Linux 2023 (AL2023). Sie können optional eine bestimmte Anzahl von Tagen angeben, die auf das Patching gewartet wird, nachdem ein Patch verfügbar ist. Für Linux und macOS haben Sie die Möglichkeit, anstelle der in den Patch-Baseline-Regeln definierten Patches eine externe Liste von Patches aus Compliance-Gründen (eine Install Override-Liste) anzugeben.

Wenn ein Patching-Vorgang ausgeführt wird, vergleicht Patch Manager die Patches, die derzeit auf einen verwalteten Knoten angewendet werden, mit denen, die gemäß den in der Patch-Baseline oder in einer Install Override-Liste festgelegten Regeln angewendet werden sollten. Sie können auswählen, dass Patch Manager Ihnen nur einen Bericht über fehlende Patches anzeigt (ein `Scan`-Vorgang), oder Sie können auswählen, dass Patch Manager automatisch alle Patches installiert, die es auf einem verwalteten Knoten findet (ein `Scan and install`-Vorgang).

**Anmerkung**  
Die Daten zur Patch-Konformität stellen eine point-in-time Momentaufnahme des letzten erfolgreichen Patch-Vorgangs dar. Jeder Konformitätsbericht enthält eine Erfassungszeit, aus der hervorgeht, wann der Konformitätsstatus berechnet wurde. Berücksichtigen Sie bei der Überprüfung der Compliance-Daten die Erfassungszeit, um festzustellen, ob der Vorgang wie erwartet ausgeführt wurde.

Patch Manager stellt vordefinierte Patch-Baselines bereit, die Sie für Ihre Patching-Vorgänge verwenden können. Diese vordefinierten Konfigurationen dienen jedoch nur als Beispiele und nicht als empfohlene bewährte Methoden. Wir empfehlen, dass Sie selbst benutzerdefinierte Patch-Baselines erstellen, um besser kontrollieren zu können, was unter Patch-Compliance für Ihre Flotte zu verstehen ist.

Weitere Informationen zu Patch-Baselines finden Sie in den folgenden Themen:
+ [Vordefinierte und benutzerdefinierte Patch-Baselines](patch-manager-predefined-and-custom-patch-baselines.md)
+ [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md)
+ [AWS Vordefinierte Patch-Baselines anzeigen](patch-manager-view-predefined-patch-baselines.md)
+ [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md)
+ [Arbeiten mit Patch-Compliance-Berichten](patch-manager-compliance-reports.md)

## Primäre Komponenten
<a name="primary-components"></a>

Bevor Sie mit der Arbeit mit dem Patch Manager-Tool beginnen, sollten Sie sich mit einigen wichtigen Komponenten und Features der Patching-Vorgänge des Tools vertraut machen.

**Patch-Baselines**  
Patch Manager verwendet *Patch-Baselines*, die Regeln für die automatische Genehmigung von Patches innerhalb weniger Tage nach ihrer Veröffentlichung enthalten, zusätzlich zu den optionalen Listen der genehmigten und abgelehnten Patches. Wenn ein Patching-Vorgang ausgeführt wird, vergleicht Patch Manager die Patches, die derzeit auf einen verwalteten Knoten angewendet werden, mit denen, die gemäß den in der Patch-Baseline festgelegten Regeln angewendet werden sollten. Sie können auswählen, dass Patch Manager Ihnen nur einen Bericht über fehlende Patches anzeigt (ein `Scan`-Vorgang), oder Sie können auswählen, dass Patch Manager automatisch alle Patches installiert, die es auf einem verwalteten Knoten findet (ein `Scan and install`-Vorgang).

**Methoden für das Patchen von Vorgängen**  
Patch Manager bietet derzeit vier Methoden zum Ausführen von `Scan`- und `Scan and install`-Operationen:
+ **(Empfohlen) Eine in konfigurierte Patch-Richtlinie Quick Setup** — Basierend auf der Integration mit AWS Organizations können mit einer einzigen Patch-Richtlinie Patch-Zeitpläne und Patch-Baselines für eine gesamte Organisation definiert werden, einschließlich mehrerer AWS-Konten und all AWS-Regionen dieser Konten. Eine Patch-Richtlinie kann sich auch nur auf einige Organisationseinheiten (OUs) in einer Organisation beziehen. Sie können eine einzige Patch-Richtlinie verwenden, um nach verschiedenen Zeitplänen zu scannen und zu installieren. Weitere Informationen erhalten Sie unter [Das Patchen für Instances in einer Organisation mithilfe einer Patch-Richtlinie für Quick Setup konfigurieren](quick-setup-patch-manager.md) und [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md).
+ **Eine Host-Management-Option, konfiguriert in Quick Setup** — Host-Management-Konfigurationen werden auch durch die Integration mit unterstützt AWS Organizations, sodass ein Patch-Vorgang für bis zu eine gesamte Organisation ausgeführt werden kann. Diese Option ist jedoch darauf beschränkt, anhand der aktuellen Standard-Patch-Baseline nach fehlenden Patches zu suchen und Ergebnisse in Compliance-Berichten bereitzustellen. Mit dieser Vorgangsmethode können keine Patches installiert werden. Weitere Informationen finden Sie unter [Amazon-EC2-Host-Verwaltung mit Quick Setup einrichten](quick-setup-host-management.md).
+ **Ein Wartungsfenster zum Ausführen eines Patch-`Scan` oder einer `Install`-Aufgabe** – Ein Wartungsfenster, das Sie im Systems-Manager-Tool mit dem Namen Maintenance Windows einrichten, kann so konfiguriert werden, dass es verschiedene Arten von Aufgaben nach einem von Ihnen definierten Zeitplan ausführt. Eine Aufgabe vom Run Command-Typ kann verwendet werden, um `Scan` oder `Scan and install` Aufgaben auf einem Satz verwalteter Knoten Ihrer Wahl auszuführen. Jede Aufgabe im Wartungsfenster kann nur auf verwaltete Knoten in einem einzigen AWS-Region Paar AWS-Konto abzielen. Weitere Informationen finden Sie unter [Tutorial: Erstellen Sie ein Wartungsfenster zum Patchen über die Konsole](maintenance-window-tutorial-patching.md).
+ **Ein „**Jetzt patchen**“-On-Demand-Vorgang in Patch Manager** – Mit der Option **Jetzt patchen** können Sie Zeitplan-Einrichtungen umgehen, wenn Sie verwaltete Knoten so schnell wie möglich patchen müssen. Mit **Patch now** (Jetzt patchen) geben Sie an, ob der `Scan`- oder `Scan and install`-Vorgang ausgeführt werden soll und auf welchen verwalteten Knoten der Vorgang ausgeführt werden soll. Sie können sich auch dafür entscheiden, Systems-Manager-Dokumente (SSM-Dokumente) als Lebenszyklus-Hooks während des Patch-Vorgangs auszuführen. Jeder **Patch-Now-Vorgang** kann auf verwaltete Knoten in nur einem einzigen AWS-KontoAWS-Region Paar abzielen. Weitere Informationen finden Sie unter [On-Demand-Patchen von verwalteten Knoten](patch-manager-patch-now-on-demand.md).

**Compliance-Meldung**  
Nach einer `Scan`-Operation können Sie die Systems-Manager-Konsole verwenden, um Informationen darüber anzuzeigen, welche Ihrer verwalteten Knoten die Patch-Compliance nicht erfüllen und welche Patches auf jedem dieser Knoten fehlen. Sie können auch Patch-Compliance-Berichte im CSV-Format generieren, die an einen Amazon Simple Storage Service (Amazon S3)-Bucket Ihrer Wahl gesendet werden. Sie können einmalige Berichte erstellen oder Berichte nach einem regelmäßigen Zeitplan erstellen. Für einen einzelnen verwalteten Knoten enthalten Berichte Details aller Patches für den Knoten. Für einen Bericht über alle verwaltete Knoten wird nur eine Zusammenfassung der fehlenden Patches bereitgestellt. Nachdem ein Bericht generiert wurde, können Sie ein Tool wie Amazon Quick verwenden, um die Daten zu importieren und zu analysieren. Weitere Informationen finden Sie unter [Arbeiten mit Patch-Compliance-Berichten](patch-manager-compliance-reports.md).

**Anmerkung**  
Ein durch die Verwendung einer Patch-Richtlinie generiertes Compliance-Element hat den Ausführungstyp `PatchPolicy`. Ein Compliance-Element, das nicht in einem Patch-Richtlinienvorgang generiert wurde, hat den Ausführungstyp `Command`.

**Integrationen**  
Patch Managerlässt sich in die folgenden anderen AWS-Services integrieren: 
+ **AWS Identity and Access Management (IAM)** — Verwenden Sie IAM, um zu steuern, welche Benutzer, Gruppen und Rollen Zugriff Patch Manager auf Operationen haben. Weitere Informationen erhalten Sie unter [Funktionsweise von AWS Systems Manager mit IAM](security_iam_service-with-iam.md) und [Konfiguration von erforderlichen Instance-Berechtigungen für Systems Manager](setup-instance-permissions.md). 
+ **AWS CloudTrail**— Wird verwendet CloudTrail , um einen überprüfbaren Verlauf von Patch-Vorgängen aufzuzeichnen, die von Benutzern, Rollen oder Gruppen ausgelöst wurden. Weitere Informationen finden Sie unter [AWS Systems Manager API-Aufrufe protokollieren mit AWS CloudTrail](monitoring-cloudtrail-logs.md).
+ **AWS Security Hub CSPM**— Daten zur Patch-Konformität von Patch Manager können an gesendet werden. AWS Security Hub CSPM Security Hub CSPM bietet Ihnen einen umfassenden Überblick über Ihre Sicherheitswarnungen mit hoher Priorität und den Compliance-Status. Er überwacht auch den Patching-Status Ihrer Flotte. Weitere Informationen finden Sie unter [Integrieren Patch Manager mit AWS Security Hub CSPM](patch-manager-security-hub-integration.md). 
+ **AWS Config**— Richten Sie die Aufzeichnung ein AWS Config , um die Amazon EC2 EC2-Instance-Verwaltungsdaten im Patch Manager Dashboard anzuzeigen. Weitere Informationen finden Sie unter [Patch-Dashboard-Zusammenfassungen anzeigen](patch-manager-view-dashboard-summaries.md).

**Topics**
+ [Welche Vorteile bietet Patch Manager meiner Organisation?](#how-can-patch-manager-benefit-my-organization)
+ [An wen richtet sich Patch Manager?](#who-should-use-patch-manager)
+ [Was sind die Hauptfeatures von Patch Manager?](#what-are-the-main-features-of-patch-manager)
+ [Worin besteht Compliance in Patch Manager?](#patch-manager-definition-of-compliance)
+ [Primäre Komponenten](#primary-components)
+ [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md)
+ [Patch Manager-Voraussetzungen](patch-manager-prerequisites.md)
+ [So funktionieren Patch Manager-Operationen](patch-manager-patching-operations.md)
+ [SSM-Befehlsdokumente zum Patchen verwalteter Knoten](patch-manager-ssm-documents.md)
+ [Patch-Baselines](patch-manager-patch-baselines.md)
+ [Verwenden von Kernel Live Patching auf von Amazon Linux 2 verwalteten Knoten](patch-manager-kernel-live-patching.md)
+ [Arbeiten mit Patch Manager-Ressourcen und Compliance mithilfe der Konsole](patch-manager-console.md)
+ [Arbeiten mit Patch Manager-Ressourcen unter Verwendung der AWS CLI](patch-manager-cli-commands.md)
+ [AWS Systems Manager Patch Manager Tutorials](patch-manager-tutorials.md)
+ [Fehlerbehebung für Patch Manager](patch-manager-troubleshooting.md)

# Patch-Richtlinienkonfigurationen in Quick Setup
<a name="patch-manager-policies"></a>

AWS empfiehlt die Verwendung von *Patch-Richtlinien* zur Konfiguration von Patches für Ihr Unternehmen und. AWS-Konten Patch-Richtlinien wurden in Patch Manager im Dezember 2022 eingeführt. 

Eine Patch-Richtlinie ist eine Konfiguration, die Sie mit Quick Setup, einem Tool in AWS Systems Manager, einrichten. Patch-Richtlinien bieten eine umfassendere und zentralisiertere Kontrolle über Ihre Patching-Vorgänge, als dies mit früheren Methoden zum Konfigurieren von Patches möglich war. Patch-Richtlinien können mit [allen von Patch Manager unterstützten Betriebssystemen](patch-manager-prerequisites.md#pm-prereqs) verwendet werden, einschließlich unterstützter Versionen von Linux, macOS und Windows Server. Anweisungen zum Erstellen einer Patch-Richtlinie finden Sie unter [Das Patchen für Instances in einer Organisation mithilfe einer Patch-Richtlinie für Quick Setup konfigurieren](quick-setup-patch-manager.md).

## Hauptfeatures von Patch-Richtlinien
<a name="patch-policies-about-major-features"></a>

Anstatt andere Methoden zum Patchen Ihrer Knoten zu verwenden, verwenden Sie eine Patch-Richtlinie, um die Vorteile dieser Hauptfeatures zu nutzen:
+ **Einzelkonfiguration** – Das Einrichten von Patching-Vorgängen mithilfe eines Wartungsfensters oder einer State Manager-Zuordnung kann mehrere Aufgaben in verschiedenen Teilen der Systems-Manager-Konsole erfordern. Mithilfe einer Patch-Richtlinie können alle Ihre Patching-Vorgänge in einem einzigen Assistenten eingerichtet werden.
+ **Support für mehrere Benutzerkonten/Regionen** — Mithilfe eines Wartungsfensters, einer State Manager Zuordnung oder der Funktion „**Jetzt patchen**“ können Sie nur verwaltete Knoten in einem einzigen Paar auswählen. Patch Manager AWS-KontoAWS-Region Wenn Sie mehrere Konten und mehrere Regionen verwenden, können Ihre Einrichtungs- und Wartungsaufgaben viel Zeit in Anspruch nehmen, da Sie Einrichtungsaufgaben in jedem Konto-Region-Paar durchführen müssen. Wenn Sie jedoch die Option verwenden AWS Organizations, können Sie eine Patch-Richtlinie einrichten, die für alle Ihre verwalteten Knoten gilt. AWS-Regionen AWS-Konten Wenn Sie möchten, kann eine Patch-Richtlinie auch nur für einige Organisationseinheiten (OUs) in den von Ihnen ausgewählten Konten und Regionen gelten. Eine Patch-Richtlinie kann auf Wunsch auch für ein einzelnes lokales Konto gelten.
+ **Installationsunterstützung auf Organisationsebene** – Die vorhandene Host-Management-Konfigurationsoption in Quick Setup bietetUnterstützung für einen täglichen Scan Ihrer verwalteten Knoten auf Patch-Compliance. Dieser Scan wird jedoch zu einem vorher festgelegten Zeitpunkt durchgeführt und liefert nur Patch-Compliance-Informationen. Es werden keine Patch-Installationen durchgeführt. Mithilfe einer Patch-Richtlinie können Sie unterschiedliche Zeitpläne für das Scannen und Installieren festlegen. Sie können auch die Häufigkeit und Zeit dieser Vorgänge auswählen, indem Sie benutzerdefinierte CRON- oder Rate-Ausdrücke verwenden. Sie könnten beispielsweise jeden Tag nach fehlenden Patches suchen, um regelmäßig aktualisierte Compliance-Informationen bereitzustellen. Ihr Installationsplan könnte jedoch nur einmal pro Woche sein, um unerwünschte Ausfallzeiten zu vermeiden.
+ **Vereinfachte Auswahl von Patch-Baselines** – Patch-Richtlinien enthalten weiterhin Patch-Baselines, und es gibt keine Änderungen an der Art und Weise, wie Patch-Baselines konfiguriert werden. Wenn Sie jedoch eine Patch-Richtlinie erstellen oder aktualisieren, können Sie die AWS verwaltete oder benutzerdefinierte Baseline, die Sie für jeden Betriebssystemtyp (OS) verwenden möchten, in einer einzigen Liste auswählen. Es ist nicht erforderlich, die Standard-Baseline für jeden Betriebssystemtyp in separaten Aufgaben anzugeben.

**Anmerkung**  
Wenn Patching-Vorgänge, die auf einer Patch-Richtlinie basieren, ausgeführt werden, verwenden diese das `AWS-RunPatchBaseline`-SSM-Dokument. Weitere Informationen finden Sie unter [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).

**Ähnliche Informationen**  
[Stellen Sie mithilfe von Systems Manager zentral Patching-Operationen in Ihrem gesamten AWS Unternehmen](https://aws.amazon.com/blogs/mt/centrally-deploy-patching-operations-across-your-aws-organization-using-systems-manager-quick-setup/) bereit Quick Setup (AWS Cloud Operations and Migrations Blog)

## Weitere Unterschiede bei Patch-Richtlinien
<a name="patch-policies-about-other-features"></a>

Hier sind einige weitere Unterschiede, die bei der Verwendung von Patch-Richtlinien anstelle der vorherigen Methoden zum Konfigurieren von Patches zu beachten sind:
+ **Keine Patchgruppen erforderlich** – Bei früheren Patching-Vorgängen konnten Sie mehrere Knoten so kennzeichnen, dass sie zu einer Patch-Gruppe gehören, und dann die Patch-Baseline angeben, die für diese Patch-Gruppe verwendet werden soll. Wenn keine Patch-Gruppe definiert wurde, patcht Patch Manager die Instances mit der aktuellen Standard-Patch-Baseline für den OS-Typ. Durch die Verwendung von Patch-Richtlinien ist es nicht mehr erforderlich, Patch-Gruppen einzurichten und zu verwalten. 
**Anmerkung**  
Die Patchgruppenfunktion wird in der Konsole für Konto-Regionen-Paare nicht unterstützt, die vor der Veröffentlichung der Patch-Richtlinienunterstützung am 22. Dezember 2022 noch keine Patchgruppen verwendet haben. Die Patchgruppenfunktion ist weiterhin für Konto-Regionen-Paare verfügbar, die vor diesem Datum mit der Verwendung von Patchgruppen begonnen haben.
+ **Seite „Patching konfigurieren“ entfernt** – Vor der Veröffentlichung von Patch-Richtlinien konnten Sie auf der Seite **Configure patching** (Patching konfigurieren) Standardwerte für die zu patchenden Knoten, einen Patch-Zeitplan und einen Patching-Vorgang angeben. Diese Seite wurde von Patch Manager entfernt. Diese Optionen werden jetzt in Patch-Richtlinien festgelegt. 
+ **Keine „Jetzt patchen“ -Unterstützung** — Die Möglichkeit, Knoten bei Bedarf zu patchen, ist immer noch auf jeweils ein einzelnes Paar AWS-Konto beschränkt.AWS-Region Weitere Informationen finden Sie unter [On-Demand-Patchen von verwalteten Knoten](patch-manager-patch-now-on-demand.md).
+ **Patch-Richtlinien und Compliance-Informationen** – Wenn Ihre verwalteten Knoten gemäß einer Patching-Richtlinienkonfiguration auf Compliance gescannt werden, werden Ihnen Compliance-Daten zur Verfügung gestellt. Sie können die Daten auf die gleiche Weise wie bei anderen Methoden des Compliance-Scannens anzeigen und bearbeiten. Sie können zwar eine Patch-Richtlinie für eine gesamte Organisation oder mehrere Organisationseinheiten einrichten, die Compliance-Informationen werden jedoch für jedes Paar einzeln gemeldet AWS-Konto.AWS-Region Weitere Informationen finden Sie unter [Arbeiten mit Patch-Compliance-Berichten](patch-manager-compliance-reports.md).
+ **Konformitätsstatus der Zuordnungen und Patch-Richtlinien** – Der Patching-Status für einen verwalteten Knoten, für den eine Quick Setup-Patch-Richtlinie gilt, entspricht dem Status der State Manager-Zuordnungsausführung für diesen Knoten. Wenn der Status der Zuordnungsausführung `Compliant` lautet, wird der Patching-Status für den verwalteten Knoten ebenfalls als `Compliant` markiert. Wenn der Status der Zuordnungsausführung `Non-Compliant` lautet, wird der Patching-Status für den verwalteten Knoten ebenfalls als `Non-Compliant` markiert. 

## AWS-Regionen wird für Patch-Richtlinien unterstützt
<a name="patch-policies-supported-regions"></a>

Patch-Richtlinien-Konfigurationen in Quick Setup werden derzeit in den folgenden Regionen unterstützt:
+ USA Ost (Ohio): (us-east-2)
+ USA Ost (Nord-Virginia): (us-east-1)
+ USA West (Nordkalifornien) (us-west-1)
+ USA West (Oregon): (us-west-2)
+ Asien-Pazifik (Mumbai): (ap-south-1)
+ Asien-Pazifik (Seoul): (ap-northeast-2)
+ Asien-Pazifik (Singapur): (ap-southeast-1)
+ Asien-Pazifik (Sydney): (ap-southeast-2)
+ Asien-Pazifik (Tokyo) (ap-northeast-1)
+ Kanada (Zentral): (ca-central-1)
+ Europa (Frankfurt) (eu-central-1)
+ Europa (Irland) (eu-west-1)
+ Europa (London) (eu-west-2)
+ Europa (Paris) (eu-west-3)
+ Europa (Stockholm) (eu-north-1)
+ Südamerika (São Paulo) (sa-east-1)

# Patch Manager-Voraussetzungen
<a name="patch-manager-prerequisites"></a>

Stellen Sie sicher, dass Sie die erforderlichen Voraussetzungen erfüllt habenPatch Manager, bevor Sie ein Tool in verwenden AWS Systems Manager. 

**Topics**
+ [SSM Agent-Version](#agent-versions)
+ [Python-Version](#python-version)
+ [Zusätzliche Paketanforderungen](#additional-package-requirements)
+ [Konnektivität zur Patch-Quelle](#source-connectivity)
+ [S3-Endpunkt-Zugriff](#s3-endpoint-access)
+ [Berechtigungen zur lokalen Installation von Patches](#local-installation-permissions)
+ [Unterstützte Betriebssysteme für Patch Manager](#supported-os)

## SSM Agent-Version
<a name="agent-versions"></a>

Version 2.0.834.0 oder höher von SSM Agent muss auf dem verwalteten Knoten ausgeführt werden, den Sie mit Patch Manager verwalten möchten.

**Anmerkung**  
Wenn Systems Manager neue Tools hinzugefügt oder Aktualisierungen an den vorhandenen Tools vorgenommen werden, wird eine neue Version von SSM Agent veröffentlicht. Wenn Sie nicht die neueste Version des Agenten verwenden, kann dies dazu führen, dass der verwaltete Knoten nicht die zahlreichen Tools und Features von Systems Manager verwendet. Aus diesem Grund empfehlen wir, dass Sie den Prozess zur Aktualisierung von SSM Agent in Ihren Maschinen automatisieren. Weitere Informationen finden Sie unter [Automatisieren von Updates für SSM Agent](ssm-agent-automatic-updates.md). Abonnieren Sie die [SSM Agent-Versionshinweise](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)-Seite in GitHub, um Benachrichtigungen über SSM Agent-Updates zu erhalten.

## Python-Version
<a name="python-version"></a>

Unterstützt Patch Manager derzeit die Python-Versionen 2.6 bis 3.12 für macOS und die meisten Linux-Betriebssysteme (OSs). Die AlmaLinuxDebian Server, und Ubuntu Server OSs erfordern eine unterstützte Version von Python 3 (3.0-3.12).

## Zusätzliche Paketanforderungen
<a name="additional-package-requirements"></a>

Bei DNF-basierten Betriebssystemen können die `unzip` Dienstprogramme `zstd``xz`, und zum Dekomprimieren von Repository-Informationen und Patch-Dateien erforderlich sein. Zu den DNF-basierten Betriebssystemen gehören Amazon Linux 2023, Red Hat Enterprise Linux 8 und spätere Versionen, Oracle Linux Rocky Linux AlmaLinux, und CentOS 8 und spätere Versionen. Wenn Sie einen ähnlichen Fehler wie `No such file or directory: b'zstd'``No such file or directory: b'unxz'`, sehen oder wenn das Patchen aufgrund fehlender Informationen fehlschlägt`unzip`, müssen Sie diese Dienstprogramme installieren. `zstd``xz`, und `unzip` kann installiert werden, indem Sie den folgenden Befehl ausführen:

```
dnf install zstd xz unzip
```

## Konnektivität zur Patch-Quelle
<a name="source-connectivity"></a>

Wenn Ihre verwalteten Knoten keine direkte Verbindung zum Internet haben und Sie eine Amazon Virtual Private Cloud (Amazon VPC) mit einem VPC-Endpunkt verwenden, müssen Sie sicherstellen, dass die Knoten Zugriff auf die Quell-Patch-Verzeichnisse (Repos) haben. Auf Linux-Knoten werden Patch-Updates normalerweise von den auf dem Knoten konfigurierten Remote-Repos heruntergeladen. Daher muss der Knoten eine Verbindung zu den Repos herstellen können, damit die Patches ausgeführt werden können. Weitere Informationen finden Sie unter [Wie Sicherheitspatches ausgewählt werden](patch-manager-selecting-patches.md).

Wenn Sie einen Knoten patchen, der in einer IPv6 reinen Umgebung ausgeführt wird, stellen Sie sicher, dass der Knoten mit der Patch-Quelle verbunden ist. Sie können die Run Command Ausgabe der Patching-Ausführung überprüfen, um nach Warnungen zu unzugänglichen Repositorys zu suchen. Für DNF-basierte Betriebssysteme ist es möglich, nicht verfügbare Repositorys so zu konfigurieren, dass sie beim Patchen übersprungen werden, wenn die Option auf unter gesetzt ist. `skip_if_unavailable` `True` `/etc/dnf/dnf.conf` Zu den DNF-basierten Betriebssystemen gehören Amazon Linux 2023, Red Hat Enterprise Linux 8 und spätere Versionen, Oracle Linux Rocky Linux AlmaLinux, und CentOS 8 und spätere Versionen. Unter Amazon Linux 2023 ist die `skip_if_unavailable` Option `True` standardmäßig auf eingestellt.

**CentOS Stream: Das `EnableNonSecurity`-Flag aktivieren**  
CentOS Stream-Knoten verwenden DNF als Paketmanager, das das Konzept eines Update-Hinweises verwendet. Ein Update-Hinweis ist einfach eine Sammlung von Paketen, die bestimmte Probleme beheben. 

Standard-Repos von CentOS Stream werden jedoch nicht mit einem Update-Hinweis konfiguriert. Das bedeutet, dass Patch Manager Pakete auf einem Standard-CentOS Stream-Repos nicht erkennt. Um Patch Manager für die Verarbeitung von Paketen, die nicht in einem Update-Hinweis enthalten sind, zu aktivieren, müssen Sie die `EnableNonSecurity`-Markierung in den Patch-Baseline-Regeln aktivieren.

**Windows Server: Stellen Sie die Konnektivität zum Windows Update Catalog oder Windows Server Update Services (WSUS) sicher**  
Von Windows Server verwaltete Knoten müssen eine Verbindung zum Windows Update Catalog oder Windows Server Update Services (WSUS) herstellen können. Vergewissern Sie sich, dass Ihre Knoten über ein Internet-Gateway, ein NAT-Gateway oder eine NAT-Instance eine Verbindung zum [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/home.aspx) hergestellt haben. Wenn Sie WSUS verwenden, stellen Sie sicher, dass der Knoten eine Verbindung zum WSUS-Server in Ihrer Umgebung hat. Weitere Informationen finden Sie unter [Problem: Der verwaltete Knoten hat keinen Zugriff auf Windows Update Catalog oder WSUS](patch-manager-troubleshooting.md#patch-manager-troubleshooting-instance-access).

## S3-Endpunkt-Zugriff
<a name="s3-endpoint-access"></a>

Unabhängig davon, ob Ihre verwalteten Knoten in einem privaten oder öffentlichen Netzwerk betrieben werden, ohne Zugriff auf die erforderlichen AWS verwalteten Amazon Simple Storage Service (Amazon S3) -Buckets schlagen Patch-Vorgänge fehl. Informationen zu den S3-Buckets, auf die Ihre verwalteten Knoten zugreifen können müssen, finden Sie unter [SSM AgentKommunikation mit AWS verwalteten S3-Buckets](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) und [Die Sicherheit von EC2-Instances mithilfe von VPC-Endpunkten für Systems Manager verbessern](setup-create-vpc.md).

## Berechtigungen zur lokalen Installation von Patches
<a name="local-installation-permissions"></a>

Unter den Betriebssystemen Windows Server und Linux setzt Patch Manager zum Installieren von Patches die Benutzerkonten Administrator bzw. Root voraus.

Unter macOS unterstützt Homebrew für Brew und Brew Cask jedoch nicht die Ausführung seiner Befehle unter dem Root-Benutzerkonto. Darum fragt Patch Manager entweder als Eigentümer des Homebrew-Verzeichnisses oder als gültiger Benutzer,der zur Eigentümergruppe des Homebrew-Verzeichnisses gehört, Homebrew–Befehle ab und führt sie aus. Um Patches installieren zu können, benötigt der Besitzer des `homebrew`-Verzeichnisses daher auch rekursive Eigentümerberechtigungen für das `/usr/local`-Verzeichnis.

**Tipp**  
Der folgende Befehl stellt diese Berechtigung für den angegebenen Benutzer bereit:  

```
sudo chown -R $USER:admin /usr/local
```

## Unterstützte Betriebssysteme für Patch Manager
<a name="supported-os"></a>

Das Patch Manager-Tool unterstützt nicht dieselben Betriebssystemversionen, die von anderen Systems-Manager-Tools unterstützt werden. (Eine vollständige Liste der von Systems Manager unterstützten Betriebssysteme finden Sie unter [Unterstützte Betriebssysteme für Systems Manager](operating-systems-and-machine-types.md#prereqs-operating-systems).) Stellen Sie daher sicher, dass die verwalteten Knoten, die Sie mit Patch Manager verwenden möchten, eines der Betriebssysteme ausführen, die in der folgenden Tabelle aufgeführt sind.

**Anmerkung**  
Patch Manager stützt sich auf die Patch-Repositorys, die auf einem verwalteten Knoten konfiguriert sind, z. B. Windows Update Catalog und Windows Server Update Services für Windows, um verfügbare Patches für die Installation abzurufen. Daher können Betriebssystemversionen, die am Ende ihres Lebenszyklus (EOL) sind, ist Patch Manager möglicherweise nicht in der Lage, über die neuen Updates zu berichten, wenn keine neuen Updates verfügbar sind. Dies kann daran liegen, dass vom Linux-Distributionsbetreuer, Microsoft oder Apple keine neuen Updates veröffentlicht wurden oder dass der verwaltete Knoten nicht über die richtige Lizenz für den Zugriff auf die neuen Updates verfügt.  
Wir empfehlen dringend, die Verwendung von Betriebssystemversionen zu vermeiden, die End-of-Life (EOL) erreicht haben. Betriebssystemanbieter, darunter auch, bieten AWS in der Regel keine Sicherheitspatches oder andere Updates für Versionen an, die EOL erreicht haben. Die weitere Verwendung eines EOL-Systems erhöht das Risiko, dass Upgrades, einschließlich Sicherheitsupdates, und andere Betriebsprobleme nicht durchgeführt werden können, erheblich. AWS testet die Systems Manager Manager-Funktionalität nicht auf Betriebssystemversionen, die EOL erreicht haben.  
Patch Manager meldet den Konformitätsstatus anhand der verfügbaren Patches auf dem verwalteten Knoten. Wenn auf einer Instance ein EOL-Betriebssystem ausgeführt wird und keine Updates verfügbar sind, wird Patch Manager den Knoten daher möglicherweise als konform melden, je nachdem, welche Patch-Baselines für den Patchvorgang konfiguriert wurden.


| Betriebssystem | Details | 
| --- | --- | 
|  Linux  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-prerequisites.html)  | 
| macOS |  *macOS wird nur für Amazon EC2-Instances unterstützt.* 13.0–13.7 (Ventura) 14*.x* (Sonoma) 15*.x* (Sequoia)  macOS Updates Patch Manager unterstützt keine Updates oder Upgrades für macOS, z. B. von 13.1 auf 13.2. Für die Aktualisierung der Betriebssystemversion von macOS empfehlen wir, die in Apple integrierten Mechanismen zu verwenden. Weitere Informationen finden Sie auf der Website mit Entwicklerdokumentation von Apple unter [Device Management](https://developer.apple.com/documentation/devicemanagement).   Unterstützung für Homebrew Patch Manager erfordert, dass Homebrew, das Open-Source-Softwarepaketverwaltungssystem, an einem der folgenden Standardinstallationsverzeichnisse installiert ist:  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-prerequisites.html) Patch-Vorgänge, die Patch Manager verwenden, funktionieren nicht richtig, wenn Homebrew nicht installiert ist.  Regionsunterstützung macOSwird nicht in AWS-Regionen allen unterstützt. Weitere Informationen zur Amazon-EC2-Unterstützung für macOS finden Sie unter [Amazon-EC2-Mac-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html) im *Amazon-EC2-Benutzerhandbuch*.   macOS-Edge-Geräte SSM Agentfür AWS IoT Greengrass Kerngeräte wird auf nicht unterstütztmacOS. Sie können Patch Manager nicht verwenden, um macOS-Edge-Geräte zu patchen.   | 
|  Windows  |  Windows Server 2012 bis Windows Server 2025, einschließlich R2-Versionen.  SSM Agentfür AWS IoT Greengrass Kerngeräte wird unter Windows 10 nicht unterstützt. Sie können Patch Manager nicht verwenden, um Windows-10-Edge-Geräte zu patchen.   Windows Server 2012 und 2012 R2 Windows Server 2012 und 2012 R2 haben am 10. Oktober 2023 das Ende der Unterstützung erreicht. Für die Verwendung Patch Manager mit diesen Versionen empfehlen wir, auch Extended Security Updates (ESUs) von Microsoft zu verwenden. Weitere Informationen finden Sie auf der Microsoft-Website unter [Windows Server 2012 und 2012 R2 erreichen das Ende des Supports](https://learn.microsoft.com/en-us/lifecycle/announcements/windows-server-2012-r2-end-of-support).   | 

# So funktionieren Patch Manager-Operationen
<a name="patch-manager-patching-operations"></a>

Dieser Abschnitt enthält technische Details, die erklären, wie Patch Manager, ein Tool in AWS Systems Manager, bestimmt, welche Patches installiert werden und wie er sie auf dem jeweiligen unterstützten Betriebssystem installiert. Für Linux-Betriebssysteme enthält er auch Informationen zur Angabe einer Quell-Repository, in einer benutzerdefinierten Patch-Baseline, für andere Patches als diejenigen, die standardmäßig auf einem verwalteten Knoten konfiguriert sind. Dieser Abschnitt bietet außerdem Informationen darüber, wie Patch-Baseline-Regeln auf verschiedenen Verteilungen des Linux-Betriebssystems funktionieren.

**Anmerkung**  
Die Informationen in den folgenden Themen gelten unabhängig davon, welche Methode oder Art der Konfiguration Sie für Ihre Patching-Vorgänge verwenden:  
Eine in Quick Setup konfigurierte Patch-Richtlinie
Eine in Quick Setup konfigurierte Host-Management-Option
Ein Wartungsfenster zum Ausführen eines Patch-`Scan` oder einer `Install`-Aufgabe
Ein On-Demand-**Jetzt patchen**-Vorgang

**Topics**
+ [So werden Veröffentlichungs- und Aktualisierungsdaten von Paketen berechnet](patch-manager-release-dates.md)
+ [Wie Sicherheitspatches ausgewählt werden](patch-manager-selecting-patches.md)
+ [So geben Sie ein alternatives Patch-Quell-Repository an (Linux)](patch-manager-alternative-source-repository.md)
+ [Wie Patches installiert werden](patch-manager-installing-patches.md)
+ [Funktionsweise von Patch-Baseline-Regeln auf Linux-basierten Systemen](patch-manager-linux-rules.md)
+ [Unterschiede beim Patchvorgang zwischen Linux und Windows Server](patch-manager-windows-and-linux-differences.md)

# So werden Veröffentlichungs- und Aktualisierungsdaten von Paketen berechnet
<a name="patch-manager-release-dates"></a>

**Wichtig**  
Die Informationen auf dieser Seite beziehen sich auf Amazon-Linux-2 und Amazon-Linux-2023-Betriebssysteme (OS) für Amazon Elastic Compute Cloud (Amazon EC2)-Instances. Die Pakete für diese Betriebssystemtypen werden von Amazon Web Services erstellt und verwaltet. Wie die Hersteller anderer Betriebssysteme ihre Pakete und Repositorys verwalten, wirkt sich darauf aus, wie ihre Veröffentlichungs- und Aktualisierungsdaten berechnet werden. OSs Neben Amazon Linux 2 und Amazon Linux 2023 finden Sie in der Dokumentation des Herstellers Informationen darüberRed Hat Enterprise Linux, wie ihre Pakete aktualisiert und gewartet werden.

In den Einstellungen für [benutzerdefinierte Patch-Baselines](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom), die Sie für die meisten Betriebssystemtypen erstellen, können Sie angeben, dass Patches nach einer bestimmten Anzahl von Tagen automatisch für die Installation genehmigt werden. AWS bietet mehrere vordefinierte Patch-Baselines, die automatische Genehmigungsdaten von 7 Tagen enthalten.

Eine *Verzögerung der automatischen Genehmigung* ist die Anzahl an Tagen, die gewartet werde soll, nachdem die Patch veröffentlicht wurde, bevor der Patch automatisch genehmigt wird. Beispielsweise erstellen Sie eine Regel mit der `CriticalUpdates`-Klassifizierung und konfigurieren sie für eine Verzögerung der automatischen Genehmigung um sieben Tage. Infolgedessen wird ein neuer kritischer Patch mit einem Veröffentlichungsdatum oder dem letzten Aktualisierungsdatum vom 7. Juli automatisch am 14. Juli genehmigt.

Um unerwartete Ergebnisse mit Verzögerungen bei der automatischen Genehmigung auf Amazon Linux 2 und Amazon Linux 2023 zu vermeiden, ist es wichtig zu wissen, wie die Veröffentlichungs- und Aktualisierungsdaten berechnet werden.

**Anmerkung**  
Wenn ein Amazon Linux 2- oder Amazon Linux 2023-Repository keine Informationen zum Veröffentlichungsdatum von Paketen bereitstellt, verwendet Patch Manager die Erstellungszeit des Pakets als Datum zur automatischen Genehmigung der Datumsangaben. Wenn die Erstellungszeit des Pakets nicht bestimmt werden kann, verwendet Patch Manager als Standarddatum den 1. Januar 1970. Dies führt dazu, dass alle Angaben zum Datum der automatischen Genehmigung in Patch-Baselines von Patch Manager umgangen werden, die so konfiguriert sind, dass Patches für jedes Datum nach dem 1. Januar 1970 genehmigt werden.

In den meisten Fällen wird die Wartezeit für die automatische Genehmigung vor der Installation von Patches aus einem `Updated Date`-Wert in `updateinfo.xml` und nicht aus einem `Release Date`-Wert berechnet. Im Folgenden finden Sie wichtige Details zu diesen Datumsberechnungen: 
+ Das `Release Date` ist das Datum, an dem ein *Hinweis* veröffentlicht wird. Dies bedeutet nicht, dass das Paket bereits in den zugehörigen Repositorys verfügbar ist. 
+ Das `Update Date` ist das letzte Datum, an dem der Hinweis aktualisiert wurde. Eine Aktualisierung eines Hinweises kann etwas so Kleines wie eine Text- oder Beschreibungsaktualisierung darstellen. Dies bedeutet nicht, dass das Paket ab diesem Datum veröffentlicht wurde oder notwendigerweise in den zugehörigen Repositorys verfügbar ist. 

  Dies bedeutet, dass ein Paket einen `Update Date`-Wert vom 7. Juli haben kann, aber erst (zum Beispiel) am 13. Juli für die Installation verfügbar sein kann. Angenommen, in diesem Fall wird am 14. Juli in einem `Install`-Vorgang eine Patch-Baseline ausgeführt, die eine 7-tägige automatische Genehmigungsverzögerung angibt. Da der `Update Date`-Wert sieben Tage vor dem Ausführungsdatum liegt, werden die Patches und Updates im Paket am 14. Juli installiert. Die Installation erfolgt, obwohl erst ein Tag vergangen ist, seit das Paket für die eigentliche Installation verfügbar ist.
+ Ein Paket, das Betriebssystem- oder Anwendungs-Patches enthält, kann nach der ersten Veröffentlichung mehrmals aktualisiert werden.
+ Ein Paket kann in den AWS verwalteten Repositorys veröffentlicht, dann aber zurückgesetzt werden, wenn später Probleme damit entdeckt werden.

Bei einigen Patch-Vorgängen sind diese Faktoren möglicherweise nicht wichtig. Wenn beispielsweise eine Patch-Baseline so konfiguriert ist, dass ein Patch mit den Schweregraden `Low` und `Medium` und der Klassifizierung `Recommended` installiert wird, kann jede Verzögerung der automatischen Genehmigung nur geringe Auswirkungen auf Ihren Betrieb haben.

In Fällen, in denen das Timing kritischer Patches oder Patches mit hohem Schweregrad wichtiger ist, sollten Sie möglicherweise mehr Kontrolle darüber haben, wann Patches installiert werden. Die empfohlene Methode hierfür ist die Verwendung alternativer Patch-Quell-Repositorys anstelle der Standard-Repositorys für Patch-Vorgänge auf einem verwalteten Knoten. 

Sie können beim Erstellen einer benutzerdefinierten Patch-Baseline alternative Patch-Quell-Repositorys angeben. Für jede benutzerdefinierte Patch-Baseline können Sie Patch-Quellkonfigurationen für bis zu 20 Versionen eines unterstützten Linux-Betriebssystems angeben. Weitere Informationen finden Sie unter [So geben Sie ein alternatives Patch-Quell-Repository an (Linux)](patch-manager-alternative-source-repository.md).

# Wie Sicherheitspatches ausgewählt werden
<a name="patch-manager-selecting-patches"></a>

Das Hauptaugenmerk vonPatch Manager, einem Tool in AWS Systems Manager, liegt auf der Installation sicherheitsrelevanter Betriebssystemupdates auf verwalteten Knoten. Standardmäßig installiert Patch Manager daher nicht alle verfügbaren Patches, sondern eher eine kleinere Reihe von Patches mit Schwerpunkt auf der Sicherheit.

Standardmäßig ersetzt Patch Manager kein Paket, das in einem Paket-Repository mit Ersatzpaketen als veraltet markiert wurde mit Ersatzpaketen mit anderen Namen, es sei denn, dieser Ersatz ist für die Installation eines anderen Paket-Updates erforderlich. Stattdessen meldet und installiert Patch Manager bei Befehlen, die ein Paket aktualisieren, nur fehlende Updates für das Paket, das installiert wird, aber veraltet ist. Dies liegt daran, dass das Ersetzen eines veralteten Pakets normalerweise die Deinstallation eines vorhandenen Pakets und die Installation des Ersatzpakets erfordert. Durch das Ersetzen des veralteten Pakets könnten grundlegende Änderungen oder zusätzliche Funktionen eingeführt werden, die Sie nicht beabsichtigt hatten.

Dieses Verhalten entspricht dem `update-minimal`-Befehl von YUM und DNF, der sich eher auf Sicherheitsupdates als auf Feature-Updates konzentriert. Weitere Informationen finden Sie unter [Wie Patches installiert werden](patch-manager-installing-patches.md).

**Anmerkung**  
Wenn Sie den `ApproveUntilDate` Parameter oder `ApproveAfterDays` Parameter in einer Patch-Baseline-Regel verwenden, werden die Veröffentlichungsdaten von Patches anhand der koordinierten Weltzeit (UTC) Patch Manager ausgewertet.   
Wenn Sie beispielsweise ein Datum angeben`ApproveUntilDate`, werden Patches`2025-11-16`, die zwischen `2025-11-16T00:00:00Z` und veröffentlicht wurden`2025-11-16T23:59:59Z`, genehmigt.   
Beachten Sie, dass die Veröffentlichungsdaten von Patches, die von systemeigenen Paketmanagern auf Ihren verwalteten Knoten angezeigt werden, je nach der lokalen Zeitzone Ihres Systems unterschiedliche Zeiten anzeigen können. Für Genehmigungsberechnungen wird jedoch Patch Manager immer die UTC-Datum/Uhrzeit verwendet. Dadurch wird die Konsistenz mit den auf offiziellen Websites mit Sicherheitshinweisen veröffentlichten Patch-Veröffentlichungsdaten gewährleistet.

Für Linux-basierte Betriebssysteme, die einen Schweregrad für Patches melden, verwendet Patch Manager den vom Softwareherausgeber gemeldeten Schweregrad für den Update-Hinweis oder den einzelnen Patch. Patch Manager leitet keinen Schweregrad aus Drittquellen wie dem [Common Vulnerability Scoring System](https://www.first.org/cvss/) (CVSS) oder aus Metriken ab, die von der [National Vulnerability Database](https://nvd.nist.gov/vuln) (NVD) veröffentlicht werden.

**Anmerkung**  
Auf allen Linux-basierten Systemen, die von Patch Manager unterstützt werden, können Sie ein anderes für den verwalteten Knoten konfiguriertes Quell-Repository auswählen, typischerweise zur Installation von nicht-sicherheitsrelevanten Updates. Weitere Informationen finden Sie unter [So geben Sie ein alternatives Patch-Quell-Repository an (Linux)](patch-manager-alternative-source-repository.md).

Wählen Sie aus den folgenden Registerkarten, um zu erfahren, wie Patch Manager sicherheitsrelevante Patches für Ihr Betriebssystem auswählt.

------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]

Vorkonfigurierte Repositorys werden auf Amazon Linux 2 anders behandelt als auf Amazon Linux 2023.

Auf Amazon Linux 2 verwendet der Patch-Baseline-Server des Systems Managers vorkonfigurierte Repositorys auf dem verwalteten Knoten. Es gibt in der Regel zwei vorkonfigurierte Repositorys (Repos) auf einem Knoten:

**Auf Amazon Linux 2**
+ **Repo-ID**: `amzn2-core/2/architecture`

  **Repo-Name**: `Amazon Linux 2 core repository`
+ **Repo-ID**: `amzn2extra-docker/2/architecture`

  **Repo-Name**: `Amazon Extras repo for docker`

**Anmerkung**  
*architecture*kann x86\$164 oder (für Graviton-Prozessoren) aarch64 sein.

Wenn Sie eine Amazon Linux 2023 (AL2023) -Instance erstellen, enthält sie die Updates, die in der von AMI Ihnen ausgewählten Version AL2023 und spezifischen Version verfügbar waren. Ihre AL2023 Instance erhält beim Start nicht automatisch zusätzliche kritische und wichtige Sicherheitsupdates. Stattdessen können Sie mit der Unterstützung der Funktion *deterministische Upgrades durch versionierte Repositorys* AL2023, die standardmäßig aktiviert ist, Updates nach einem Zeitplan anwenden, der Ihren spezifischen Anforderungen entspricht. Weitere Informationen finden Sie unter [Deterministische Upgrades durch versionierte Repositories](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html) im *Benutzerhandbuch von Amazon Linux 2023*. 

Bei aktivierter AL2023 Option sieht das vorkonfigurierte Repository wie folgt aus:
+ **Repo-ID**: `amazonlinux`

  **Repository-Name**: Amazon-Linux-2023-Repository

Bei Amazon Linux 2023 (Vorschauversion) sind die vorkonfigurierten Repositories an *gesperrte Versionen* von Paket-Updates gebunden. Wenn new Amazon Machine Images (AMIs) für veröffentlicht AL2023 werden, sind sie an eine bestimmte Version gebunden. Bei Patch-Aktualisierungen ruft Patch Manager die letzte gesperrte Version des Patch-Aktualisierungs-Repositorys ab und aktualisiert dann die Pakete auf dem verwalteten Knoten basierend auf dem Inhalt dieser gesperrten Version.

**Paket-Manager**  
Amazon Linux 2 verwaltete Knoten verwenden YUM als Paket-Manager. Amazon Linux 2023 verwendet DNF als Paket-Manager. 

Beide Paket-Manager verwenden das Konzept einer *Aktualisierungsbenachrichtigung* in Form einer Datei mit dem Namen `updateinfo.xml`. Ein Update-Hinweis ist einfach eine Sammlung von Paketen, die bestimmte Probleme beheben. Alle Pakete in einem Update-Hinweis werden von Patch Manager als sicherheitsrelevant betrachtet. Einzelnen Paketen werden keine Klassifizierungen oder Schweregrade zugewiesen. Daher weist Patch Manager die Attribute eines Update-Hinweises den jeweiligen Paketen zu.

**Anmerkung**  
Wenn Sie das Kontrollkästchen **Funktionsupdates einschließen** auf der Seite **Patch-Baseline erstellen** aktivieren, können Pakete, die nicht in einer `updateinfo.xml`-Datei klassifiziert sind (oder Pakete, die eine Datei ohne korrekt formatierte Klassifizierung, Schweregrad und Datenwerte), in die vorgefilterte Patchliste aufgenommen werden. Damit ein Patch jedoch angewendet werden kann, muss er dennoch die benutzerspezifischen Patch-Baseline-Regeln erfüllen.  
Weitere Informationen zur Option **Nicht sicherheitsrelevante Updates einbeziehen** finden Sie unter [Wie Patches installiert werden](patch-manager-installing-patches.md) und [Funktionsweise von Patch-Baseline-Regeln auf Linux-basierten Systemen](patch-manager-linux-rules.md).

------
#### [  CentOS Stream ]

Der Patch-Baseline-Service des Systems Managers auf CentOS Stream verwendet vorkonfigurierte Repositorys (Repos) auf dem verwalteten Knoten. Die folgende Liste enthält Beispiele für ein fiktives CentOS 9.2 Amazon Machine Image (AMI):
+ **Repo-ID**: `example-centos-9.2-base`

  **Repo-Name**: `Example CentOS-9.2 - Base`
+ **Repo-ID**: `example-centos-9.2-extras` 

  **Repo-Name**: `Example CentOS-9.2 - Extras`
+ **Repo-ID**: `example-centos-9.2-updates`

  **Repo-Name**: `Example CentOS-9.2 - Updates`
+ **Repo-ID**: `example-centos-9.x-examplerepo`

  **Repo-Name**: `Example CentOS-9.x – Example Repo Packages`

**Anmerkung**  
Alle Updates werden von den auf dem verwalteten Knoten konfigurierten Remote-Repos heruntergeladen. Daher muss der Knoten über einen ausgehenden Zugang zum Internet verfügen, um eine Verbindung zu den Repos herzustellen, damit das Patching durchgeführt werden kann.

CentOS Stream-Knoten verwenden DNF als Paket-Manager. Der Paket-Manager verwenden das Konzept eines Update-Hinweises. Ein Update-Hinweis ist einfach eine Sammlung von Paketen, die bestimmte Probleme beheben. 

Standard-Repos von CentOS Stream werden jedoch nicht mit einem Update-Hinweis konfiguriert. Das bedeutet, dass Patch Manager Pakete auf einem Standard-CentOS Stream-Repos nicht erkennt. Um Patch Manager für die Verarbeitung von Paketen, die nicht in einem Update-Hinweis enthalten sind, zu aktivieren, müssen Sie die `EnableNonSecurity`-Markierung in den Patch-Baseline-Regeln aktivieren.

**Anmerkung**  
CentOS Stream-Update-Hinweise werden unterstützt. Repos mit Update-Hinweisen können nach dem Start heruntergeladen werden.

------
#### [ Debian Server ]

Der Systems Manager-Patch-Baseline-Service auf Debian Server verwendet vorkonfigurierte Repositorys (Repos) auf der Instance. Diese vorkonfigurierten Repos werden verwendet, um eine aktualisierte Liste der verfügbaren Paket-Upgrades abzurufen. Dazu führt Systems Manager das Äquivalent eines `sudo apt-get update`-Befehls durch. 

Pakete werden dann aus `debian-security codename`-Repos gefiltert. Das bedeutet, dass für jede Version von Debian Server, Patch Manager nur Upgrades identifiziert, die Teil des zugehörigen Repositorys für diese Version sind, und zwar wie folgt:
+  Debian Server11: `debian-security bullseye`
+ Debian Server12: `debian-security bookworm`

------
#### [ Oracle Linux ]

Der Patch-Baseline-Service des Systems Managers auf Oracle Linux verwendet vorkonfigurierte Repositorys (Repos) auf dem verwalteten Knoten. Es gibt in der Regel zwei vorkonfigurierte Repositorys (Repos) auf einem Knoten.

**Oracle Linux 7**:
+ **Repo-ID**: `ol7_UEKR5/x86_64`

  **Repo-Name**: `Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)`
+ **Repo-ID**: `ol7_latest/x86_64`

  **Repo-Name**: `Oracle Linux 7Server Latest (x86_64)` 

**Oracle Linux 8**:
+ **Repo-ID**: `ol8_baseos_latest` 

  **Repo-Name**: `Oracle Linux 8 BaseOS Latest (x86_64)`
+ **Repo-ID**: `ol8_appstream`

  **Repo-Name**: `Oracle Linux 8 Application Stream (x86_64)` 
+ **Repo-ID**: `ol8_UEKR6`

  **Repo-Name**: `Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)`

**Oracle Linux 9**:
+ **Repo-ID**: `ol9_baseos_latest` 

  **Repo-Name**: `Oracle Linux 9 BaseOS Latest (x86_64)`
+ **Repo-ID**: `ol9_appstream`

  **Repo-Name**: `Oracle Linux 9 Application Stream Packages(x86_64)` 
+ **Repo-ID**: `ol9_UEKR7`

  **Repo-Name**: `Oracle Linux UEK Release 7 (x86_64)`

**Anmerkung**  
Alle Updates werden von den auf dem verwalteten Knoten konfigurierten Remote-Repos heruntergeladen. Daher muss der Knoten über einen ausgehenden Zugang zum Internet verfügen, um eine Verbindung zu den Repos herzustellen, damit das Patching durchgeführt werden kann.

Von Oracle Linux verwaltete Knoten verwenden Yum als Paketmanager und Yum verwendet das Konzept eines Update-Hinweises in Form einer Datei namens `updateinfo.xml`. Ein Update-Hinweis ist einfach eine Sammlung von Paketen, die bestimmte Probleme beheben. Einzelnen Paketen werden keine Klassifizierungen oder Schweregrade zugewiesen. Aus diesem Grund weist Patch Manager die Attribute eines Update-Hinweises den jeweiligen Paketen zu und installiert Pakete basierend auf den Klassifizierungsfiltern, die in der Patch-Baseline angegeben sind.

**Anmerkung**  
Wenn Sie das Kontrollkästchen **Funktionsupdates einschließen** auf der Seite **Patch-Baseline erstellen** aktivieren, können Pakete, die nicht in einer `updateinfo.xml`-Datei klassifiziert sind (oder Pakete, die eine Datei ohne korrekt formatierte Klassifizierung, Schweregrad und Datenwerte), in die vorgefilterte Patchliste aufgenommen werden. Damit ein Patch jedoch angewendet werden kann, muss er dennoch die benutzerspezifischen Patch-Baseline-Regeln erfüllen.

------
#### [ AlmaLinux, RHEL, and Rocky Linux  ]

Ein AlmaLinuxRed Hat Enterprise Linux, und Rocky Linux der Systems Manager Patch Baseline Service verwendet vorkonfigurierte Repositorys (Repos) auf dem verwalteten Knoten. Es gibt in der Regel drei vorkonfigurierte Repositorys (Repos) auf einem Knoten.

Alle Updates werden von den auf dem verwalteten Knoten konfigurierten Remote-Repos heruntergeladen. Daher muss der Knoten über einen ausgehenden Zugang zum Internet verfügen, um eine Verbindung zu den Repos herzustellen, damit das Patching durchgeführt werden kann.

**Anmerkung**  
Wenn Sie das Kontrollkästchen **Funktionsupdates einschließen** auf der Seite **Patch-Baseline erstellen** aktivieren, können Pakete, die nicht in einer `updateinfo.xml`-Datei klassifiziert sind (oder Pakete, die eine Datei ohne korrekt formatierte Klassifizierung, Schweregrad und Datenwerte), in die vorgefilterte Patchliste aufgenommen werden. Damit ein Patch jedoch angewendet werden kann, muss er dennoch die benutzerspezifischen Patch-Baseline-Regeln erfüllen.

Red Hat Enterprise Linux7 verwaltete Knoten verwenden Yum als Paketmanager. AlmaLinux, Red Hat Enterprise Linux 8, und Rocky Linux verwaltete Knoten verwenden DNF als Paketmanager. Beide Paketmanager verwenden das Konzept eines Update-Hinweises als Datei namens `updateinfo.xml`. Ein Update-Hinweis ist einfach eine Sammlung von Paketen, die bestimmte Probleme beheben. Einzelnen Paketen werden keine Klassifizierungen oder Schweregrade zugewiesen. Aus diesem Grund weist Patch Manager die Attribute eines Update-Hinweises den jeweiligen Paketen zu und installiert Pakete basierend auf den Klassifizierungsfiltern, die in der Patch-Baseline angegeben sind.

RHEL 7  
Das folgende Repo ist mit IDs RHUI 2 verknüpft. RHUI 3 wurde im Dezember 2019 veröffentlicht und führte ein anderes Benennungsschema für das Yum-Repository ein. IDs Abhängig von dem RHEL-7-AMI, aus dem Sie Ihre verwalteten Knoten erstellen, müssen Sie möglicherweise Ihre Befehle aktualisieren. Weitere Informationen finden Sie unter [Repository IDs for RHEL 7 in Have AWS Changed](https://access.redhat.com/articles/4599971) im *Red Hat* Customer Portal.
+ **Repo-ID**: `rhui-REGION-client-config-server-7/x86_64`

  **Repo-Name**: `Red Hat Update Infrastructure 2.0 Client Configuration Server 7`
+ **Repo-ID**: `rhui-REGION-rhel-server-releases/7Server/x86_64`

  **Repo-Name**: `Red Hat Enterprise Linux Server 7 (RPMs)`
+ **Repo-ID**: `rhui-REGION-rhel-server-rh-common/7Server/x86_64`

  **Repo-Name**: `Red Hat Enterprise Linux Server 7 RH Common (RPMs)`

AlmaLinux, 8, RHEL 8 und Rocky Linux 8  
+ **Repo-ID**: `rhel-8-appstream-rhui-rpms`

  **Repo-Name**: `Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)`
+ **Repo-ID**: `rhel-8-baseos-rhui-rpms`

  **Repo-Name**: `Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)`
+ **Repo-ID**: `rhui-client-config-server-8`

  **Repo-Name**: `Red Hat Update Infrastructure 3 Client Configuration Server 8`

AlmaLinux 9, RHEL 9 und Rocky Linux 9  
+ **Repo-ID**: `rhel-9-appstream-rhui-rpms`

  **Repo-Name**: `Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)`
+ **Repo-ID**: `rhel-9-baseos-rhui-rpms`

  **Repo-Name**: `Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)`
+ **Repo-ID**: `rhui-client-config-server-9`

  **Repo-Name**: `Red Hat Enterprise Linux 9 Client Configuration`

------
#### [ SLES ]

Auf von SUSE Linux Enterprise Server (SLES) verwalteten Knoten erhält die ZYPP-Bibliothek die Liste der verfügbaren Patches (eine Sammlung von Paketen) von den folgenden Standorten:
+ Liste der Repositorys: `etc/zypp/repos.d/*`
+ Paketinformationen: `/var/cache/zypp/raw/*`

Von SLES verwaltete Knoten verwenden Zypper als Paketmanager und Zypper verwendet das Konzept eines Patches. Ein Patch ist einfach eine Sammlung von Paketen, die ein bestimmtes Problem beheben. Patch Manager behandelt alle Pakete, auf die in einem Patch verwiesen wird, als sicherheitsbezogen. Da einzelnen Paketen weder Klassifizierungen noch Schweregrade zugewiesen werden, weist Patch Manager den Paketen die Attribute des Patches zu, dem sie angehören.

------
#### [ Ubuntu Server ]

Der Patch-Baseline-Service des Systems Managers auf Ubuntu Server verwendet vorkonfigurierte Repositorys (Repos) auf dem verwalteten Knoten. Diese vorkonfigurierten Repos werden verwendet, um eine aktualisierte Liste der verfügbaren Paket-Upgrades abzurufen. Dazu führt Systems Manager das Äquivalent eines `sudo apt-get update`-Befehls durch. 

Pakete werden dann aus `codename-security`-Repos gefiltert, wobei der Codename für die Release-Version eindeutig ist, z. B. `trusty` für Ubuntu Server 14. Patch Manager identifiziert nur Upgrades, die Teil dieser Repos sind: 
+ Ubuntu Server 16.04 LTS: `xenial-security`
+ Ubuntu Server 18.04 LTS: `bionic-security`
+ Ubuntu Server 20.04 LTS: `focal-security`
+ Ubuntu Server 22.04 LTS (`jammy-security`)
+ Ubuntu Server 24.04 LTS (`noble-security`)
+ Ubuntu Server 25.04 (`plucky-security`)

------
#### [ Windows Server ]

Unter Microsoft Windows-Betriebssystemen ruft Patch Manager eine Liste der verfügbaren, von Microsoft über Microsoft Update veröffentlichten und automatisch auf Windows Server Update Services (WSUS) verfügbaren Updates ab.

**Anmerkung**  
Patch Manager stellt nur dann Patches für Windows Server-Betriebssystemversionen bereit, wenn diese für Patch Manager unterstützt werden. Beispiel: Patch Manager kann nicht zum Patchen von Windows RT verwendet werden.

Patch Manager überwacht kontinuierlich neue Updates in allen AWS-Region. Die Liste der verfügbaren Updates wird in jeder Region mindestens einmal pro Tag aktualisiert. Wenn die Patch-Informationen von Microsoft verarbeitet werden, entfernt Patch Manager Updates, die durch spätere Updates ersetzt wurden, aus der Patch-Liste. Daher werden nur die neuesten Updates angezeigt und zur Installation zur Verfügung gestellt. Beispiel: Wenn `KB4012214` `KB3135456` ersetzt, steht nur `KB4012214` als Update in Patch Manager zur Verfügung.

Ebenso kann Patch Manager nur Patches installieren, die zum Zeitpunkt des Patchvorgangs auf dem verwalteten Knoten verfügbar sind. Standardmäßig entfernen Windows Server 2019 und Windows Server 2022 Updates, die durch spätere Updates ersetzt werden. Wenn Sie den `ApproveUntilDate`-Parameter in einer Windows Server-Patch-Baseline verwenden, das im `ApproveUntilDate`-Parameter ausgewählte Datum jedoch *vor dem* Datum des letzten Patches liegt, tritt das folgende Szenario ein:
+ Der ersetzte Patch wurde vom Knoten entfernt und kann daher nicht mit Patch Manager installiert werden.
+ Der neueste Ersatz-Patch ist auf dem Knoten vorhanden, wurde aber zum angegebenen Datum noch nicht für die `ApproveUntilDate`-Installation freigegeben. 

Das bedeutet, dass der verwaltete Knoten die Anforderungen des Systems-Manager-Betriebs erfüllt, auch wenn ein kritischer Patch aus dem Vormonat möglicherweise nicht installiert wurde. Das gleiche Szenario kann bei Verwendung des `ApproveAfterDays`-Parameters auftreten. Aufgrund des Verhaltens von Microsoft bei abgelösten Patches ist es möglich, eine Zahl (im Allgemeinen größer als 30 Tage) festzulegen, sodass Patches für Windows Server nie installiert werden, wenn der neueste verfügbare Patch von Microsoft veröffentlicht wird, bevor die Anzahl der Tage in `ApproveAfterDays` verstrichen ist. Beachten Sie, dass dieses Systemverhalten nicht zutrifft, wenn Sie Ihre Einstellungen für das Windows-Gruppenrichtlinienobjekt (GPO) so geändert haben, dass der abgelöste Patch auf Ihren verwalteten Knoten verfügbar ist.

**Anmerkung**  
In einigen Fällen veröffentlicht Microsoft Patches für Anwendungen, die kein aktualisiertes Datum und keine aktualisierte Uhrzeit angeben. In diesen Fällen wird ein aktualisiertes Datum und eine Uhrzeit von `01/01/1970` standardmäßig angegeben.

------

# So geben Sie ein alternatives Patch-Quell-Repository an (Linux)
<a name="patch-manager-alternative-source-repository"></a>

Wenn Sie die auf einem verwalteten Knoten konfigurierten Standardrepositorys für Patch-Operationen verwenden Patch Manager AWS Systems Manager, sucht ein Tool in nach sicherheitsrelevanten Patches oder installiert diese. Dies ist das Standardverhalten für Patch Manager. Ausführliche Informationen darüber, wie Patch Manager Sicherheits-Patches auswählt und installiert, finden Sie unter [Wie Sicherheitspatches ausgewählt werden](patch-manager-selecting-patches.md).

Sie können auf Linux-Systemen jedoch auch mithilfe von Patch Manager Patches installieren, die nicht auf Sicherheit bezogen sind oder die sich in einem anderen als dem Standard-Quell-Repository befinden, das in dem verwalteten Knoten konfiguriert ist. Sie können beim Erstellen einer benutzerdefinierten Patch-Baseline alternative Patch-Quell-Repositorys angeben. Für jede benutzerdefinierte Patch-Baseline können Sie Patch-Quellkonfigurationen für bis zu 20 Versionen eines unterstützten Linux-Betriebssystems angeben. 

Angenommen, Ihre Ubuntu Server-Flotte beinhaltet Ubuntu Server 25.04-verwaltete Knoten. In diesem Fall können Sie alternative Repositorys für jede Version in derselben benutzerdefinierten Patch-Baseline angeben. Geben Sie für jede Version einen Namen, die Version und den Typ des Betriebssystems (Produkt) und eine Repository-Konfiguration an. Sie können auch ein einziges alternatives Quell-Repository angeben, das für alle Versionen eines unterstützten Betriebssystems gilt.

**Anmerkung**  
Wenn Sie eine benutzerdefinierte Patch-Baseline ausführen, die alternative Patch-Repositorys für einen verwalteten Knoten angeben, werden diese Repositorys dadurch nicht zum neuen Standard-Repository auf dem Betriebssystem. Nach Abschluss der Patching-Operation bleiben die zuvor definierten Standard-Repositorys für das Betriebssystem des Knoten als Standard erhalten.

Eine Liste mit Beispielszenarien zur Verwendung dieser Option finden Sie weiter [Anwendungsbeispiele für alternative Patch-Quell-Repositorys](#patch-manager-alternative-source-repository-examples) unten in diesem Thema.

Weitere Informationen zu Standard- und benutzerdefinierten Patch-Baselines finden Sie unter [Vordefinierte und benutzerdefinierte Patch-Baselines](patch-manager-predefined-and-custom-patch-baselines.md).

**Beispiel: Verwenden der Konsole**  
Um alternative Patch-Quell-Repositorys anzugeben, wenn Sie in der Systems Manager-Konsole arbeiten, verwenden Sie den Abschnitt **Patch sources** auf der Seite **Create patch baseline**. Weitere Informationen zur Verwendung der Optionen in **Patch sources (Patch-Quellen)** finden Sie unter [So erstellen Sie eine benutzerdefinierte Patch-Baseline für Linux](patch-manager-create-a-patch-baseline-for-linux.md).

**Beispiel: Verwendung des AWS CLI**  
Ein Beispiel für die Verwendung der Option `--sources` mit der AWS Command Line Interface (AWS CLI) finden Sie in [Erstellen einer Patch-Baseline mit benutzerdefinierten Repositorys für verschiedene Betriebssystemversionen](patch-manager-cli-commands.md#patch-manager-cli-commands-create-patch-baseline-mult-sources).

**Topics**
+ [Wichtige Überlegungen für alternative Repositorys](#alt-source-repository-important)
+ [Anwendungsbeispiele für alternative Patch-Quell-Repositorys](#patch-manager-alternative-source-repository-examples)

## Wichtige Überlegungen für alternative Repositorys
<a name="alt-source-repository-important"></a>

Beachten Sie die folgenden Punkte, wenn Sie planen, in Ihrer Patching-Strategie alternative Patch-Repositorys zu verwenden.

**Erzwingen Sie Überprüfungen von Repo-Updates (YUM und DNF)**  
Eine Standardkonfiguration für einen Paketmanager auf einer Linux-Distribution kann so eingestellt sein, dass ein nicht erreichbares Paket-Repository übersprungen wird, wenn keine Verbindung zum Repository hergestellt werden kann. Um die Überprüfung des Repository-Updates `skip_if_unavailable=False` zu erzwingen, fügen Sie es der Repository-Konfiguration hinzu.

Weitere Informationen zur Option `skip_if_available` finden Sie unter [Konnektivität zur Patch-Quelle](patch-manager-prerequisites.md#source-connectivity).

**Nur angegebene Repositorys werden für das Einspielen von Patches verwendet.**  
Angeben von alternativen Repositorys bedeutet nicht das Angeben *zusätzlicher* Repositorys. Sie können wählen, andere Repositorys als die auf einem verwalteten Knoten als Standardwerte konfigurierten festzulegen. Sie müssen jedoch auch die Standard-Repositorys als Teil der alternativen Patch-Quell-Konfiguration angeben, wenn Sie möchten, dass deren Updates übernommen werden.

Beispielsweise sind die Standard-Repositorys auf von Amazon Linux 2 verwalteten Knoten `amzn2-core` und `amzn2extra-docker`. Wenn Sie das Repository "Extra Packages for Enterprise Linux (EPEL)" in Ihre Patching-Operationen einschließen möchten, müssen Sie alle drei Repositorys als alternative Repositorys angeben.

**Anmerkung**  
Wenn Sie eine benutzerdefinierte Patch-Baseline ausführen, die alternative Patch-Repositorys für einen verwalteten Knoten angeben, werden diese Repositorys dadurch nicht zum neuen Standard-Repository auf dem Betriebssystem. Nach Abschluss der Patching-Operation bleiben die zuvor definierten Standard-Repositorys für das Betriebssystem des Knoten als Standard erhalten.

**Das Patching-Verhalten für YUM-basierte Distributionen hängt vom updateinfo.xml-Manifest ab**  
Wenn Sie alternative Patch-Repositorys für YUM-basierte Distributionen festlegen, z. B. Amazon Linux 2 oder Red Hat Enterprise Linux, hängt das Patching-Verhalten davon ab, ob das Repository ein Update-Manifest in Form einer vollständig und korrekt formatierten `updateinfo.xml`-Datei enthält. Diese Datei gibt das Release-Datum, Klassifizierungen und Schweregrade der verschiedenen Pakete an. Jede der folgenden Optionen wirkt sich auf das Patching-Verhalten aus:
+ Wenn Sie nach **Klassifizierung** und **Schweregrad** filtern, diese aber nicht in `updateinfo.xml` angegeben sind, wird das Paket nicht in Filter aufgenommen. Dies bedeutet auch, dass Pakete ohne eine `updateinfo.xml`-Datei werden nicht in das Patching eingeschlossen werden.
+ Wenn Sie nach filtern **ApprovalAfterDays**, aber das Veröffentlichungsdatum des Pakets nicht im Format Unix Epoch ist (oder kein Veröffentlichungsdatum angegeben ist), wird das Paket nicht in den Filter aufgenommen.
+ Eine Ausnahme besteht, wenn Sie das Kontrollkästchen **Genehmigte Patches umfassen nicht sicherheitsrelevante Updates** auf der Seite **Patch-Baseline erstellen** aktivieren. In diesem Fall *werden* Pakete ohne eine `updateinfo.xml`-Datei (oder die diese Datei ohne ordnungsgemäß formatierte Werte für **Klassifizierung**, **Schweregrad** und **Datum** enthalten) in die vorgefilterte Liste der Patches aufgenommen. (Diese müssen nach wie vor die übrigen Anforderungen Patch-Baseline Regel erfüllen, damit sie installiert werden.)

## Anwendungsbeispiele für alternative Patch-Quell-Repositorys
<a name="patch-manager-alternative-source-repository-examples"></a>

**Beispiel 1: Nicht sicherheitsrelevante Updates für Ubuntu Server**  
Sie verwenden bereitsPatch Manager, um Sicherheitspatches auf einer Flotte von Ubuntu Server verwalteten Knoten mithilfe der von AWS Ihnen bereitgestellten vordefinierten Patch-Baseline zu installieren. `AWS-UbuntuDefaultPatchBaseline` Sie können eine neue Patch-Baseline erstellen, die auf diesem Standard basiert, aber in den Genehmigungsregeln angeben, dass nicht auf die Sicherheit bezogene Updates, die Teil der Standardverteilung sind, ebenfalls installiert werden sollen. Wenn diese Patch-Baseline für Ihre Knoten ausgeführt wird, werden sowohl sicherheitsbezogene als auch nicht-sicherheitsbezogene Patches angewendet. Sie können auch auswählen, dass nicht sicherheitsbezogene Patches in den Patch-Ausnahmen, die Sie für eine Baseline angeben, genehmigt werden.

**Beispiel 2: Personal Package Archives (PPA) für Ubuntu Server**  
Auf Ihren von Ubuntu Server verwalteten Knoten wird Software ausgeführt, die über ein [Personal Package Archives (PPA) für Ubuntu](https://launchpad.net/ubuntu/+ppas) verteilt wird. In diesem Fall erstellen Sie eine Patch-Baseline, die ein PPA-Repository angibt, das Sie auf dem verwalteten Knoten als das Quell-Repository für die Patch-Operation konfiguriert haben. Führen Sie anschließend mithilfe von Run Command das Patch-Baseline-Dokument auf den Knoten aus.

**Beispiel 3: Interne Firmenanwendungen in unterstützten Amazon-Linux-Versionen**  
Sie müssen auf Ihren von Amazon Linux verwalteten Knoten einige Anwendungen ausführen, die für die Compliance gesetzlicher Vorschriften und Branchenstandards erforderlich sind. Sie können ein Repository für diese Anwendungen auf den Knoten konfigurieren, mit YUM die Anwendungen erstmals installieren und eine neue Patch-Baseline aktualisieren oder erstellen, um dieses neue Unternehmens-Repository hinzuzufügen. Anschließend können Sie mit Run Command das Dokument `AWS-RunPatchBaseline` mit der Option `Scan` ausführen, um zu prüfen, ob das Unternehmenspaket unter den installierten Paketen aufgelistet und auf dem verwalteten Knoten aktuell ist. Wenn es nicht aktuell ist, können Sie das Dokument mithilfe der Option `Install` erneut ausführen, um die Anwendungen zu aktualisieren. 

# Wie Patches installiert werden
<a name="patch-manager-installing-patches"></a>

Patch Manager, ein Tool in AWS Systems Manager, verwendet den im Betriebssystem integrierten Paketmanager, um Updates auf verwalteten Knoten zu installieren. Beispielsweise verwendet es die Windows Update API `DNF` auf Windows Server und unter Amazon Linux 2023. Patch Manager berücksichtigt bestehende Paketmanager- und Repository-Konfigurationen auf den Knoten, einschließlich Einstellungen wie Repository-Status URLs, Spiegelung, GPG-Überprüfung und Optionen wie`skip_if_unavailable`.

Patch Manager installiert kein neues Paket, das ein veraltetes Paket ersetzt, das derzeit installiert ist. (Ausnahmen: Das neue Paket hängt davon ab, ob ein anderes Paket-Update installiert wird, oder das neue Paket hat denselben Namen wie das veraltete Paket.) Stattdessen meldet und installiert Patch Manager verfügbare Updates für installierte Pakete. Dieser Ansatz trägt dazu bei, unerwartete Änderungen an der Systemfunktionalität zu verhindern, die auftreten können, wenn ein Paket ein anderes ersetzt.

Wenn Sie ein veraltetes Paket deinstallieren und dessen Ersatz installieren müssen, müssen Sie möglicherweise ein benutzerdefiniertes Skript verwenden oder Paket-Manager-Befehle außerhalb der Standardvorgänge von Patch Manager verwenden.

Wählen Sie aus den folgenden Registerkarten, um zu erfahren, wie Patch Manager Patches auf einem Betriebssystem installiert.

------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]

Auf von Amazon Linux 2 und Amazon Linux 2023 verwalteten Knoten sieht der Workflow der Patch-Installation wie folgt aus:

1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung. 

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

   Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. 

   Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) verworfen wurden oder wenn keine in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

1. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.

1. Die YUM-Aktualisierungs-API (Amazon Linux 2) oder die DNF-Aktualisierungs-API (Amazon Linux 2023) wird wie folgt auf genehmigte Patches angewendet:
   + Für vordefinierte Standard-Patch-Baselines, die von AWS bereitgestellt werden, werden nur die in `updateinfo.xml` angegebenen Patches angewendet (nur Sicherheitsupdates). Dies liegt daran, dass das Kontrollkästchen **Funktionsupdates einschließen** nicht aktiviert ist. Die vordefinierten Baselines entsprechen einer benutzerdefinierten Baseline mit folgenden Eigenschaften:
     + Das Kontrollkästchen **Funktionsupdates einschließen** ist nicht aktiviert
     + Eine Liste des SCHWEREGRADE von `[Critical, Important]`
     + Eine Liste der KLASSIFIZIERUNGEN von `[Security, Bugfix]`

     Für Amazon Linux 2 lautet der entsprechende YUM-Befehl für diesen Workflow wie folgt:

     ```
     sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
     ```

     Für Amazon Linux 2023 lautet der entsprechende DNF-Befehl für diesen Workflow wie folgt:

     ```
     sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y
     ```

     Wenn das Kontrollkästchen **Funktionsupdates einschließen** aktiviert ist, werden alle Patches angewendet (Sicherheits- und Funktionsupdates), die in `updateinfo.xml` und nicht in `updateinfo.xml` sind.

     Für Amazon Linux 2, wenn eine Baseline mit **Funktionsupdates einschließen** ausgewählt ist, und die eine SCHWEREGRAD-Liste von `[Critical, Important]` und eine KLASSIFIKATION-Liste von `[Security, Bugfix]` hat, lautet der entsprechende YUM-Befehl:

     ```
     sudo yum update --security --sec-severity=Critical,Important --bugfix -y
     ```

     Für Amazon Linux 2023 lautet der entsprechende DNF-Befehl wie folgt:

     ```
     sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y
     ```
**Anmerkung**  
Neue Pakete, die veraltete Pakete mit anderen Namen ersetzen, werden installiert, wenn Sie diese `yum`- oder `dnf`-Befehle außerhalb von Patch Manager ausführen. Sie werden jedoch *nicht* mit den entsprechenden Patch Manager-Vorgängen installiert.

**Zusätzliche Patchdetails für Amazon Linux 2023**  
Support für den Schweregrad „Keine“  
Amazon Linux 2023 unterstützt auch den Patch-Schweregrad `None`, der vom DNF-Paket-Manager erkannt wird.   
Support für den Schweregrad „Mittel“  
Für Amazon Linux 2023 entspricht ein Patch-Schweregrad von `Medium` einem Schweregrad von `Moderate`, der möglicherweise in einigen externen Repositorys definiert ist. Wenn Sie Patches mit dem `Medium`-Schweregrad in die Patch-Baseline aufnehmen, werden auch Patches mit dem `Moderate`-Schweregrad von externen Patches auf den Instances installiert.  
Wenn Sie Konformitätsdaten mit der API-Aktion [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) abfragen, werden beim Filtern nach dem Schweregrad `Medium` Patches mit den Schweregraden `Medium` und `Moderate` gemeldet.  
Transitive Abhängigkeitsbehandlung für Amazon Linux 2023  
Für Amazon Linux 2023 installiert Patch Manager möglicherweise andere Versionen von transitiven Abhängigkeiten als die entsprechenden `dnf`-Befehle install. Transitive Abhängigkeiten sind Pakete, die automatisch installiert werden, um die Anforderungen anderer Pakete zu erfüllen (Abhängigkeiten von Abhängigkeiten).   
`dnf upgrade-minimal --security` installiert beispielsweise die *Minimalversionen* transitiver Abhängigkeiten, die zur Lösung bekannter Sicherheitsprobleme erforderlich sind, und Patch Manager installiert gleichzeitig die ** neuesten verfügbaren Versionen derselben transitiven Abhängigkeiten.

1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

**Anmerkung**  
Eine Standardkonfiguration für einen Paketmanager auf einer Linux-Distribution könnte so eingestellt sein, dass ein Paket-Repository, das nicht erreichbar ist, ohne Fehler übersprungen wird. In solchen Fällen wird der entsprechende Patchvorgang ohne Installation von Updates aus dem Projektarchiv fortgesetzt und erfolgreich abgeschlossen. Um Repository-Updates zu erzwingen, fügen Sie `skip_if_unavailable=False` es der Repository-Konfiguration hinzu.  
Weitere Informationen zur Option `skip_if_available` finden Sie unter [Konnektivität zur Patch-Quelle](patch-manager-prerequisites.md#source-connectivity).

------
#### [ CentOS Stream ]

Auf von CentOS Stream verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:

1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

   Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung. 

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

   Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. 

   Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) verworfen wurden oder wenn keine in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

1. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.

1. Das DNF-Update auf CentOS Stream wird auf genehmigte Patches angewendet.
**Anmerkung**  
Für CentOS Stream installiert Patch Manager möglicherweise andere Versionen transitiver Abhängigkeiten als die entsprechenden `dnf`-Befehle install. Transitive Abhängigkeiten sind Pakete, die automatisch installiert werden, um die Anforderungen anderer Pakete zu erfüllen (Abhängigkeiten von Abhängigkeiten).   
`dnf upgrade-minimal ‐‐security` installiert beispielsweise die *Minimalversionen* transitiver Abhängigkeiten, die zur Lösung bekannter Sicherheitsprobleme erforderlich sind, und Patch Manager installiert gleichzeitig die *neuesten verfügbaren Versionen* derselben transitiven Abhängigkeiten.

1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ Debian Server ]

Auf Debian Server-Instances sieht der Patch-Installations-Workflow wie folgt aus:

1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

1. Wenn eine Aktualisierung für `python3-apt` (eine Python-Bibliotheks-Schnittstelle zu `libapt`) verfügbar ist, wird es auf die neueste Version aktualisiert. (Dieses nicht sicherheitsrelevante Paket wird aktualisiert, auch wenn Sie die Option **Mit nicht sicherheitsrelevanten Updates** nicht ausgewählt haben.)

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung. 

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren. 
**Anmerkung**  
Da es nicht möglich ist, die Veröffentlichungstermine von Update-Paketen für Debian Server zuverlässig zu bestimmen, werden die Optionen für die automatische Genehmigung für dieses Betriebssystem nicht unterstützt.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

   Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. 

   Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.
**Anmerkung**  
Für Debian Server sind Patch-Kandidaten-Versionen auf Patches beschränkt, die in `debian-security` enthalten sind.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) verworfen wurden oder wenn keine in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

1. Die APT-Bibliothek wird verwendet, um Upgrades für Pakete durchzuführen.
**Anmerkung**  
Patch Manager unterstützt nicht die Verwendung der `Pin-Priority`-APT-Option, um Paketen Prioritäten zuzuweisen. Patch Manager aggregiert verfügbare Updates aus allen aktivierten Repositorys und wählt das neueste Update aus, das der Baseline für jedes installierte Paket entspricht.

1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ macOS ]

Auf von macOS verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:

1. Die `/Library/Receipts/InstallHistory.plist`-Eigenschaft ist ein Datensatz der Software, die mit den `softwareupdate`- und `installer`-Paketmanagern installiert und aktualisiert wurde. Unter Verwendung der`pkgutil`-Befehlszeilen-Tool (für `installer`) und des `softwareupdate`-Paketmanagers werden CLI-Befehle ausgeführt, um diese Liste zu analysieren. 

   Für `installer` umfasst die Antwort auf die CLI-Befehle Details zu `package name`, `version`, `volume`, `location` und `install-time`, aber nur der `package name` und die `version` werden von Patch Manager verwendet.

   Für `softwareupdate` umfasst die Antwort auf die CLI-Befehle den Paketnamen (`display name`),`version` und`date`, aber nur der Paketname und die Version werden vom Patch Manager verwendet.

   Für Brew and Brew Cask unterstützt Homebrew seine Befehle, die unter dem Root-Benutzer ausgeführt werden, nicht. Darum fragt Patch Manager entweder als Eigentümer des Homebrew-Verzeichnisses oder als gültiger Benutzer,der zur Eigentümergruppe des Homebrew-Verzeichnisses gehört, Homebrew–Befehle ab und führt sie aus. Die Befehle sind ähnlich wie `softwareupdate` und `installer` und werden durch einen Python-Subprozess ausgeführt, um Paketdaten zu sammeln. Die Ausgabe wird dann analysiert, um Paketnamen und -versionen zu identifizieren.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung. 

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) verworfen wurden oder wenn keine in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

1. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.

1. Ruft die entsprechende Paket-CLI auf dem verwalteten Knoten auf, um genehmigte Patches wie folgt zu verarbeiten:
**Anmerkung**  
`installer` fehlt die Funktion, um nach Updates zu suchen und sie zu installieren. Daher meldet Patch Manager für `installer` nur, welche Pakete installiert sind. Das Ergebnis: `installer`-Pakete werden nie als `Missing` gemeldet.
   + Für vordefinierte Standard-Patch-Baselines, die von AWS bereitgestellt werden, und für benutzerdefinierte Patch-Baselines, bei denen das Kästchen **Funktionsupdates einschließen** *nicht* ausgewählt wurde, werden nur Sicherheitsupdates angewendet.
   + Bei benutzerdefinierten Patch-Baselines, bei denen das Kästchen **Funktionsupdates einschließen** *aktiviert* ist, werden sowohl Sicherheits- als auch Funktionsupdates angewendet.

1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ Oracle Linux ]

Auf von Oracle Linux verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:

1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung. 

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

   Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. 

   Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) verworfen wurden oder wenn keine in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

1. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.

1. Auf von Version 7 verwalteten Knoten wird die YUM-Update-API wie folgt auf genehmigte Patches angewendet:
   + Für vordefinierte Standard-Patch-Baselines, die von AWS bereitgestellt werden, und für benutzerdefinierte Patch-Baselines, bei denen das Kästchen **Funktionsupdates einschließen** *nicht* ausgewählt wurde, werden nur Patches, die in `updateinfo.xml` angegeben sind (nur Sicherheitsupdates), angewendet.

     Der entsprechende Yum-Befehl für diesen Workflow lautet:

     ```
     sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y
     ```
   + Bei benutzerdefinierten Patch-Baselines, bei denen das Kästchen **Funktionsupdates einschließen** *aktiviert* ist, werden sowohl Patches aus der Datei `updateinfo.xml` als auch solche, die nicht in `updateinfo.xml` enthalten sind, angewendet (sowohl Sicherheits- als auch Funktionsupdates).

     Der entsprechende Yum-Befehl für diesen Workflow lautet:

     ```
     sudo yum update --security --bugfix -y
     ```

     Auf von Version 8 und 9 verwalteten Knoten wird die DNF-Update-API wie folgt auf genehmigte Patches angewendet:
     + Für vordefinierte Standard-Patch-Baselines, die von bereitgestellt werden AWS, und für benutzerdefinierte Patch-Baselines, bei denen das Kontrollkästchen **Nicht sicherheitsrelevante Updates einbeziehen** *nicht* aktiviert ist, `updateinfo.xml` werden nur die in angegebenen Patches angewendet (nur Sicherheitsupdates).

       Der entsprechende Yum-Befehl für diesen Workflow lautet:

       ```
       sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important
       ```
**Anmerkung**  
Für Oracle Linux installiert Patch Manager möglicherweise andere Versionen von transitiven Abhängigkeiten als die entsprechenden `dnf`-Befehle install. Transitive Abhängigkeiten sind Pakete, die automatisch installiert werden, um die Anforderungen anderer Pakete zu erfüllen (Abhängigkeiten von Abhängigkeiten).   
`dnf upgrade-minimal --security` installiert beispielsweise die *Minimalversionen* transitiver Abhängigkeiten, die zur Lösung bekannter Sicherheitsprobleme erforderlich sind, und Patch Manager installiert gleichzeitig die *neuesten verfügbaren Versionen* derselben transitiven Abhängigkeiten.
     + Bei benutzerdefinierten Patch-Baselines, bei denen das Kästchen **Funktionsupdates einschließen** *aktiviert* ist, werden sowohl Patches aus der Datei `updateinfo.xml` als auch solche, die nicht in `updateinfo.xml` enthalten sind, angewendet (sowohl Sicherheits- als auch Funktionsupdates).

       Der entsprechende Yum-Befehl für diesen Workflow lautet:

       ```
       sudo dnf upgrade --security --bugfix
       ```
**Anmerkung**  
Neue Pakete, die veraltete Pakete mit anderen Namen ersetzen, werden installiert, wenn Sie diese `yum`- oder `dnf`-Befehle außerhalb von Patch Manager ausführen. Sie werden jedoch *nicht* mit den entsprechenden Patch Manager-Vorgängen installiert.

1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

**Anmerkung**  
Eine Standardkonfiguration für einen Paketmanager auf einer Linux-Distribution kann so eingestellt sein, dass ein Paket-Repository, das nicht erreichbar ist, ohne Fehler übersprungen wird. In solchen Fällen wird der entsprechende Patchvorgang ohne Installation von Updates aus dem Projektarchiv fortgesetzt und erfolgreich abgeschlossen. Um Repository-Updates zu erzwingen, fügen Sie `skip_if_unavailable=False` es der Repository-Konfiguration hinzu.  
Weitere Informationen zur Option `skip_if_available` finden Sie unter [Konnektivität zur Patch-Quelle](patch-manager-prerequisites.md#source-connectivity).

------
#### [ AlmaLinux, RHEL, and Rocky Linux  ]

Auf AlmaLinuxRed Hat Enterprise Linux, und Rocky Linux verwalteten Knoten sieht der Arbeitsablauf für die Patch-Installation wie folgt aus:

1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung. 

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

   Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. 

   Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) verworfen wurden oder wenn keine in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

1. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.

1. Die YUM-Update-API (auf RHEL 7) oder die DNF-Update-API (auf AlmaLinux 8 und 9, RHEL 8, 9 und 10 sowie Rocky Linux 8 und 9) wird gemäß den folgenden Regeln auf genehmigte Patches angewendet:

    

**Szenario 1: Nicht sicherheitsrelevante Updates ausgeschlossen**
   + **Gilt für**: Vordefinierte Standard-Patch-Baselines, die von bereitgestellt werden, AWS und benutzerdefinierte Patch-Baselines.
   + Das Kontrollkästchen **Funktionsupdates einschließen** ist *nicht* aktiviert
   + **Angewendete Patches**: Die unter `updateinfo.xml` (nur Sicherheitsupdates) angegebenen Patches werden *nur* angewendet, wenn sie beide der Patch-Baseline-Konfiguration entsprechen und sich in den konfigurierten Repositorys befinden.

     In einigen Fällen ist ein in `updateinfo.xml` spezifizierter Patch möglicherweise nicht mehr in einem konfigurierten Repository verfügbar. Konfigurierte Repositorys verfügen normalerweise nur über die neueste Version eines Patches, bei dem es sich um einen kumulativen Rollup aller vorherigen Updates handelt. Die neueste Version entspricht jedoch möglicherweise nicht den Patch-Baseline-Regeln und wird beim Patchen nicht berücksichtigt.
   + **Befehle**: Für RHEL 7 lautet der entsprechende YUM-Befehl für diesen Workflow wie folgt: 

     ```
     sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
     ```

     Für AlmaLinux, RHEL 8 undRocky Linux, lauten die entsprechenden dnf-Befehle für diesen Workflow:

     ```
     sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \
     sudo dnf update-minimal --sec-severity=Important --bugfix -y
     ```
**Anmerkung**  
For AlmaLinuxRHEL, und Rocky Linux Rocky Linux installiert Patch Manager möglicherweise andere Versionen von transitiven Abhängigkeiten als die entsprechenden `dnf` Befehle install. Transitive Abhängigkeiten sind Pakete, die automatisch installiert werden, um die Anforderungen anderer Pakete zu erfüllen (Abhängigkeiten von Abhängigkeiten).   
`dnf upgrade-minimal --security` installiert beispielsweise die *Minimalversionen* transitiver Abhängigkeiten, die zur Lösung bekannter Sicherheitsprobleme erforderlich sind, und Patch Manager installiert gleichzeitig die *neuesten verfügbaren Versionen* derselben transitiven Abhängigkeiten.

**Szenario 2: Nicht sicherheitsrelevante Updates enthalten**
   + **Gilt für**: Benutzerdefinierte Patch-Baselines.
   + Das Kontrollkästchen **Funktionsupdates einschließen** ist aktiviert.
   + **Angewendete Patches**: Patches in `updateinfo.xml` *und* nicht in `updateinfo.xml` werden angewendet (Sicherheits- und andere Updates).
   + **Befehle**: Für RHEL 7 lautet der entsprechende YUM-Befehl für diesen Workflow wie folgt:

     ```
     sudo yum update --security --bugfix -y
     ```

     Für AlmaLinux 8 und 9, RHEL 8 und 9 sowie Rocky Linux 8 und 9 lautet der entsprechende dnf-Befehl für diesen Workflow:

     ```
     sudo dnf update --security --bugfix -y
     ```
**Anmerkung**  
Neue Pakete, die veraltete Pakete mit anderen Namen ersetzen, werden installiert, wenn Sie diese `yum`- oder `dnf`-Befehle außerhalb von Patch Manager ausführen. Sie werden jedoch *nicht* mit den entsprechenden Patch Manager-Vorgängen installiert.

1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

**Anmerkung**  
Eine Standardkonfiguration für einen Paketmanager auf einer Linux-Distribution könnte so eingestellt sein, dass ein Paket-Repository, das nicht erreichbar ist, ohne Fehler übersprungen wird. In solchen Fällen wird der entsprechende Patchvorgang ohne Installation von Updates aus dem Projektarchiv fortgesetzt und erfolgreich abgeschlossen. Um Repository-Updates zu erzwingen, fügen Sie `skip_if_unavailable=False` es der Repository-Konfiguration hinzu.  
Weitere Informationen zur Option `skip_if_available` finden Sie unter [Konnektivität zur Patch-Quelle](patch-manager-prerequisites.md#source-connectivity).

------
#### [ SLES ]

Auf von SUSE Linux Enterprise Server (SLES) verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:

1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung. 

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

   Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. 

   Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) verworfen wurden oder wenn keine in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

1. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.

1. Die Zypper-Update-API wird auf genehmigte Patches angewendet.

1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ Ubuntu Server ]

Auf von Ubuntu Server verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:

1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.

1. Wenn eine Aktualisierung für `python3-apt` (eine Python-Bibliotheks-Schnittstelle zu `libapt`) verfügbar ist, wird es auf die neueste Version aktualisiert. (Dieses nicht sicherheitsrelevante Paket wird aktualisiert, auch wenn Sie die Option **Mit nicht sicherheitsrelevanten Updates** nicht ausgewählt haben.)

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung. 

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren. 
**Anmerkung**  
Da es nicht möglich ist, die Veröffentlichungsdaten von Updatepaketen für Ubuntu Server zuverlässig zu bestimmen, werden die Optionen für die automatische Genehmigung für dieses Betriebssystem nicht unterstützt.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

   Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. 

   Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.
**Anmerkung**  
Für jede Version von Ubuntu Server sind die Patchkandidatenversionen wie folgt auf Patches beschränkt, die Teil des zugehörigen Repositorys für diese Version sind:  
Ubuntu Server 16.04 LTS: `xenial-security`
Ubuntu Server 18.04 LTS: `bionic-security`
Ubuntu Server 20.04 LTS): `focal-security`
Ubuntu Server 22.04 LTS: `jammy-security`
Ubuntu Server 24.04 LTS (`noble-security`)
Ubuntu Server 25.04 (`plucky-security`)

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) verworfen wurden oder wenn keine in [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.

1. Wenden Sie [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.

1. Die APT-Bibliothek wird verwendet, um Upgrades für Pakete durchzuführen.
**Anmerkung**  
Patch Manager unterstützt nicht die Verwendung der `Pin-Priority`-APT-Option, um Paketen Prioritäten zuzuweisen. Patch Manager aggregiert verfügbare Updates aus allen aktivierten Repositorys und wählt das neueste Update aus, das der Baseline für jedes installierte Paket entspricht.

1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ Windows Server ]

Wenn eine Patch-Operation auf einem von Windows Server verwalteten Knoten durchgeführt wird, fordert die Instance einen Snapshot der entsprechenden Patch-Baseline von Systems Manager an. Dieser Snapshot enthält die Liste aller in der Patch-Baseline verfügbaren Updates, die für die Bereitstellung genehmigt wurden. Diese Liste der Updates wird an die Windows-Update-API gesendet, die festlegt, welche Updates für den verwalteten Knoten zutreffen, und diese bei Bedarf installiert. Windows erlaubt nur die Installation der neuesten verfügbaren Version einer KB. Patch Manager installiert die neueste Version einer KB, wenn sie oder eine frühere Version der KB mit der angewendeten Patch-Baseline übereinstimmt. Wenn Updates installiert sind, wird der verwaltete Knoten danach so oft wie nötig neu gestartet, bis alle erforderlichen Patches abgeschlossen sind. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).) Die Zusammenfassung des Patch-Vorgangs finden Sie in der Ausgabe der Run Command-Anfrage. Zusätzliche Protokolle finden Sie auf dem verwalteten Knoten im `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs`-Ordner.

Da die Windows Update-API zum Herunterladen und Installieren verwendet wird KBs, werden alle Gruppenrichtlinieneinstellungen für Windows Update berücksichtigt. Für die Verwendung von Patch Manager sind keine Gruppenrichtlinien-Einstellungen erforderlich. Allerdings werden alle definierten Einstellungen angewendet, wie etwa die Weiterleitung von verwalteten Knoten an einen Windows Server Update Services (WSUS)-Server.

**Anmerkung**  
Standardmäßig lädt Windows alles KBs von der Windows Update-Website von Microsoft herunter, da die Windows Update-API Patch Manager verwendet wird, um den Download und die Installation von voranzutreiben KBs. Der verwaltete Knoten muss daher die Website von Microsoft Windows Update erreichen können. Andernfalls tritt ein Fehler bei der Patch-Operation auf. Alternativ können Sie einen WSUS-Server als KB-Repository konfigurieren und Ihre verwalteten Knoten so konfigurieren, dass sie den WSUS-Server anvisieren, anstatt Gruppenrichtlinien zu verwenden.  
Patch Managerverweist möglicherweise auf KB, IDs wenn benutzerdefinierte Patch-Baselines für erstellt werdenWindows Server, z. B. wenn eine Liste **zulässiger Patches** oder **abgelehnter Patches** in der Basiskonfiguration enthalten ist. Nur Updates, denen in Microsoft Windows Update oder einem WSUS-Server eine KB-ID zugewiesen wurde, werden von Patch Manager installiert. Updates, denen eine KB-ID fehlt, sind nicht in den Patchvorgängen enthalten.   
Informationen zum Erstellen benutzerdefinierter Patch-Baselines finden Sie in den folgenden Themen:  
 [Erstellen einer benutzerdefinierten Patch-Baseline für Windows Server](patch-manager-create-a-patch-baseline-for-windows.md)
 [Erstellen einer Patch-Baseline (CLI)](patch-manager-create-a-patch-baseline-for-windows.md)
[Paketnamen-Formate für Windows-Betriebssysteme](patch-manager-approved-rejected-package-name-formats.md#patch-manager-approved-rejected-package-name-formats-windows)

------

# Funktionsweise von Patch-Baseline-Regeln auf Linux-basierten Systemen
<a name="patch-manager-linux-rules"></a>

Die Regeln in einer Patch-Baseline für Linux-Verteilungen funktionieren je nach Verteilungstyp unterschiedlich. Im Gegensatz zu Patch-Updates auf Windows Server verwalteten Knoten werden Regeln auf jedem Knoten ausgewertet, um die konfigurierten Repos auf der Instanz zu berücksichtigen. Patch Manager, ein Tool in AWS Systems Manager, verwendet den systemeigenen Paketmanager, um die Installation von Patches voranzutreiben, die von der Patch-Baseline genehmigt wurden.

Für Linux-basierte Betriebssysteme, die einen Schweregrad für Patches melden, verwendet Patch Manager den vom Software-Publisher gemeldeten Schweregrad für den Update-Hinweis oder den einzelnen Patch. Patch Manager leitet keinen Schweregrad aus Drittquellen wie dem [Common Vulnerability Scoring System](https://www.first.org/cvss/) (CVSS) oder aus Metriken ab, die von der [National Vulnerability Database](https://nvd.nist.gov/vuln) (NVD) veröffentlicht werden.

**Topics**
+ [Funktionsweise von Patch-Baseline-Regeln unter Amazon Linux 2 und Amazon Linux 2023](#linux-rules-amazon-linux)
+ [Funktionsweise von Patch-Baseline-Regeln auf CentOS Stream](#linux-rules-centos)
+ [Funktionsweise von Patch-Baseline-Regeln auf Debian Server](#linux-rules-debian)
+ [Funktionsweise von Patch-Baseline-Regeln auf macOS](#linux-rules-macos)
+ [Funktionsweise von Patch-Baseline-Regeln auf Oracle Linux](#linux-rules-oracle)
+ [So funktionieren Patch-Basisregeln für AlmaLinuxRHEL, und Rocky Linux](#linux-rules-rhel)
+ [Funktionsweise von Patch-Baseline-Regeln auf SUSE Linux Enterprise Server](#linux-rules-sles)
+ [Funktionsweise von Patch-Baseline-Regeln auf Ubuntu Server](#linux-rules-ubuntu)

## Funktionsweise von Patch-Baseline-Regeln unter Amazon Linux 2 und Amazon Linux 2023
<a name="linux-rules-amazon-linux"></a>

**Anmerkung**  
Amazon Linux 2023 (AL2023) verwendet versionierte Repositorys, die über eine oder mehrere Systemeinstellungen für eine bestimmte Version gesperrt werden können. Für alle Patching-Vorgänge auf AL2023 EC2-Instances verwendet Patch Manager unabhängig von der Systemkonfiguration die neuesten Repository-Versionen. Weitere Informationen finden Sie unter [Deterministische Upgrades durch versionierte Repositories](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html) im *Benutzerhandbuch von Amazon Linux 2023*.

Unter Amazon Linux 2 und Amazon Linux 2023 erfolgt die Patch-Auswahl folgendermaßen:

1. Auf dem verwalteten Knoten greift die YUM-Bibliothek (Amazon Linux 2) oder die DNF-Bibliothek (Amazon Linux 2023) auf die `updateinfo.xml`-Datei für jedes konfigurierte Repository zu. 

   Wenn keine `updateinfo.xml`-Datei gefunden wird, hängt es von den Einstellungen für **Funktionsupdates einschließen** und **Automatische Genehmigung** ab, ob Patches installiert werden. Wenn beispielsweise nicht sicherheitsrelevante Updates zulässig sind, werden sie installiert, wenn die automatische Genehmigung eintrifft.

1. Jeder Update-Hinweis in `updateinfo.xml` enthält mehrere Attribute, die die Eigenschaften der Pakete im Hinweis kennzeichnen, wie in der folgenden Tabelle beschrieben.  
**Update-Hinweis-Attribute**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).

1. Das Produkt des verwalteten Knotens wird durch SSM Agent bestimmt. Dieses Attribut entspricht dem Wert des Produktschlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline.

1. Pakete für das Update werden gemäß den folgenden Richtlinien ausgewählt.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).

## Funktionsweise von Patch-Baseline-Regeln auf CentOS Stream
<a name="linux-rules-centos"></a>

Die CentOS Stream-Standard-Repositorys enthalten keine `updateinfo.xml`-Datei. Benutzerdefinierte Repositorys, die Sie erstellen oder verwenden, können diese Datei jedoch enthalten. In diesem Thema beziehen sich Verweise nur `updateinfo.xml` auf diese benutzerdefinierten Repositorys.

In CentOS Stream erfolgt die Patch-Auswahl folgendermaßen:

1. Auf dem verwalteten Knoten ruft die DNF-Bibliothek die `updateinfo.xml`-Datei für jedes konfigurierte Repository auf, sofern diese in einem benutzerdefinierten Repository vorhanden ist.

   Wenn kein `updateinfo.xml` gefunden wird (was immer die Standard-Repos einschließt), hängt die Installation von Patches von den Einstellungen für **Nicht sicherheitsrelevante Updates einschließen** und **Automatische Genehmigung** ab. Wenn beispielsweise nicht sicherheitsrelevante Updates zulässig sind, werden sie installiert, wenn die automatische Genehmigung eintrifft.

1. Wenn `updateinfo.xml` vorhanden ist, enthält jede Aktualisierungsmitteilung in der Datei mehrere Attribute, die die Eigenschaften der Pakete in der Mitteilung bezeichnen, wie in der folgenden Tabelle beschrieben.  
**Update-Hinweis-Attribute**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).

1. Das Produkt des verwalteten Knotens wird in allen Fällen durch SSM Agent bestimmt. Dieses Attribut entspricht dem Wert des Produktschlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline.

1. Pakete für das Update werden gemäß den folgenden Richtlinien ausgewählt.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).

## Funktionsweise von Patch-Baseline-Regeln auf Debian Server
<a name="linux-rules-debian"></a>

Auf Debian Server bietet der Patch-Baseline-Service Filter in den Feldern *Priorität* und *Abschnitt*. Diese Felder sind normalerweise für alle Debian Server-Pakete vorhanden. Um zu bestimmen, ob ein Patch von der Patch-Baseline ausgewählt wird, geht Patch Manager folgendermaßen vor:

1. Auf Debian Server-Systemen wird das Äquivalent von `sudo apt-get update` ausgeführt, um die Liste der verfügbaren Pakete zu aktualisieren. Repos sind nicht konfiguriert und die Daten werden aus Repos abgerufen, die in einer `sources`-Liste konfiguriert sind.

1. Wenn eine Aktualisierung für `python3-apt` (eine Python-Bibliotheks-Schnittstelle zu `libapt`) verfügbar ist, wird es auf die neueste Version aktualisiert. (Dieses nicht sicherheitsrelevante Paket wird aktualisiert, auch wenn Sie die Option **Mit nicht sicherheitsrelevanten Updates** nicht ausgewählt haben.)

1. Als Nächstes werden die Listen [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) und [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) angewendet.
**Anmerkung**  
Da es nicht möglich ist, die Veröffentlichungstermine von Update-Paketen für Debian Server zuverlässig zu bestimmen, werden die Optionen für die automatische Genehmigung für dieses Betriebssystem nicht unterstützt.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

   Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. Für Debian Server sind Patch-Kandidaten-Versionen in diesem Fall auf Patches beschränkt, die in den folgenden Repos enthalten sind:

   Diese Repos werden wie folgt benannt:
   + Debian Server11: `debian-security bullseye`
   + Debian Server12: `debian-security bookworm`

   Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

   Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).

Zum Anzeigen der Inhalte der Felder *Priorität* und *Abschnitt* führen Sie den folgenden `aptitude`-Befehl aus: 

**Anmerkung**  
Möglicherweise müssen Sie zuerst Aptitude auf Debian Server-Systemen installieren.

```
aptitude search -F '%p %P %s %t %V#' '~U'
```

In der Antwort auf diesen Befehl werden alle Pakete, für die ein Upgrade durchgeführt werden kann, in diesem Format gemeldet: 

```
name, priority, section, archive, candidate version
```

Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).

## Funktionsweise von Patch-Baseline-Regeln auf macOS
<a name="linux-rules-macos"></a>

In macOS erfolgt die Patch-Auswahl folgendermaßen:

1. Auf dem verwalteten Knoten greift Patch Manager auf den geparsten Inhalt der `InstallHistory.plist`-Datei zu und identifiziert Paketnamen und -versionen. 

   Details zum Parsing-Prozess finden Sie unter der Registerkarte **macOS** in [Wie Patches installiert werden](patch-manager-installing-patches.md).

1. Das Produkt des verwalteten Knotens wird durch SSM Agent bestimmt. Dieses Attribut entspricht dem Wert des Produktschlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline.

1. Pakete für das Update werden gemäß den folgenden Richtlinien ausgewählt.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).

## Funktionsweise von Patch-Baseline-Regeln auf Oracle Linux
<a name="linux-rules-oracle"></a>

In Oracle Linux erfolgt die Patch-Auswahl folgendermaßen:

1. Auf dem verwalteten Knoten ruft die YUM-Bibliothek die `updateinfo.xml`-Datei für jedes konfigurierte Repo auf.
**Anmerkung**  
Die `updateinfo.xml`-Datei ist möglicherweise nicht verfügbar, wenn das Repo nicht von Oracle verwaltet wird. Wenn keine `updateinfo.xml`-Datei gefunden wird, hängt es von den Einstellungen für **Funktionsupdates einschließen** und **Automatische Genehmigung** ab, ob Patches installiert werden. Wenn beispielsweise nicht sicherheitsrelevante Updates zulässig sind, werden sie installiert, wenn die automatische Genehmigung eintrifft.

1. Jeder Update-Hinweis in `updateinfo.xml` enthält mehrere Attribute, die die Eigenschaften der Pakete im Hinweis kennzeichnen, wie in der folgenden Tabelle beschrieben.  
**Update-Hinweis-Attribute**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).

1. Das Produkt des verwalteten Knotens wird durch SSM Agent bestimmt. Dieses Attribut entspricht dem Wert des Produktschlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline.

1. Pakete für das Update werden gemäß den folgenden Richtlinien ausgewählt.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).

## So funktionieren Patch-Basisregeln für AlmaLinuxRHEL, und Rocky Linux
<a name="linux-rules-rhel"></a>

Bei AlmaLinux, Red Hat Enterprise Linux (RHEL) und Rocky Linux erfolgt die Patch-Auswahl wie folgt:

1. Auf dem verwalteten Knoten greift die YUM-Bibliothek (RHEL7) oder die DNF-Bibliothek (AlmaLinux 8 und 9, RHEL 8, 9 und 10 sowie Rocky Linux 8 und 9) auf die `updateinfo.xml` Datei für jedes konfigurierte Repository zu.
**Anmerkung**  
Die `updateinfo.xml`-Datei ist möglicherweise nicht verfügbar, wenn das Repo nicht von Red Hat verwaltet wird. Falls keine `updateinfo.xml` gefunden werden, wird kein Patch angewendet.

1. Jeder Update-Hinweis in `updateinfo.xml` enthält mehrere Attribute, die die Eigenschaften der Pakete im Hinweis kennzeichnen, wie in der folgenden Tabelle beschrieben.  
**Update-Hinweis-Attribute**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).

1. Das Produkt des verwalteten Knotens wird durch SSM Agent bestimmt. Dieses Attribut entspricht dem Wert des Produktschlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline.

1. Pakete für das Update werden gemäß den folgenden Richtlinien ausgewählt.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).

## Funktionsweise von Patch-Baseline-Regeln auf SUSE Linux Enterprise Server
<a name="linux-rules-sles"></a>

Auf SLES enthält jeder Patch die folgenden Attribute, mit denen die Eigenschaften der Pakete im Patch gekennzeichnet werden:
+ **Category**: Entspricht dem Wert des **Klassifizierungs**-Schlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline. Kennzeichnet den Typ des im Update-Hinweis enthaltenen Patches.

  Sie können die Liste der unterstützten Werte mithilfe des AWS CLI Befehls **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** oder der API-Operation **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)** anzeigen. Sie können die Liste auch im Bereich **Genehmigungsregeln** der Seite **Erstellen einer Patch-Baseline** der Seite **Patch-Baseline bearbeiten** in der Systems Manager-Konsole anzeigen.
+ **Schweregrad**: Entspricht dem Wert des **Schweregrads**-Schlüsselattributs in dem [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline. Kennzeichnet den Schweregrad der Patches.

  Sie können die Liste der unterstützten Werte mithilfe des AWS CLI Befehls **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** oder der API-Operation anzeigen**[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)**. Sie können die Liste auch im Bereich **Genehmigungsregeln** der Seite **Erstellen einer Patch-Baseline** der Seite **Patch-Baseline bearbeiten** in der Systems Manager-Konsole anzeigen.

Das Produkt des verwalteten Knotens wird durch SSM Agent bestimmt. Dieses Attribut entspricht dem Wert des **Produkt**-Schlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline. 

Für jeden Patch wird die Patch-Baseline als Filter verwendet, der nur den qualifizierten Paketen die Aufnahme in das Update erlaubt. Wenn mehrere Pakete zutreffen, wird die aktuelle Version nach Anwenden der Patch-Baseline-Definition verwendet. 

Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).

## Funktionsweise von Patch-Baseline-Regeln auf Ubuntu Server
<a name="linux-rules-ubuntu"></a>

Auf Ubuntu Server bietet der Patch-Baseline-Service Filter in den Feldern *Priorität* und *Abschnitt*. Diese Felder sind normalerweise für alle Ubuntu Server-Pakete vorhanden. Um zu bestimmen, ob ein Patch von der Patch-Baseline ausgewählt wird, geht Patch Manager folgendermaßen vor:

1. Auf Ubuntu Server-Systemen wird das Äquivalent von `sudo apt-get update` ausgeführt, um die Liste der verfügbaren Pakete zu aktualisieren. Repos sind nicht konfiguriert und die Daten werden aus Repos abgerufen, die in einer `sources`-Liste konfiguriert sind.

1. Wenn eine Aktualisierung für `python3-apt` (eine Python-Bibliotheks-Schnittstelle zu `libapt`) verfügbar ist, wird es auf die neueste Version aktualisiert. (Dieses nicht sicherheitsrelevante Paket wird aktualisiert, auch wenn Sie die Option **Mit nicht sicherheitsrelevanten Updates** nicht ausgewählt haben.)

1. Als Nächstes werden die Listen [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) und [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) angewendet.
**Anmerkung**  
Da es nicht möglich ist, die Veröffentlichungsdaten von Updatepaketen für Ubuntu Server zuverlässig zu bestimmen, werden die Optionen für die automatische Genehmigung für dieses Betriebssystem nicht unterstützt.

   Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.

   Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. Für Ubuntu Server sind Patch-Kandidaten-Versionen in diesem Fall auf Patches beschränkt, die in den folgenden Repos enthalten sind:
   + Ubuntu Server 16.04 LTS: `xenial-security`
   + Ubuntu Server 18.04 LTS: `bionic-security`
   + Ubuntu Server 20.04 LTS: `focal-security`
   + Ubuntu Server 22.04 LTS (`jammy-security`)
   + Ubuntu Server 24.04 LTS (`noble-security`)
   + Ubuntu Server 25.04 (`plucky-security`)

   Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.

   Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).

Zum Anzeigen der Inhalte der Felder *Priorität* und *Abschnitt* führen Sie den folgenden `aptitude`-Befehl aus: 

**Anmerkung**  
Möglicherweise müssen Sie zuerst Aptitude auf Ubuntu Server 16-Systemen installieren.

```
aptitude search -F '%p %P %s %t %V#' '~U'
```

In der Antwort auf diesen Befehl werden alle Pakete, für die ein Upgrade durchgeführt werden kann, in diesem Format gemeldet: 

```
name, priority, section, archive, candidate version
```

Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).

# Unterschiede beim Patchvorgang zwischen Linux und Windows Server
<a name="patch-manager-windows-and-linux-differences"></a>

In diesem Thema werden wichtige Unterschiede zwischen Linux- und Windows Server-Patching in Patch Manager, einem Tool in AWS Systems Manager, beschrieben.

**Anmerkung**  
Um von Linux verwaltete Knoten zu patchen, müssen Ihre Knoten SSM Agent der Version 2.0.834.0 oder höher ausführen.  
Wenn Systems Manager neue Tools hinzugefügt oder Aktualisierungen an den vorhandenen Tools vorgenommen werden, wird eine neue Version von SSM Agent veröffentlicht. Wenn Sie nicht die neueste Version des Agenten verwenden, kann dies dazu führen, dass der verwaltete Knoten nicht die zahlreichen Tools und Features von Systems Manager verwendet. Aus diesem Grund empfehlen wir, dass Sie den Prozess zur Aktualisierung von SSM Agent in Ihren Maschinen automatisieren. Weitere Informationen finden Sie unter [Automatisieren von Updates für SSM Agent](ssm-agent-automatic-updates.md). Abonnieren Sie die [SSM Agent-Versionshinweise](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)-Seite in GitHub, um Benachrichtigungen über SSM Agent-Updates zu erhalten.

## Unterschied 1: Patch-Bewertung
<a name="patch-evaluation_diff"></a>

Patch Manager verwendet auf Windows-verwalteten Knoten und Linux-verwalteten Knoten jeweils andere Prozesse, um zu ermitteln, welche Patches installiert sein sollten. 

**Linux**  
Bei Linux-Patches wertet Systems Manager auf *jedem* verwalteten Knoten einzeln zuerst die Patch-Baseline-Regeln und dann die Liste der genehmigten bzw. abgelehnten Patches aus. Systems Manager muss die Patches auf jedem Knoten gesondert auswerten, weil der Service die Liste der bekannten Patches und Updates von den Repositorys abruft, die auf dem verwalteten Knoten konfiguriert sind.

**Windows**  
Für Windows-Patches wertet Systems Manager *direkt im Service* zuerst die Patch-Baseline-Regeln und dann die Liste der genehmigten bzw. abgelehnten Patches aus. Dies ist möglich, weil Windows-Patches aus einem einzigen Repository (Windows Update) abgerufen werden.

## Unterschied 2: `Not Applicable`-Patches
<a name="not-applicable-diff"></a>

Aufgrund der großen Anzahl der verfügbaren Pakete für Linux-Betriebssysteme, meldet Systems Manager keine Details zu Patches mit dem Status *Nicht anwendbar*. Ein `Not Applicable`-Patch ist beispielsweise ein Patch für Apache-Software, wenn auf der Instance Apache nicht installiert ist. Systems Manager meldet zwar die Anzahl der `Not Applicable` Patches in der Zusammenfassung, aber wenn Sie die [DescribeInstancePatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html)API für einen verwalteten Knoten aufrufen, enthalten die zurückgegebenen Daten keine Patches mit dem Status von`Not Applicable`. Dieses Verhalten unterscheidet sich von dem bei Windows.

## Unterschied 3: Unterstützung von SSM-Dokumenten
<a name="document-support-diff"></a>

Das Systems-Manager-Dokument (SSM-Dokument) `AWS-ApplyPatchBaseline` unterstützt keine Linux-verwalteten Knoten. Um Patch-Baselines auf Linux-, macOS- und Windows Server-verwalteten Knoten anzuwenden, wird das SSM-Dokument `AWS-RunPatchBaseline` empfohlen. Weitere Informationen erhalten Sie unter [SSM-Befehlsdokumente zum Patchen verwalteter Knoten](patch-manager-ssm-documents.md) und [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).

## Unterschied 4: Anwendungspatches
<a name="application-patches-diff"></a>

Der Hauptfokus von Patch Manager liegt auf dem Patchen von Betriebssystemen. Sie können mit Patch Manager jedoch auch Patches für bestimmte Anwendungen auf Ihren verwalteten Knoten anwenden.

**Linux**  
Auf Linux-Betriebssystemen verwendet Patch Manager die konfigurierten Repositorys für Updates und unterscheidet dabei nicht zwischen Betriebssystem- und Anwendungs-Patches. Sie können mit Patch Manager festlegen, aus welchen Repositorys Updates abgerufen werden. Weitere Informationen finden Sie unter [So geben Sie ein alternatives Patch-Quell-Repository an (Linux)](patch-manager-alternative-source-repository.md).

**Windows**  
Auf von Windows Server verwaltete Knoten können Sie für Microsoft-Anwendungen wie Microsoft Word 2016 und Microsoft Exchange Server 2016 Genehmigungsregeln sowie die Patch-Ausnahmen *Approved* (Freigegeben) und *Rejected* (Abgelehnt) anwenden. Weitere Informationen finden Sie unter [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md).

## Unterschied 5: Optionen für abgelehnte Patch-Listen in benutzerdefinierten Patch-Baselines
<a name="rejected-patches-diff"></a>

Wenn Sie eine benutzerdefinierte Patch-Baseline erstellen, können Sie für eine Liste Abgelehnte Patches einen oder **mehrere Patches** angeben. Bei verwalteten Linux-Knoten können Sie auch festlegen, dass sie installiert werden dürfen, wenn es sich um Abhängigkeiten für einen anderen Patch handelt, der laut Baseline zulässig ist.

Windows Server unterstützt jedoch das Konzept der Patch-Abhängigkeiten nicht. Sie können einen Patch zur Liste der **abgelehnten Patches** in einer benutzerdefinierten Baseline für Windows Server hinzufügen. Das Ergebnis hängt jedoch davon ab, (1) ob der abgelehnte Patch bereits auf einem verwalteten Knoten installiert ist oder nicht, und (2) welche Option Sie für die **Aktion Abgelehnte Patches** wählen.

In der folgenden Tabelle finden Sie Einzelheiten zu den Optionen für abgelehnte Patches in Windows Server.


| Status der installation | Option: „Als Abhängigkeit zulassen“ | Option: „Blockieren“ | 
| --- | --- | --- | 
| Der Patch ist bereits installiert | Gemeldeter Status: INSTALLED\$1OTHER | Gemeldeter Status: INSTALLED\$1REJECTED | 
| Der Patch ist noch nicht installiert | Patch übersprungen | Patch übersprungen | 

Jeder von Microsoft veröffentlichte Patch für Windows Server enthält normalerweise alle Informationen, die für eine erfolgreiche Installation erforderlich sind. Gelegentlich kann jedoch ein Paket erforderlich sein, das Sie manuell installieren müssen. Patch Manager meldet keine Informationen zu diesen Voraussetzungen. Weitere Informationen finden Sie auf der Microsoft-Website unter [Problembehandlung bei Windows Update](https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting).

# SSM-Befehlsdokumente zum Patchen verwalteter Knoten
<a name="patch-manager-ssm-documents"></a>

In diesem Thema werden die neun derzeit verfügbaren Systems-Manager-Dokumente (SSM-Dokumente) beschrieben, die Ihnen dabei helfen, Ihre verwalteten Knoten mit den neuesten sicherheitsrelevanten Updates zu patchen. 

Wir empfehlen Ihnen, nur fünf dieser Dokumente für Ihre Patches zu verwenden. Zusammen bieten Ihnen diese fünf SSM-Dokumente eine breite Palette an Patch-Optionen mit AWS Systems Manager. Vier dieser Dokumente wurden später veröffentlicht als die vier alten SSM-Dokumente, die sie ersetzen und Erweiterungen oder Konsolidierungen der Funktion darstellen.

**Empfohlene SSM-Dokumente zum Patchen**  
Wir empfehlen, bei Ihren Patchvorgängen die folgenden fünf SSM-Dokumente zu verwenden.
+ `AWS-ConfigureWindowsUpdate`
+ `AWS-InstallWindowsUpdates`
+ `AWS-RunPatchBaseline`
+ `AWS-RunPatchBaselineAssociation`
+ `AWS-RunPatchBaselineWithHooks`

**Ältere SSM-Dokumente zum Patchen**  
Die folgenden vier älteren SSM-Dokumente sind in einigen AWS-Regionen weiterhin verfügbar, werden jedoch nicht mehr aktualisiert oder unterstützt. Es kann nicht garantiert werden, dass diese Dokumente nur in IPv6 Umgebungen und im Support funktionieren. IPv4 Es kann nicht garantiert werden, dass sie in allen Szenarien funktionieren, und sie könnten in Zukunft den Support verlieren. Es wird empfohlen, diese Dokumente nicht für Patch-Vorgänge zu verwenden.
+ `AWS-ApplyPatchBaseline`
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`

Anweisungen zum Einrichten von Patching-Vorgängen in einer Umgebung, die nur Support bietet, finden Sie unter IPv6. [Tutorial: Einen Server in einer IPv6 einzigen Umgebung patchen](patch-manager-server-patching-iPv6-tutorial.md)

In den folgenden Abschnitten finden Sie weitere Informationen zur Verwendung dieser SSM-Dokumente bei Ihren Patching-Vorgängen.

**Topics**
+ [Empfohlene SSM-Dokumente für das Patchen von verwalteten Knoten](#patch-manager-ssm-documents-recommended)
+ [Legacy-SSM-Dokumente für das Patchen von verwalteten Knoten](#patch-manager-ssm-documents-legacy)
+ [Bekannte Einschränkungen der SSM-Dokumente für das Patchen verwalteter Knoten](#patch-manager-ssm-documents-known-limitations)
+ [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)
+ [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)
+ [Beispielszenario für die Verwendung des InstallOverrideList Parameters in `AWS-RunPatchBaseline` oder `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md)
+ [Verwenden des BaselineOverride Parameters](patch-manager-baselineoverride-parameter.md)

## Empfohlene SSM-Dokumente für das Patchen von verwalteten Knoten
<a name="patch-manager-ssm-documents-recommended"></a>

Die folgenden fünf SSM-Dokumente werden für die Verwendung bei Ihren Patching-Operationen für Ihre verwalteten Knoten empfohlen.

**Topics**
+ [`AWS-ConfigureWindowsUpdate`](#patch-manager-ssm-documents-recommended-AWS-ConfigureWindowsUpdate)
+ [`AWS-InstallWindowsUpdates`](#patch-manager-ssm-documents-recommended-AWS-InstallWindowsUpdates)
+ [`AWS-RunPatchBaseline`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaseline)
+ [`AWS-RunPatchBaselineAssociation`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineAssociation)
+ [`AWS-RunPatchBaselineWithHooks`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineWithHooks)

### `AWS-ConfigureWindowsUpdate`
<a name="patch-manager-ssm-documents-recommended-AWS-ConfigureWindowsUpdate"></a>

Unterstützt die Konfiguration grundlegender Funktionen für Windows Update und deren Verwendung zum automatischen Installieren von Updates (oder zum Deaktivieren automatischer Updates). In allen AWS-Regionen verfügbar.

Mit diesem SSM-Dokument wird Windows Update aufgefordert, die angegebenen Updates herunterzuladen und zu installieren und die verwalteten Knoten bei Bedarf neu zu starten. Verwenden Sie dieses Dokument zusammen mit einem Tool inState Manager, um sicherzustellen AWS Systems Manager, dass Windows Update seine Konfiguration beibehält. Sie können es auch manuell ausführenRun Command, indem Sie ein Tool in verwenden AWS Systems Manager, um die Windows Update-Konfiguration zu ändern. 

Die in diesem Dokument verfügbaren Parameter unterstützen die Angabe einer Kategorie von Updates, die installiert werden sollen (oder ob automatische Updates deaktiviert werden sollen), sowie die Angabe des Wochentages und der Tageszeit für die Ausführung von Patch-Vorgängen. Dieses SSM-Dokument ist besonders dann von Vorteil, wenn Sie keine strenge Kontrolle über Windows Updates benötigen und keine Compliance-Informationen sammeln müssen. 

**Replaces legacy SSM documents: **
+ *Keine*

### `AWS-InstallWindowsUpdates`
<a name="patch-manager-ssm-documents-recommended-AWS-InstallWindowsUpdates"></a>

Installiert Updates auf einem von Windows Server verwalteten Knoten. In allen AWS-Regionen verfügbar.

Dieses SSM-Dokument bietet grundlegende Patch-Funktion für den Fall, dass Sie entweder ein bestimmtes Update (mit Hilfe des `Include Kbs`-Parameters) installieren möchten oder Patches mit bestimmten Klassifizierungen oder Kategorien installieren möchten, aber keine Informationen zur Patch-Compliance benötigen. 

**Replaces legacy SSM documents:**
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`

Die drei alten Dokumente erfüllen zwar unterschiedliche Funktionen, aber Sie können die gleichen Ergebnisse erzielen, indem Sie unterschiedliche Parametereinstellungen mit dem neueren SSM-Dokument `AWS-InstallWindowsUpdates` verwenden. Diese Parametereinstellungen werden in [Legacy-SSM-Dokumente für das Patchen von verwalteten Knoten](#patch-manager-ssm-documents-legacy) beschrieben.

### `AWS-RunPatchBaseline`
<a name="patch-manager-ssm-documents-recommended-AWS-RunPatchBaseline"></a>

Installiert Patches auf Ihren verwalteten Knoten oder scannt Knoten, um festzustellen, ob qualifizierte Patches fehlen. In allen AWS-Regionen verfügbar.

Mit `AWS-RunPatchBaseline` können Sie Patch-Genehmigungen mithilfe der Patch-Baseline steuern, die als „Standard“ für einen Betriebssystemtyp angegeben ist. Stellt Informationen zur Patch-Compliance dar, die Sie mit den Systems Manager-Compliance-Tools einsehen können. Mit diesen Tools erhalten Sie Erkenntnisse in den Zustand der Patch-Compliance Ihrer verwalteten Knoten, z. B. bei welchen Knoten Patches fehlen und was diese Patches sind. Wenn Sie `AWS-RunPatchBaseline` verwenden, werden Patch-Compliance-Informationen mit dem API-Befehl `PutInventory` aufgezeichnet. Für Linux-Betriebssysteme werden Compliance-Informationen für Patches sowohl über das in einem verwalteten Knoten konfigurierte Standard-Quell-Repository bereitgestellt, als auch von einem beliebigen alternativen Quell-Repository aus, das Sie in einer benutzerdefinierten Patch-Baseline angeben. Weitere Informationen über alternative Quell-Repositorys finden Sie unter [So geben Sie ein alternatives Patch-Quell-Repository an (Linux)](patch-manager-alternative-source-repository.md). Weitere Informationen zu den Systems Manager-Compliance-Tools finden Sie unter [AWS Systems Manager-Compliance](systems-manager-compliance.md).

 **Ersetzt alte Dokumente:**
+ `AWS-ApplyPatchBaseline`

Das Legacy-Dokument `AWS-ApplyPatchBaseline` gilt nur für von Windows Server verwaltete Knoten und bietet keinen Support für Anwendungs-Patches. Das neue Dokument `AWS-RunPatchBaseline` bietet die gleiche Unterstützung für sowohl Windows- als auch Linux-Systeme. Version 2.0.834.0 oder höher von SSM Agent ist erforderlich, um das Dokument `AWS-RunPatchBaseline` zu verwenden. 

Weitere Informationen über das SSM-Dokument `AWS-RunPatchBaseline` finden Sie unter [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).

### `AWS-RunPatchBaselineAssociation`
<a name="patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineAssociation"></a>

Installiert Patches auf Ihren Instances oder scannt Instances, um festzustellen, ob qualifizierte Patches fehlen. In allen kommerziellen AWS-Regionen verfügbar. 

`AWS-RunPatchBaselineAssociation` unterscheidet sich in verschiedenen wichtigen Punkten von `AWS-RunPatchBaseline`:
+ `AWS-RunPatchBaselineAssociation` ist hauptsächlich für die Verwendung mit State Manager-Zuordnungen vorgesehen, die mithilfe von Quick Setup, einem Tool in AWS Systems Manager, erstellt wurden. Insbesondere, wenn Sie den Quick Setup-Host-Management-Konfigurationstyp verwenden und die Option **Scan instances for missing patches daily** (Instances täglich auf fehlende Patches scannen) auswählen, verwendet das System `AWS-RunPatchBaselineAssociation` für diese Operation.

  In den meisten Fällen sollten Sie jedoch beim Einrichten eigener Patching-Vorgänge [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) oder [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) anstelle von `AWS-RunPatchBaselineAssociation` auswählen. 

  Weitere Informationen finden Sie unter den folgenden Themen:
  + [AWS Systems Manager Quick Setup](systems-manager-quick-setup.md)
  + [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ `AWS-RunPatchBaselineAssociation` unterstützt die Verwendung von Tags, um zu identifizieren, welche Patch-Baseline bei der Ausführung mit einer Reihe von Zielen verwendet werden soll. 
+ Für Patching-Vorgänge, die `AWS-RunPatchBaselineAssociation` verwenden, werden Patch-Compliance-Daten in Bezug auf eine bestimmte State Manager-Zuordnung gesammelt. Die Patch-Compliance-Daten, die gesammelt werden, wenn `AWS-RunPatchBaselineAssociation` ausgeführt wird, werden mit dem API-Befehl `PutComplianceItems` anstelle des Befehls `PutInventory` aufgezeichnet. Dies verhindert, dass Compliance-Daten, die nicht mit dieser bestimmten Zuordnung verknüpft sind, überschrieben werden.

  Für Linux-Betriebssysteme werden Compliance-Informationen für Patches sowohl über das in einer Instance konfigurierte Standard-Quell-Repository bereitgestellt, als auch von einem beliebigen alternativen Quell-Repository aus, das Sie in einer benutzerdefinierten Patch-Baseline angeben. Weitere Informationen über alternative Quell-Repositorys finden Sie unter [So geben Sie ein alternatives Patch-Quell-Repository an (Linux)](patch-manager-alternative-source-repository.md). Weitere Informationen zu den Systems Manager-Compliance-Tools finden Sie unter [AWS Systems Manager-Compliance](systems-manager-compliance.md).

 **Ersetzt alte Dokumente:**
+ **Keine**

Weitere Informationen über das SSM-Dokument `AWS-RunPatchBaselineAssociation` finden Sie unter [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md).

### `AWS-RunPatchBaselineWithHooks`
<a name="patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineWithHooks"></a>

Installiert Patches auf Ihren verwalteten Knoten oder scannt Knoten, um festzustellen, ob qualifizierte Patches fehlen. Mit optionalen Hooks können Sie SSM-Dokumente an drei Punkten während des Patch-Zyklus ausführen. In allen kommerziellen AWS-Regionen verfügbar. Wird nicht unterstützt auf macOS.

`AWS-RunPatchBaselineWithHooks` unterscheidet sich von `AWS-RunPatchBaseline` in seiner `Install`-Operation.

`AWS-RunPatchBaselineWithHooks` unterstützt Lebenszyklus-Hooks, die während dem Patching von verwalteten Knoten an festgelegten Punkten ausgeführt werden. Da Patch-Installationen manchmal den Neustart von verwalteten Knoten erfordern, ist die Patch-Operation in zwei Ereignisse unterteilt, wobei insgesamt drei Hooks enthalten sind, die benutzerdefinierte Funktion unterstützen. Der erste Hook ist vor der `Install with NoReboot`-Operation. Der zweite Hook ist nach der `Install with NoReboot`-Operation. Der dritte Hook ist nach dem Neustart des Knoten verfügbar.

 **Ersetzt alte Dokumente:**
+ **Keine**

Weitere Informationen über das SSM-Dokument `AWS-RunPatchBaselineWithHooks` finden Sie unter [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md).

## Legacy-SSM-Dokumente für das Patchen von verwalteten Knoten
<a name="patch-manager-ssm-documents-legacy"></a>

Die folgenden vier SSM-Dokumente sind in einigen AWS-Regionen noch verfügbar. Sie werden jedoch nicht mehr aktualisiert und möglicherweise in Zukunft nicht mehr unterstützt. Daher empfehlen wir ihre Verwendung nicht. Stattdessen verwenden Sie bitte die unter [Empfohlene SSM-Dokumente für das Patchen von verwalteten Knoten](#patch-manager-ssm-documents-recommended) beschriebenen Dokumente.

**Topics**
+ [`AWS-ApplyPatchBaseline`](#patch-manager-ssm-documents-legacy-AWS-ApplyPatchBaseline)
+ [`AWS-FindWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-AWS-FindWindowsUpdates)
+ [`AWS-InstallMissingWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallMissingWindowsUpdates)
+ [`AWS-InstallSpecificWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallSpecificWindowsUpdates)

### `AWS-ApplyPatchBaseline`
<a name="patch-manager-ssm-documents-legacy-AWS-ApplyPatchBaseline"></a>

Unterstützt nur von Windows Server verwaltete Knoten, enthält jedoch, anders als der Nachfolger `AWS-RunPatchBaseline`, keinen Support für Anwendungs-Patches. Nicht verfügbar in Versionen, die nach August 2017 AWS-Regionen veröffentlicht wurden.

**Anmerkung**  
Um dieses SSM-Dokument, `AWS-RunPatchBaseline`, zu ersetzen, wird die Version 2.0.834.0 oder eine neuere Version von SSM Agent benötigt. Sie können das Dokument `AWS-UpdateSSMAgent` verwenden, um Ihre verwalteten Knoten auf die neueste Version des Agenten zu aktualisieren. 

### `AWS-FindWindowsUpdates`
<a name="patch-manager-ssm-documents-legacy-AWS-AWS-FindWindowsUpdates"></a>

Ersetzt durch `AWS-InstallWindowsUpdates`, die alle die gleichen Aktionen ausführen können. Nicht verfügbar bei AWS-Regionen Markteinführungen nach April 2017.

Um das gleiche Ergebnis wie bei diesem alten SSM-Dokument zu erzielen, verwenden Sie die folgende Parameterkonfiguration mit dem empfohlenen Ersatzdokument, `AWS-InstallWindowsUpdates`:
+ `Action` = `Scan`
+ `Allow Reboot` = `False`

### `AWS-InstallMissingWindowsUpdates`
<a name="patch-manager-ssm-documents-legacy-AWS-InstallMissingWindowsUpdates"></a>

Ersetzt durch `AWS-InstallWindowsUpdates`, die alle die gleichen Aktionen ausführen können. Nicht verfügbar bei Produkten, die nach April 2017 auf den AWS-Regionen Markt gebracht wurden.

Um das gleiche Ergebnis wie bei diesem alten SSM-Dokument zu erzielen, verwenden Sie die folgende Parameterkonfiguration mit dem empfohlenen Ersatzdokument, `AWS-InstallWindowsUpdates`:
+ `Action` = `Install`
+ `Allow Reboot` = `True`

### `AWS-InstallSpecificWindowsUpdates`
<a name="patch-manager-ssm-documents-legacy-AWS-InstallSpecificWindowsUpdates"></a>

Ersetzt durch `AWS-InstallWindowsUpdates`, die alle die gleichen Aktionen ausführen können. Nicht verfügbar bei Produkten, die nach April 2017 auf den AWS-Regionen Markt gebracht wurden.

Um das gleiche Ergebnis wie bei diesem alten SSM-Dokument zu erzielen, verwenden Sie die folgende Parameterkonfiguration mit dem empfohlenen Ersatzdokument, `AWS-InstallWindowsUpdates`:
+ `Action` = `Install`
+ `Allow Reboot` = `True`
+ `Include Kbs` = *comma-separated list of KB articles*

## Bekannte Einschränkungen der SSM-Dokumente für das Patchen verwalteter Knoten
<a name="patch-manager-ssm-documents-known-limitations"></a>

### Unterbrechungen des externen Neustarts
<a name="patch-manager-ssm-documents-known-limitations-external-reboot"></a>

Wenn das System auf dem Knoten während der Patch-Installation einen Neustart initiiert (z. B. um Firmware-Updates oder andere Funktionen anzuwenden SecureBoot), kann die Ausführung des Patch-Dokuments unterbrochen und als fehlgeschlagen markiert werden, obwohl Patches erfolgreich installiert wurden. Dies ist darauf zurückzuführen, dass der SSM-Agent den Status der Dokumentausführung bei externen Neustarts nicht beibehalten und wieder aufnehmen kann.

Um den Status der Patch-Installation nach einer fehlgeschlagenen Ausführung zu überprüfen, führen Sie einen `Scan` Patch-Vorgang aus und überprüfen Sie anschließend die Patch-Kompatibilitätsdaten in Patch Manager, um den aktuellen Kompatibilitätsstatus zu beurteilen.

# SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaseline`
<a name="patch-manager-aws-runpatchbaseline"></a>

AWS Systems Manager unterstützt`AWS-RunPatchBaseline`, ein Systems Manager Manager-Dokument (SSM-Dokument) fürPatch Manager, ein Tool in AWS Systems Manager. Dieses SSM-Dokument führt Patch-Operationen auf verwaltete Knoten sowohl für sicherheitsrelevante als auch für andere Arten von Updates durch. Wenn das Dokument ausgeführt wird, verwendet es die Patch-Baseline, die der „Standard“ für einen Betriebssystemtyp ist, wenn keine Patch-Gruppe angegeben ist. Andernfalls wird die Patch-Baseline verwendet, die der Patch-Gruppe zugeordnet ist. Informationen zu Patch-Gruppen finden Sie unter [Patch-Gruppen](patch-manager-patch-groups.md). 

Sie können das Dokument `AWS-RunPatchBaseline` verwenden, um Patches sowohl für Betriebssysteme als auch für Anwendungen durchzuführen. (Unter Windows Server ist der Anwendungssupport auf Updates für Microsoft-Anwendungen beschränkt.)

Dieses Dokument unterstützt von Linux, macOS und Windows Server verwaltete Knoten. Das Dokument führt die entsprechenden Aktionen für jede Plattform durch. 

**Anmerkung**  
Patch Manager unterstützt auch das veraltete SSM-Dokument `AWS-ApplyPatchBaseline`. Dieses Dokument unterstützt jedoch nur das Patchen von Windows-verwalteten Knoten. Wir empfehlen Ihnen, stattdessen `AWS-RunPatchBaseline` zu verwenden, da es das Patchen auf Linux-, macOS- und Windows Server-verwaltete Knoten unterstützt. Version 2.0.834.0 oder höher von SSM Agent ist erforderlich, um das Dokument `AWS-RunPatchBaseline` zu verwenden.

------
#### [ Windows Server ]

Auf Windows Server verwalteten Knoten lädt das `AWS-RunPatchBaseline` Dokument ein PowerShell Modul herunter und ruft es auf, das wiederum einen Snapshot der Patch-Baseline herunterlädt, die für den verwalteten Knoten gilt. Dieser Patch-Baseline-Snapshot enthält eine Liste genehmigter Patches, die kompiliert werden, indem die Patch-Baseline auf einem WSUS-Server (Windows Server Update Services) abgefragt wird. Diese Liste wird an die Windows Update-API weitergeleitet, die das Herunterladen und Installieren des genehmigten Patches entsprechend steuert. 

------
#### [ Linux ]

Auf Linux-verwalteten Knoten ruft das Dokument `AWS-RunPatchBaseline` ein Python-Modul auf, das wiederum einen entsprechenden Snapshot der Patch-Baseline für den verwalteten Knoten herunterlädt. Dieser Patch-Baseline-Snapshot verwendet die definierten Regeln und Listen der genehmigten und gesperrten Patches, um den entsprechenden Paketmanager für jeden Knoten-Typ anzutreiben: 
+ Von Amazon Linux 2, Oracle Linux und RHEL 7 verwaltete Knoten verwenden YUM. Für YUM-Operationen ist eine `Python 2.6` oder eine neuere unterstützte Version Patch Manager erforderlich (2.6 — 3.12). Amazon Linux 2023 verwendet DNF. Für DNF-Operationen Patch Manager ist eine unterstützte Version von `Python 2` oder `Python 3` (2.6 - 3.12) erforderlich.
+ Von RHEL 8 verwaltete Knoten verwenden DNF. Für DNF-Operationen Patch Manager ist eine unterstützte Version von `Python 2` or `Python 3` (2.6 - 3.12) erforderlich. (Keine der beiden Versionen ist standardmäßig auf RHEL 8 installiert. Sie müssen die eine oder andere Version manuell installieren.)
+ Debian Server, und Ubuntu Server Instanzen verwenden APT. Für APT-Operationen Patch Manager ist eine unterstützte Version von `Python 3` (3.0 - 3.12) erforderlich.

------
#### [ macOS ]

Auf macOS-verwalteten Knoten ruft das Dokument `AWS-RunPatchBaseline` ein Python-Modul auf, das wiederum einen entsprechenden Snapshot der Patch-Baseline für den verwalteten Knoten herunterlädt. Als Nächstes ruft ein Python-Unterprozess die AWS Command Line Interface (AWS CLI) auf dem Knoten auf, um die Installations- und Aktualisierungsinformationen für die angegebenen Paketmanager abzurufen und den entsprechenden Paketmanager für jedes Aktualisierungspaket zu steuern.

------

Jeder Snapshot ist spezifisch für eine Patchgruppe AWS-Konto, ein Betriebssystem und eine Snapshot-ID. Der Snapshot wird über eine vorsignierte Amazon Simple Storage Service (Amazon S3)-URL bereitgestellt, die 24 Stunden nach Erstellung des Snapshots abläuft. Wenn Sie jedoch denselben Snapshot-Inhalt auf andere verwaltete Knoten anwenden möchten, können Sie nach Ablauf der URL bis zu drei Tage nach Erstellung des Snapshots eine neue vorsignierte Amazon-S3-URL generieren. Verwenden Sie dazu den Befehl [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html). 

Nachdem alle genehmigten und zutreffenden Updates installiert und je nach Bedarf Neustarts durchgeführt wurden, werden Patch-Compliance-Informationen auf einem verwalteten Knoten generiert und wieder an Patch Manager gemeldet. 

**Anmerkung**  
Wenn der Parameter `RebootOption` im Dokument `AWS-RunPatchBaseline` auf `NoReboot` gesetzt ist, wird der verwaltete Knoten nach dem Ausführen von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption).

Weitere Informationen zum Anzeigen von Patch-Compliance-Daten finden Sie unter [Info zu Patch Compliance](compliance-about.md#compliance-monitor-patch). 

## `AWS-RunPatchBaseline`-Parameter
<a name="patch-manager-aws-runpatchbaseline-parameters"></a>

`AWS-RunPatchBaseline` unterstützt sechs Parameter. Der Parameter `Operation` muss angegeben werden. Die Parameter `InstallOverrideList`, `BaselineOverride` und `RebootOption` sind optional. `Snapshot-ID` ist technisch optional, wir empfehlen allerdings, dass Sie einen benutzerdefinierten Wert dafür angeben, wenn Sie `AWS-RunPatchBaseline` außerhalb von einem Wartungsfenster ausführen, und Patch Manager den Wert benutzerdefinierten automatisch angeben lassen, wenn das Dokument als Teil eines Wartungsfenstervorgangs ausgeführt wird.

**Topics**
+ [Parametername: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Parametername: `AssociationId`](#patch-manager-aws-runpatchbaseline-parameters-association-id)
+ [Parametername: `Snapshot ID`](#patch-manager-aws-runpatchbaseline-parameters-snapshot-id)
+ [Parametername: `InstallOverrideList`](#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)
+ [Parametername: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)
+ [Parametername: `BaselineOverride`](#patch-manager-aws-runpatchbaseline-parameters-baselineoverride)
+ [Parametername: `StepTimeoutSeconds`](#patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds)

### Parametername: `Operation`
<a name="patch-manager-aws-runpatchbaseline-parameters-operation"></a>

**Nutzung**: erforderlich.

**Optionen**: `Scan` \$1 `Install`. 

Scan  
Wenn Sie die Option `Scan` wählen, bestimmt `AWS-RunPatchBaseline` den Patch-Compliance-Status des verwalteten Knoten und meldet diese Informationen an Patch Manager. `Scan` fordert nicht zum Installieren von Updates oder zum Neustarten von verwalteten Knoten auf. Stattdessen erkennt die Operation, wo für den Knoten genehmigte und geeignete Updates fehlen. 

Installieren  
Bei Auswahl der Option `Install` versucht `AWS-RunPatchBaseline`, die genehmigten und geeigneten Updates zu installieren, die auf dem verwalteten Knoten fehlen. Patch-Compliance-Informationen, die als Teil eines `Install`-Vorgangs generiert wurden, enthalten keine fehlenden Updates, melden allerdings möglicherweise Updates im Fehlerzustand, wenn die Installation des Updates aus einem beliebigen Grund nicht erfolgreich war. Immer wenn ein Update auf einem verwalteten Knoten installiert wird, wird der Knoten neu gestartet, um sicherzustellen, dass das Update installiert und aktiviert ist. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)  
Wenn ein von den Basisregeln festgelegter Patch installiert wird, *bevor* der Patch Manager den verwalteten Knoten aktualisiert, wird das System möglicherweise nicht wie erwartet neu gestartet. Dies kann passieren, wenn ein Patch manuell von einem Benutzer oder automatisch von einem anderen Programm, z. B. dem `unattended-upgrades`-Paket auf Ubuntu Server, installiert wird.

### Parametername: `AssociationId`
<a name="patch-manager-aws-runpatchbaseline-parameters-association-id"></a>

**Nutzung**: optional.

`AssociationId` ist die ID einer Zuordnung in State Manager, einem Tool in AWS Systems Manager. Es wird von Patch Manager verwendet, um einer angegebenen Zuordnung Compliance-Daten hinzuzufügen. Diese Zuordnung bezieht sich auf einen Patching-Vorgang, der [in einer Patch-Richtlinie in Quick Setup eingerichtet](quick-setup-patch-manager.md) ist. 

**Anmerkung**  
Wenn mit der `AWS-RunPatchBaseline` ein `AssociationId`-Wert zusammen mit einer Baseline-Überschreibung der Patch-Richtlinie bereitgestellt wird, wird das Patchen als eine `PatchPolicy`-Operation durchgeführt und der `ExecutionType`-Wert, der in `AWS:ComplianceItem` gemeldet wird, ist ebenfalls `PatchPolicy`. Wenn kein `AssociationId`-Wert angegeben wird, wird das Patchen als eine `Command`-Operation durchgeführt, und der `ExecutionType`-Wert, der in `AWS:ComplianceItem` übermittelt wird, ist ebenfalls `Command`. 

Wenn Sie noch keine Zuordnung erstellt haben, die Sie verwenden möchten, können Sie eine erstellen, indem Sie den Befehl [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html) ausführen. 

### Parametername: `Snapshot ID`
<a name="patch-manager-aws-runpatchbaseline-parameters-snapshot-id"></a>

**Nutzung**: optional.

`Snapshot ID` ist eine eindeutige ID (GUID), die von Patch Manager verwendet wird, um sicherzustellen, dass ein Satz von verwalteten Knoten, für die in einer einzelnen Operation Patches durchgeführt werden, den genau gleichen Satz genehmigter Patches aufweist. Auch wenn der Parameter als optional definiert ist, hängen unsere Empfehlungen für bewährte Methoden davon ab, ob Sie `AWS-RunPatchBaseline` in einem Wartungsfenster, wie in der folgenden Tabelle beschrieben, ausführen.


**Bewährte Methoden für `AWS-RunPatchBaseline`**  

| Mode | Bewährte Methode | Details | 
| --- | --- | --- | 
| Ausführen von AWS-RunPatchBaseline innerhalb eines Wartungsfensters | Geben Sie keine Snapshot ID an. Patch Manager wird sie für Sie bereitstellen. |  Falls Sie ein Wartungsfenster zum Ausführen von `AWS-RunPatchBaseline` verwenden, dürfen Sie Ihre eigene generierte Snapshot ID nicht angeben. In diesem Szenario stellt Systems Manager einen GUID-Wert auf Grundlage der Wartungsfensterausführungs-ID bereit. Auf diese Weise wird sichergestellt, dass eine richtige ID für alle Aufrufe von `AWS-RunPatchBaseline` in diesem Wartungsfenster verwendet wird.  Wenn Sie einen Wert in diesem Szenario angeben, beachten Sie, dass der Snapshot der Patch-Baseline möglicherweise nicht länger als drei Tagen erhalten bleibt. Danach wird ein neuer Snapshot erstellt, auch wenn Sie dieselbe ID angeben, nachdem der Snapshot abgelaufen ist.   | 
| Ausführen von AWS-RunPatchBaseline außerhalb eines Wartungsfensters | Generieren Sie einen benutzerdefinierten GUID-Wert für die Snapshot-ID und geben Sie ihn an.¹ |  Wenn Sie kein Wartungsfenster zum Ausführen von `AWS-RunPatchBaseline` verwenden, empfehlen wir, dass Sie eine eindeutige Snapshot-ID für jede Patch-Baseline generieren und angeben, insbesondere wenn Sie das Dokument `AWS-RunPatchBaseline` auf mehreren verwaltete Knoten in derselben Operation ausführen. Wenn Sie keine ID in diesem Szenario angeben, generiert Systems Manager eine andere Snapshot-ID für jeden verwalteten Knoten, an den der Befehl gesendet wird. Dies kann zu unterschiedlichen Sätzen von Patches führen, die auf den jeweiligen verwalteten Knoten angegeben sind. Angenommen, Sie führen das Dokument `AWS-RunPatchBaseline` direkt über Run Command aus, ein Tool in AWS Systems Manager, und richten es auf eine Gruppe von 50 verwalteten Knoten aus. Das Angeben einer benutzerdefinierten Snapshot-ID führt zur Erstellung eines einzelnen Baseline-Snapshots, der verwendet wird, um alle Knoten zu bewerten und zu patchen. Dadurch wird gewährleistet, dass sie letztendlich einen konsistenten Zustand aufweisen.   | 
|  ¹ Sie können jedes beliebige Tool zum Generieren eines Werts für den Snapshot-ID-Parameter verwenden, das eine GUID generieren kann. In können Sie PowerShell beispielsweise das `New-Guid` Cmdlet verwenden, um eine GUID im Format von zu generieren. `12345699-9405-4f69-bc5e-9315aEXAMPLE`  | 

### Parametername: `InstallOverrideList`
<a name="patch-manager-aws-runpatchbaseline-parameters-installoverridelist"></a>

**Nutzung**: optional.

Mit `InstallOverrideList` können Sie eine https-URL oder eine Amazon S3-PathStyle-URL zu einer Liste mit zu installierenden Patches angeben. Diese im YAML-Format geführte Patch-Installationsliste überschreibt die von der Standard-Patch-Baseline angegebenen Patches. Dies bietet Ihnen eine detalliertere Kontrolle darüber, welche Patches auf Ihren verwalteten Knoten installiert sind. 

**Wichtig**  
Der `InstallOverrideList`-Dateiname darf die folgenden Zeichen nicht enthalten: Backtick (`), einfaches Anführungszeichen ('), doppeltes Anführungszeichen („) und Dollarzeichen (\$1).

Das Verhalten des Patch-Vorgangs bei Verwendung des `InstallOverrideList`-Parameters unterscheidet sich zwischen Linux- und macOS-verwalteten Knoten und Windows Server-verwalteten Knoten. Unter Linux und macOS versucht Patch Manager, Patches aus der Patchliste `InstallOverrideList` anzuwenden, die in einem auf dem Knoten aktivierten Repository vorhanden sind, unabhängig davon, ob die Patches den Patch-Baseline-Regeln entsprechen oder nicht. Auf Windows Server-Knoten werden Patches in der `InstallOverrideList`-Patch-Liste jedoch *nur* angewendet, wenn sie auch den Patch-Baseline-Regeln entsprechen.

Beachten Sie, dass Compliance-Berichte Patch-Status entsprechend den Angaben in der Patch-Baseline wiedergeben, nicht entsprechend Ihren Angaben in einer `InstallOverrideList`-Liste von Patches. Mit anderen Worten: Scan-Operationen ignorieren den Parameter `InstallOverrideList`. Auf diese Weise wird sichergestellt, dass Compliance-Berichte den Patch-Status konsistent entsprechend der Richtlinie wiedergeben und nicht danach, was für eine bestimmte Patching-Operation genehmigt wurde. 

**Anmerkung**  
Wenn Sie einen Knoten patchen, der nur verwendet, stellen Sie sicher IPv6, dass die angegebene URL vom Knoten aus erreichbar ist. Wenn die SSM Agent Konfigurationsoption auf gesetzt `UseDualStackEndpoint` ist`true`, wird ein Dual-Stack-S3-Client verwendet, wenn eine S3-URL bereitgestellt wird. Weitere Informationen [Tutorial: Einen Server in einer IPv6 einzigen Umgebung patchen](patch-manager-server-patching-iPv6-tutorial.md) zur Konfiguration des Agenten für die Verwendung von Dualstack finden Sie unter.

Eine Beschreibung, wie Sie den Parameter `InstallOverrideList` verwenden können, um verschiedene Patch-Typen in verschiedenen Wartungsfenster-Zeitplänen auf eine Zielgruppe anzuwenden und gleichzeitig eine einzelne Patch-Baseline zu verwenden, finden Sie unter [Beispielszenario für die Verwendung des InstallOverrideList Parameters in `AWS-RunPatchBaseline` oder `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md).

**Gültige URL-Formate**

**Anmerkung**  
Wenn Ihre Datei in einem öffentlich zugänglichen Bucket gespeichert ist, können Sie entweder ein HTTPS-URL-Format oder eine URL im Amazon S3-Pfadstil angeben. Wenn Ihre Datei in einem privaten Bucket gespeichert ist, müssen Sie eine URL im Amazon S3-Pfadstil angeben.
+ **HTTPS-URL-Format**:

  ```
  https://s3.aws-api-domain/amzn-s3-demo-bucket/my-windows-override-list.yaml
  ```
+ **URL im Amazon S3-Pfadstil**:

  ```
  s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
  ```

**Gültige YAML-Inhaltsformate**

Die Formate, die Sie verwenden, um Patches in Ihrer Liste anzugeben, hängen von dem Betriebssystem Ihres verwalteten Knoten ab. Das allgemeine Format lautet jedoch folgendermaßen:

```
patches:
    - 
        id: '{patch-d}'
        title: '{patch-title}'
        {additional-fields}:{values}
```

Sie können zwar zusätzliche Felder in der YAML-Datei bereitstellen, diese werden jedoch während der Patch-Operationen ignoriert.

Darüber hinaus empfehlen wir zu überprüfen, ob das Format Ihrer YAML-Datei gültig ist, bevor Sie die Liste in Ihrem S3-Bucket hinzufügen oder aktualisieren. Weitere Informationen zum YAML-Format finden Sie unter [yaml.org](http://www.yaml.org). Für Validierungstool-Optionen suchen Sie im Internet nach „yaml format validators“ durch.

------
#### [ Linux ]

**id**  
Das Feld **id** ist ein Pflichtfeld. Verwenden Sie es, um Patches mit Paketnamen und Architektur anzugeben. Beispiel: `'dhclient.x86_64'`. Sie können Platzhalter in der ID verwenden, um mehrere Pakete anzugeben. Zum Beispiel `'dhcp*'` und `'dhcp*1.*'`.

**Title**  
Das Feld **Titel** ist optional, es bietet jedoch auf Linux-Systemen zusätzliche Filterfunktionen. Wenn Sie **Titel** verwenden, sollte er die Versionsinformationen des Pakets in einem der folgenden Formate enthalten:

YUM/SUSE Linux Enterprise Server (SLES):

```
{name}.{architecture}:{epoch}:{version}-{release}
```

APT

```
{name}.{architecture}:{version}
```

Für Linux-Patch-Titel können Sie einen oder mehrere Platzhalter in beliebigen Positionen verwenden, um die Anzahl der Paketzuordnungen zu erhöhen. Beispiel: `'*32:9.8.2-0.*.rc1.57.amzn1'`. 

Zum Beispiel: 
+ apt-Paketversion 1.2.25 ist derzeit auf Ihrem verwalteten Knoten installiert, aber Version 1.2.27 ist jetzt verfügbar. 
+ Fügen Sie die apt.amd64-Version 1.2.27 der Liste hinzu. Sie ist abhängig von apt utils.amd64 Version 1.2.27, aber apt-utils.amd64 Version 1.2.25 ist in der Liste angegeben. 

In diesem Fall wird die Installation der APT-Version 1.2.27 blockiert und als „Fehlgeschlagen-“ gemeldet. NonCompliant

------
#### [ Windows Server ]

**id**  
Das Feld **id** ist ein Pflichtfeld. Verwenden Sie es, um Patches mithilfe von Microsoft Knowledge Base IDs (z. B. KB2736693) und Microsoft Security Bulletin IDs (z. B. MS17 -023) anzugeben. 

Alle anderen Felder, die Sie in einer Patch-Liste für Windows bereitstellen möchten, sind optional und dienen nur zu Ihrer eigenen Information. Sie können zusätzlichen Felder verwenden, wie z. B. **Titel**, **Klassifizierung**, **Schweregrad** oder andere Angaben für detailliertere Informationen über die angegebenen Patches.

------
#### [ macOS ]

**id**  
Das Feld **id** ist ein Pflichtfeld. Der Wert für das Feld **id** kann entweder mit einem `{package-name}.{package-version}`-Format oder einem \$1package\$1name\$1-Format bereitgestellt werden.

------

**Patch-Beispiellisten**
+ **Amazon Linux 2**

  ```
  patches:
      -
          id: 'kernel.x86_64'
      -
          id: 'bind*.x86_64'
          title: '39.11.4-26.P2.amzn2.5.2'
  
          id: 'glibc*'
      -
          id: 'dhclient*'
          title: '*4.2.5-58.amzn2'
      -
          id: 'dhcp*'
          title: '*4.2.5-77.amzn2'
  ```
+ **Debian Server**

  ```
  patches:
      -
          id: 'apparmor.amd64'
          title: '2.10.95-0ubuntu2.9'
      -
          id: 'cryptsetup.amd64'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'cryptsetup-bin.*'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'apt.amd64'
          title: '*1.2.27'
      -
          id: 'apt-utils.amd64'
          title: '*1.2.25'
  ```
+ **macOS**

  ```
  patches:
      -
          id: 'XProtectPlistConfigData'
      -
          id: 'MRTConfigData.1.61'
      -
          id: 'Command Line Tools for Xcode.11.5'
      -
          id: 'Gatekeeper Configuration Data'
  ```
+ **Oracle Linux**

  ```
  patches:
      -
          id: 'audit-libs.x86_64'
          title: '*2.8.5-4.el7'
      -
          id: 'curl.x86_64'
          title: '*.el7'
      -
          id: 'grub2.x86_64'
          title: 'grub2.x86_64:1:2.02-0.81.0.1.el7'
      -
          id: 'grub2.x86_64'
          title: 'grub2.x86_64:1:*-0.81.0.1.el7'
  ```
+ **Red Hat Enterprise Linux (RHEL)**

  ```
  patches:
      -
          id: 'NetworkManager.x86_64'
          title: '*1:1.10.2-14.el7_5'
      -
          id: 'NetworkManager-*.x86_64'
          title: '*1:1.10.2-14.el7_5'
      -
          id: 'audit.x86_64'
          title: '*0:2.8.1-3.el7'
      -
          id: 'dhclient.x86_64'
          title: '*.el7_5.1'
      -
          id: 'dhcp*.x86_64'
          title: '*12:5.2.5-68.el7'
  ```
+ **SUSE Linux Enterprise Server (SLES)**

  ```
  patches:
      -
          id: 'amazon-ssm-agent.x86_64'
      -
          id: 'binutils'
          title: '*0:2.26.1-9.12.1'
      -
          id: 'glibc*.x86_64'
          title: '*2.19*'
      -
          id: 'dhcp*'
          title: '0:4.3.3-9.1'
      -
          id: 'lib*'
  ```
+ **Ubuntu Server **

  ```
  patches:
      -
          id: 'apparmor.amd64'
          title: '2.10.95-0ubuntu2.9'
      -
          id: 'cryptsetup.amd64'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'cryptsetup-bin.*'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'apt.amd64'
          title: '*1.2.27'
      -
          id: 'apt-utils.amd64'
          title: '*1.2.25'
  ```
+ **Windows**

  ```
  patches:
      -
          id: 'KB4284819'
          title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
      -
          id: 'KB4284833'
      -
          id: 'KB4284835'
          title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
      -
          id: 'KB4284880'
      -
          id: 'KB4338814'
  ```

### Parametername: `RebootOption`
<a name="patch-manager-aws-runpatchbaseline-parameters-norebootoption"></a>

**Nutzung**: optional.

**Optionen**: `RebootIfNeeded` \$1 `NoReboot` 

**Standardwert**: `RebootIfNeeded`

**Warnung**  
Die Standardoption ist `RebootIfNeeded`. Stellen Sie sicher, dass Sie die richtige Option für Ihren Anwendungsfall auswählen. Wenn Ihre verwalteten Knoten beispielsweise sofort neu gestartet werden müssen, um einen Konfigurationsprozess abzuschließen, wählen Sie `RebootIfNeeded` aus. Oder wenn Sie die Verfügbarkeit von verwalteten Knoten bis zu einer geplanten Neustartzeit beibehalten müssen, wählen Sie `NoReboot` aus.

**Wichtig**  
Wir empfehlen nicht, Cluster-Instances in Amazon EMR (früher Amazon Elastic MapReduce genannt) zum Patchen zu verwendenPatch Manager. Wählen Sie insbesondere nicht die Option `RebootIfNeeded` für den Parameter `RebootOption` aus. (Diese Option ist in den SSM-Befehlsdokumenten für das Patchen von `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` und `AWS-RunPatchBaselineWithHooks` verfügbar.)  
Die zugrunde liegenden Befehle für das Patchen mithilfe von Patch Manager verwenden `yum`- und `dnf`-Befehle. Daher führen die Operationen aufgrund der Art und Weise, wie Pakete installiert werden, zu Inkompatibilitäten. Informationen zu den bevorzugten Methoden für die Aktualisierung von Software auf Amazon-EMR-Clustern finden Sie unter [Verwenden des Standard-AMI für Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) im *Amazon EMR Management Guide*.

RebootIfNeeded  
Wenn Sie die Option `RebootIfNeeded` auswählen, wird der verwaltete Knoten in einem der folgenden Fälle neu gestartet:   
+ Patch Manager ist auf einem oder mehreren Patches installiert. 

  Patch Manager wertet nicht aus, ob ein Neustart vom Patch *erfordert* wird. Das System wird neu gestartet, auch wenn der Patch keinen Neustart erfordert.
+ Patch Manager erkennt ein oder mehrere Patches mit dem Status `INSTALLED_PENDING_REBOOT` während der `Install`-Operation. 

  Der `INSTALLED_PENDING_REBOOT`-Status kann bedeuten, dass die Option `NoReboot` ausgewählt wurde, als der `Install`-Vorgang das letzte Mal ausgeführt wurde, oder dass ein Patch außerhalb von Patch Manager seit dem letzten Neustart des verwalteten Knotens installiert wurde.
Durch den Neustart von verwalteten Knoten wird in diesen beiden Fällen sichergestellt, dass aktualisierte Pakete aus dem Speicher gelöscht werden und das Patch- und Neustartverhalten über alle Betriebssysteme hinweg konsistent bleibt.

NoReboot  
Wenn Sie die Option `NoReboot` auswählen, startet Patch Manager einen verwalteten Knoten nicht neu, selbst wenn über ihn während der `Install`-Operation Patches installiert wurden. Diese Option ist nützlich, wenn Sie wissen, dass für Ihre verwalteten Knoten nach dem Anwenden von Patches kein Neustart erforderlich ist oder Anwendungen bzw. Prozesse auf einem Knoten ausgeführt werden, die nicht durch einen Neustart beim Patchen unterbrochen werden sollten. Sie ist auch nützlich, wenn Sie mehr Kontrolle über das Timing von Neustarts von verwalteten Knoten wünschen, z. B. durch die Verwendung eines Wartungsfensters.  
Wenn Sie die Option `NoReboot` auswählen und ein Patch installiert ist, wird dem Patch der Status `InstalledPendingReboot` zugewiesen. Der verwaltete Knoten selbst wird jedoch als `Non-Compliant` gekennzeichnet. Nach einem Neustart und Ausführung einer `Scan`-Operation wird der Status des verwalteten Knoten auf `Compliant` aktualisiert.  
Die Option `NoReboot` verhindert nur Neustarts auf Betriebssystemebene. Im Rahmen des Patch-Vorgangs können weiterhin Neustarts auf Service-Ebene erfolgen. Wenn Docker beispielsweise aktualisiert wird, können abhängige Services wie Amazon Elastic Container Service automatisch neu gestartet werden, auch wenn `NoReboot` aktiviert ist. Wenn Sie wichtige Services haben, die nicht unterbrochen werden dürfen, sollten Sie zusätzliche Maßnahmen in Betracht ziehen. Sie könnten z. B. Instances vorübergehend außer Betrieb nehmen oder Patches während Wartungsfenstern planen.

**Datei zum Nachverfolgen der Patch-Installation**: Um die Patch-Installation nachzuverfolgen, insbesondere von Patches, die seit dem letzten Neustart des Systems installiert wurden, erstellt Systems Manager eine Datei auf dem verwalteten Knoten.

**Wichtig**  
Löschen oder ändern Sie die Tracking-Datei nicht. Wenn diese Datei gelöscht oder beschädigt wird, ist der Patch-Compliance-Bericht für den verwalteten Knoten ungenau. Starten Sie in diesem Fall den Knoten neu und führen Sie eine Patch-Scan-Operation aus, um die Datei wiederherzustellen.

Diese Tracking-Datei wird an den folgenden Speicherorten auf Ihren verwalteten Knoten gespeichert:
+ Linux-Betriebssysteme: 
  + `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
  + `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server-Betriebssystem:
  + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
  + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`

### Parametername: `BaselineOverride`
<a name="patch-manager-aws-runpatchbaseline-parameters-baselineoverride"></a>

**Nutzung**: optional.

Sie können Patching-Voreinstellungen zur Laufzeit mit dem `BaselineOverride`-Parameter definieren. Diese Baseline-Überschreibung wird als JSON-Objekt in einem S3-Bucket beibehalten. Sie stellt sicher, dass Patchvorgänge die bereitgestellten Baselines verwenden, die dem Host-Betriebssystem entsprechen, anstatt die Regeln aus der Standard-Patch-Baseline anzuwenden

**Wichtig**  
Der `BaselineOverride`-Dateiname darf die folgenden Zeichen nicht enthalten: Backtick (`), einfaches Anführungszeichen ('), doppeltes Anführungszeichen („) und Dollarzeichen (\$1).

Weitere Informationen zur Verwendung des Parameters `BaselineOverride` finden Sie unter [Verwenden des BaselineOverride Parameters](patch-manager-baselineoverride-parameter.md).

### Parametername: `StepTimeoutSeconds`
<a name="patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds"></a>

**Nutzung**: erforderlich.

Die Zeit in Sekunden – zwischen 1 und 36 000 Sekunden (10 Stunden) –, die ein Befehl in Anspruch nehmen darf, bevor er als fehlgeschlagen betrachtet wird.

# SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaselineAssociation`
<a name="patch-manager-aws-runpatchbaselineassociation"></a>

Wie das `AWS-RunPatchBaseline`-Dokument führt auch `AWS-RunPatchBaselineAssociation` Patching-Operationen auf Instances für sicherheitsrelevante und andere Arten von Updates aus. Sie können das Dokument `AWS-RunPatchBaselineAssociation` auch verwenden, um Patches sowohl für Betriebssysteme als auch für Anwendungen durchzuführen. (Unter Windows Server ist der Anwendungssupport auf Updates für Microsoft-Anwendungen beschränkt.)

Dieses Dokument unterstützt Amazon Elastic Compute Cloud (Amazon EC2)-Instances für Linux, macOS und Windows Server. Nicht-EC2-Knoten in einer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) werden nicht unterstützt. Das Dokument führt die entsprechenden Aktionen für jede Plattform durch und ruft ein Python-Modul auf Linux und macOS Instanzen und ein PowerShell Modul auf Windows-Instanzen auf.

`AWS-RunPatchBaselineAssociation` unterscheidet sich jedoch auf folgende Weise von `AWS-RunPatchBaseline`: 
+ `AWS-RunPatchBaselineAssociation` ist hauptsächlich für die Verwendung mit State Manager-Zuordnungen vorgesehen, die mithilfe von [Quick Setup](systems-manager-quick-setup.md), einem Tool in AWS Systems Manager, erstellt wurden. Insbesondere, wenn Sie den Quick Setup-Host-Management-Konfigurationstyp verwenden und die Option **Scan instances for missing patches daily** (Instances täglich auf fehlende Patches scannen) auswählen, verwendet das System `AWS-RunPatchBaselineAssociation` für diese Operation.

  In den meisten Fällen sollten Sie jedoch beim Einrichten eigener Patching-Vorgänge [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) oder [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) anstelle von `AWS-RunPatchBaselineAssociation` auswählen.
+ Wenn Sie das `AWS-RunPatchBaselineAssociation`-Dokument verwenden, können Sie ein Tag-Schlüssel-Paar im `BaselineTags`-Parameterfeld des Dokuments angeben. Wenn eine benutzerdefinierte Patch-Baseline in Ihrem AWS-Konto System diese Tags verwendetPatch Manager, verwendet ein Tool in diese markierte Baseline AWS Systems Manager, wenn es auf den Ziel-Instances ausgeführt wird, und nicht die aktuell angegebene „Standard“ -Patch-Baseline für den Betriebssystemtyp.
**Anmerkung**  
Wenn Sie `AWS-RunPatchBaselineAssociation` in anderen Patching-Operationen als den mithilfe von Quick Setup eingerichteten verwenden und Sie den optionalen `BaselineTags`-Parameter verwenden möchten, müssen Sie einige zusätzliche Berechtigungen für das [Instance-Profil](setup-instance-permissions.md) für Amazon Elastic Compute Cloud (Amazon EC2)-Instances bereitstellen. Weitere Informationen finden Sie unter [Parametername: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags).

  Die beiden folgenden Formate sind gültig für Ihre `BaselineTags`-Parameter:

  `Key=tag-key,Values=tag-value`

  `Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**Wichtig**  
Tag-Schlüssel und -Werte dürfen die folgenden Zeichen nicht enthalten: Backtick (`), einfaches Anführungszeichen ('), doppeltes Anführungszeichen („) und Dollarzeichen (\$1).
+ Wenn `AWS-RunPatchBaselineAssociation` ausgeführt wird, werden die Patch-Compliance-Daten, die es sammelt, mit dem API-Befehl `PutComplianceItems` anstelle des Befehls `PutInventory`, der von `AWS-RunPatchBaseline` verwendet wird, aufgezeichnet. Dieser Unterschied bedeutet, dass die Patch-Compliance-Informationen gemäß einer bestimmten *Zuordnung* gespeichert und gemeldet werden. Patch-Compliance-Daten, die außerhalb dieser Zuordnung generiert wurden, werden nicht überschrieben.
+ Die Patch-Compliance-Informationen, die nach der Ausführung von `AWS-RunPatchBaselineAssociation` gemeldet werden, geben an, ob eine Instance konform ist oder nicht. Es enthält keine Details auf Patch-Ebene, wie die Ausgabe des folgenden AWS Command Line Interface (AWS CLI) -Befehls zeigt. Der Befehl filtert auf `Association` als Compliance-Typ:

  ```
  aws ssm list-compliance-items \
      --resource-ids "i-02573cafcfEXAMPLE" \
      --resource-types "ManagedInstance" \
      --filters "Key=ComplianceType,Values=Association,Type=EQUAL" \
      --region us-east-2
  ```

  Das System gibt unter anderem folgende Informationen zurück

  ```
  {
      "ComplianceItems": [
          {
              "Status": "NON_COMPLIANT", 
              "Severity": "UNSPECIFIED", 
              "Title": "MyPatchAssociation", 
              "ResourceType": "ManagedInstance", 
              "ResourceId": "i-02573cafcfEXAMPLE", 
              "ComplianceType": "Association", 
              "Details": {
                  "DocumentName": "AWS-RunPatchBaselineAssociation", 
                  "PatchBaselineId": "pb-0c10e65780EXAMPLE", 
                  "DocumentVersion": "1"
              }, 
              "ExecutionSummary": {
                  "ExecutionTime": 1590698771.0
              }, 
              "Id": "3e5d5694-cd07-40f0-bbea-040e6EXAMPLE"
          }
      ]
  }
  ```

Wenn ein Tag-Schlüssel-Paar-Wert als Parameter für das `AWS-RunPatchBaselineAssociation`-Dokument angegeben wurde, sucht Patch Manager nach einer benutzerdefinierten Patch-Baseline, die mit dem Betriebssystemtyp übereinstimmt und mit demselben Tag-Schlüssel-Paar gekennzeichnet wurde. Diese Suche ist nicht auf die aktuell angegebene Standard-Patch-Baseline oder die Baseline beschränkt, die einer Patch-Gruppe zugewiesen ist. Wenn keine Baseline mit den angegebenen Tags gefunden wird, sucht Patch Manager als Nächstes nach einer Patch-Gruppe, wenn eine in dem Befehl angegeben wurde, der `AWS-RunPatchBaselineAssociation` ausführt. Wenn keine Patch-Gruppe übereinstimmt, wird Patch Manager auf die aktuelle Standard-Patch-Baselines für das Betriebssystemkonto zurückgesetzt. 

Wenn mehr als eine Patch-Baseline mit den Tags gefunden wird, die im `AWS-RunPatchBaselineAssociation`-Dokument angegeben sind, gibt Patch Manager eine Fehlermeldung zurück, die angibt, dass nur eine Patch-Baseline mit diesem Schlüssel-Wert-Paar gekennzeichnet werden kann, damit der Vorgang fortgesetzt wird.

**Anmerkung**  
Auf Linux-Knoten wird der entsprechende Paketmanager für jeden Knotentyp verwendet, um Pakete zu installieren:   
Amazon-Linux-2-, Oracle Linux- und RHEL-Instances verwenden YUM. Für YUM-Operationen ist eine `Python 2.6` oder eine Patch Manager neuere unterstützte Version (2.6 - 3.12) erforderlich. Amazon Linux 2023 verwendet DNF. Für DNF-Vorgänge erfordert Patch Manager eine unterstützte Version von `Python 2` oder `Python 3` (2.6–3.12).
Debian Serverund Ubuntu Server Instanzen verwenden APT. Für APT-Operationen Patch Manager ist eine unterstützte Version von `Python 3` (3.0 - 3.12) erforderlich.

Nachdem der Scan abgeschlossen wurde oder alle genehmigten und zutreffenden Updates installiert und je nach Bedarf Neustarts durchgeführt wurden, werden Patch-Compliance-Informationen auf einer Instance generiert und wieder an den Patchmanager-Service gemeldet. 

**Anmerkung**  
Wenn der Parameter `RebootOption` im Dokument `AWS-RunPatchBaselineAssociation` auf `NoReboot` gesetzt ist, wird die Instance nach dem Ausführen von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption).

Weitere Informationen zum Anzeigen von Patch-Compliance-Daten finden Sie unter [Info zu Patch Compliance](compliance-about.md#compliance-monitor-patch). 

## `AWS-RunPatchBaselineAssociation`-Parameter
<a name="patch-manager-aws-runpatchbaselineassociation-parameters"></a>

`AWS-RunPatchBaselineAssociation` unterstützt fünf Parameter. Die Parameter `Operation` und `AssociationId` müssen angegeben werden. Die Parameter `InstallOverrideList`, `RebootOption` und `BaselineTags` sind optional. 

**Topics**
+ [Parametername: `Operation`](#patch-manager-aws-runpatchbaselineassociation-parameters-operation)
+ [Parametername: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)
+ [Parametername: `AssociationId`](#patch-manager-aws-runpatchbaselineassociation-parameters-association-id)
+ [Parametername: `InstallOverrideList`](#patch-manager-aws-runpatchbaselineassociation-parameters-installoverridelist)
+ [Parametername: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)

### Parametername: `Operation`
<a name="patch-manager-aws-runpatchbaselineassociation-parameters-operation"></a>

**Nutzung**: erforderlich.

**Optionen**: `Scan` \$1 `Install`. 

Scan  
Wenn Sie die Option `Scan` wählen, bestimmt `AWS-RunPatchBaselineAssociation` den Patch-Compliance-Status der Instance und meldet diese Informationen an Patch Manager. `Scan` fordert nicht zum Installieren von Updates oder zum Neustarten von Instances auf. Stattdessen erkennt der Vorgang, wo für die Instance genehmigte und geeignete Updates fehlen. 

Installieren  
Bei Auswahl der Option `Install` versucht `AWS-RunPatchBaselineAssociation`, die genehmigten und geeigneten Updates zu installieren, die auf der Instance fehlen. Patch-Compliance-Informationen, die als Teil eines `Install`-Vorgangs generiert wurden, enthalten keine fehlenden Updates, melden allerdings möglicherweise Updates im Fehlerzustand, wenn die Installation des Updates aus einem beliebigen Grund nicht erfolgreich war. Immer wenn ein Update auf einer Instance installiert wird, wird die Instance neu gestartet, um sicherzustellen, dass es installiert und aktiviert ist. (Ausnahme: Wenn der `RebootOption`-Parameter im `AWS-RunPatchBaselineAssociation`-Dokument auf `NoReboot` gesetzt ist, wird die Instance nach der Ausführung von Patch Manager nicht neugestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption).)  
Wenn ein von den Basisregeln festgelegter Patch installiert wird, *bevor* der Patch Manager die Instance aktualisiert, wird das System möglicherweise nicht wie erwartet neu gestartet. Dies kann passieren, wenn ein Patch manuell von einem Benutzer oder automatisch von einem anderen Programm, z. B. dem `unattended-upgrades`-Paket auf Ubuntu Server, installiert wird.

### Parametername: `BaselineTags`
<a name="patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags"></a>

**Nutzung**: optional. 

`BaselineTags` ist ein eindeutiges Tag-Schlüssel-Wert-Paar, das Sie auswählen und einer individuellen benutzerdefinierten Patch-Baseline zuweisen. Sie können einen oder mehrere Werte für diesen Parameter angeben. Beider der folgenden Formate sind gültig:

`Key=tag-key,Values=tag-value`

`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`

**Wichtig**  
Tag-Schlüssel und -Werte dürfen die folgenden Zeichen nicht enthalten: Backtick (`), einfaches Anführungszeichen ('), doppeltes Anführungszeichen („) und Dollarzeichen (\$1).

Der `BaselineTags`-Wert wird von Patch Manager verwendet, um sicherzustellen, dass eine Gruppe von Instances, für die in einem Vorgang Patches durchgeführt werden, den genau gleichen Satz genehmigter Patches aufweist. Wenn der Patching-Vorgang ausgeführt wird, überprüft Patch Manager, ob eine Patch-Baseline für den Betriebssystemtyp mit demselben Schlüssel-Wert-Paar versehen ist, das Sie für `BaselineTags` angeben. Wenn eine Übereinstimmung vorliegt, wird diese benutzerdefinierte Patch-Baseline verwendet. Wenn keine Übereinstimmung vorliegt, wird eine Patch-Baseline anhand einer beliebigen Patchgruppe identifiziert, die für die Patching-Operation angegeben wurde. Wenn keine vorhanden ist, wird die AWS verwaltete vordefinierte Patch-Baseline für dieses Betriebssystem verwendet. 

**Zusätzliche Berechtigungsanforderungen**  
Wenn Sie `AWS-RunPatchBaselineAssociation` in anderen Patching-Operationen als den mithilfe von Quick Setup eingerichteten verwenden und Sie den optionalen `BaselineTags`-Parameter verwenden möchten, müssen Sie die folgenden Berechtigungen für das [Instance-Profil](setup-instance-permissions.md) für Amazon Elastic Compute Cloud (Amazon EC2)-Instances bereitstellen.

**Anmerkung**  
Quick Setupund unterstützen `AWS-RunPatchBaselineAssociation` keine lokalen Server und virtuelle Maschinen (VMs).

```
{
    "Effect": "Allow",
    "Action": [
        "ssm:DescribePatchBaselines",
        "tag:GetResources"
    ],
    "Resource": "*"
},
{
    "Effect": "Allow",
    "Action": [
        "ssm:GetPatchBaseline",
        "ssm:DescribeEffectivePatchesForPatchBaseline"
    ],
    "Resource": "patch-baseline-arn"
}
```

*patch-baseline-arn*Ersetzen Sie es durch den Amazon-Ressourcennamen (ARN) der Patch-Baseline, auf die Sie Zugriff gewähren möchten, im folgenden Format`arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE`.

### Parametername: `AssociationId`
<a name="patch-manager-aws-runpatchbaselineassociation-parameters-association-id"></a>

**Nutzung**: erforderlich.

`AssociationId` ist die ID einer Zuordnung in State Manager, einem Tool in AWS Systems Manager. Es wird von Patch Manager verwendet, um einer angegebenen Zuordnung Compliance-Daten hinzuzufügen. Diese Zuordnung bezieht sich auf einen `Scan`-Patching-Vorgang, der in einer [in Quick Setup erstellten Host-Management-Konfiguration](quick-setup-host-management.md) aktiviert ist. Indem Sie die Patching-Ergebnisse als Zuordnungs-Compliance-Daten statt als Inventar-Compliance-Daten senden, werden die vorhandenen Inventar-Compliance-Informationen für Ihre Instances nach einem Patchvorgang oder bei anderen Zuordnungen nicht überschrieben. IDs Wenn Sie noch keine Zuordnung erstellt haben, die Sie verwenden möchten, können Sie eine erstellen, indem Sie den Befehl [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html) ausführen. Beispiel:

------
#### [ Linux & macOS ]

```
aws ssm create-association \
    --name "AWS-RunPatchBaselineAssociation" \
    --association-name "MyPatchHostConfigAssociation" \
    --targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" \
    --parameters "Operation=Scan" \
    --schedule-expression "cron(0 */30 * * * ? *)" \
    --sync-compliance "MANUAL" \
    --region us-east-2
```

------
#### [ Windows Server ]

```
aws ssm create-association ^
    --name "AWS-RunPatchBaselineAssociation" ^
    --association-name "MyPatchHostConfigAssociation" ^
    --targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" ^
    --parameters "Operation=Scan" ^
    --schedule-expression "cron(0 */30 * * * ? *)" ^
    --sync-compliance "MANUAL" ^
    --region us-east-2
```

------

### Parametername: `InstallOverrideList`
<a name="patch-manager-aws-runpatchbaselineassociation-parameters-installoverridelist"></a>

**Nutzung**: optional.

Mit `InstallOverrideList` können Sie eine https-URL oder eine Amazon Simple Storage Service (Amazon S3)-URL im Pfadstil zu einer Liste mit zu installierenden Patches angeben. Diese im YAML-Format geführte Patch-Installationsliste überschreibt die von der Standard-Patch-Baseline angegebenen Patches. Dies bietet Ihnen eine differenziertere Kontrolle darüber, welche Patches auf Ihren Instances installiert sind.

**Wichtig**  
Der `InstallOverrideList`-Dateiname darf die folgenden Zeichen nicht enthalten: Backtick (`), einfaches Anführungszeichen ('), doppeltes Anführungszeichen („) und Dollarzeichen (\$1).

Das Verhalten des Patch-Vorgangs bei Verwendung des `InstallOverrideList`-Parameters unterscheidet sich zwischen Linux- und macOS-verwalteten Knoten und Windows Server-verwalteten Knoten. Unter Linux und macOS versucht Patch Manager, Patches aus der Patchliste `InstallOverrideList` anzuwenden, die in einem auf dem Knoten aktivierten Repository vorhanden sind, unabhängig davon, ob die Patches den Patch-Baseline-Regeln entsprechen oder nicht. Auf Windows Server-Knoten werden Patches in der `InstallOverrideList`-Patch-Liste jedoch *nur* angewendet, wenn sie auch den Patch-Baseline-Regeln entsprechen.

Beachten Sie, dass Compliance-Berichte Patch-Status entsprechend den Angaben in der Patch-Baseline wiedergeben, nicht entsprechend Ihren Angaben in einer `InstallOverrideList`-Liste von Patches. Mit anderen Worten: Scan-Operationen ignorieren den Parameter `InstallOverrideList`. Auf diese Weise wird sichergestellt, dass Compliance-Berichte den Patch-Status konsistent entsprechend der Richtlinie wiedergeben und nicht danach, was für eine bestimmte Patching-Operation genehmigt wurde. 

**Gültige URL-Formate**

**Anmerkung**  
Wenn Ihre Datei in einem öffentlich zugänglichen Bucket gespeichert ist, können Sie entweder ein HTTPS-URL-Format oder eine URL im Amazon S3-Pfadstil angeben. Wenn Ihre Datei in einem privaten Bucket gespeichert ist, müssen Sie eine URL im Amazon S3-Pfadstil angeben.
+ **Beispiel des HTTPS-URL-Formats**:

  ```
  https://s3.amazonaws.com/amzn-s3-demo-bucket/my-windows-override-list.yaml
  ```
+ **Beispiel-URL im Amazon-S3-Pfadstil**:

  ```
  s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
  ```

**Gültige YAML-Inhaltsformate**

Die Formate, die Sie verwenden, um Patches in Ihrer Liste anzugeben, hängen von dem Betriebssystem Ihrer Instance ab. Das allgemeine Format lautet jedoch folgendermaßen:

```
patches:
    - 
        id: '{patch-d}'
        title: '{patch-title}'
        {additional-fields}:{values}
```

Sie können zwar zusätzliche Felder in der YAML-Datei bereitstellen, diese werden jedoch während der Patch-Operationen ignoriert.

Darüber hinaus empfehlen wir zu überprüfen, ob das Format Ihrer YAML-Datei gültig ist, bevor Sie die Liste in Ihrem S3-Bucket hinzufügen oder aktualisieren. Weitere Informationen zum YAML-Format finden Sie unter [yaml.org](http://www.yaml.org). Für Validierungstool-Optionen suchen Sie im Internet nach „yaml format validators“ durch.
+ Microsoft Windows

**id**  
Das Feld **id** ist ein Pflichtfeld. Verwenden Sie es, um Patches mithilfe von Microsoft Knowledge Base IDs (z. B. KB2736693) und Microsoft Security Bulletin IDs (z. B. MS17 -023) anzugeben. 

  Alle anderen Felder, die Sie in einer Patch-Liste für Windows bereitstellen möchten, sind optional und dienen nur zu Ihrer eigenen Information. Sie können zusätzlichen Felder verwenden, wie z. B. **Titel**, **Klassifizierung**, **Schweregrad** oder andere Angaben für detailliertere Informationen über die angegebenen Patches.
+ Linux

**id**  
Das Feld **id** ist ein Pflichtfeld. Verwenden Sie es, um Patches mit Paketnamen und Architektur anzugeben. Beispiel: `'dhclient.x86_64'`. Sie können Platzhalter in der ID verwenden, um mehrere Pakete anzugeben. Zum Beispiel `'dhcp*'` und `'dhcp*1.*'`.

**Titel**  
Das Feld **Titel** ist optional, es bietet jedoch auf Linux-Systemen zusätzliche Filterfunktionen. Wenn Sie **Titel** verwenden, sollte er die Versionsinformationen des Pakets in einem der folgenden Formate enthalten:

  YUM/Red Hat Enterprise Linux (RHEL):

  ```
  {name}.{architecture}:{epoch}:{version}-{release}
  ```

  APT

  ```
  {name}.{architecture}:{version}
  ```

  Für Linux-Patch-Titel können Sie einen oder mehrere Platzhalter in beliebigen Positionen verwenden, um die Anzahl der Paketzuordnungen zu erhöhen. Beispiel: `'*32:9.8.2-0.*.rc1.57.amzn1'`. 

  Zum Beispiel: 
  + apt-Paketversion 1.2.25 ist derzeit auf Ihrer Instance installiert, aber Version 1.2.27 ist jetzt verfügbar. 
  + Fügen Sie die apt.amd64-Version 1.2.27 der Liste hinzu. Sie ist abhängig von apt utils.amd64 Version 1.2.27, aber apt-utils.amd64 Version 1.2.25 ist in der Liste angegeben. 

  In diesem Fall wird die Installation der APT-Version 1.2.27 blockiert und als „Fehlgeschlagen-“ gemeldet. NonCompliant

**Andere Felder**  
Alle anderen Felder, die Sie in einer Patch-Liste für Linux bereitstellen möchten, sind optional und dienen nur zu Ihrer eigenen Information. Sie können zusätzlichen Felder verwenden, wie z. B. **Klassifizierung**, **Schweregrad** oder andere Angaben für detailliertere Informationen über die angegebenen Patches.

**Patch-Beispiellisten**
+ **Windows**

  ```
  patches:
      -
          id: 'KB4284819'
          title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
      -
          id: 'KB4284833'
      -
          id: 'KB4284835'
          title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
      -
          id: 'KB4284880'
      -
          id: 'KB4338814'
  ```
+ **APT**

  ```
  patches:
      -
          id: 'apparmor.amd64'
          title: '2.10.95-0ubuntu2.9'
      -
          id: 'cryptsetup.amd64'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'cryptsetup-bin.*'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'apt.amd64'
          title: '*1.2.27'
      -
          id: 'apt-utils.amd64'
          title: '*1.2.25'
  ```
+ **Amazon Linux 2**

  ```
  patches:
      -
          id: 'kernel.x86_64'
      -
          id: 'bind*.x86_64'
          title: '39.11.4-26.P2.amzn2.5.2'
  
          id: 'glibc*'
      -
          id: 'dhclient*'
          title: '*4.2.5-58.amzn2'
      -
          id: 'dhcp*'
          title: '*4.2.5-77.amzn2'
  ```
+ **Red Hat Enterprise Linux (RHEL)**

  ```
  patches:
      -
          id: 'NetworkManager.x86_64'
          title: '*1:1.10.2-14.el7_5'
      -
          id: 'NetworkManager-*.x86_64'
          title: '*1:1.10.2-14.el7_5'
      -
          id: 'audit.x86_64'
          title: '*0:2.8.1-3.el7'
      -
          id: 'dhclient.x86_64'
          title: '*.el7_5.1'
      -
          id: 'dhcp*.x86_64'
          title: '*12:5.2.5-68.el7'
  ```
+ **SUSE Linux Enterprise Server (SLES)**

  ```
  patches:
      -
          id: 'amazon-ssm-agent.x86_64'
      -
          id: 'binutils'
          title: '*0:2.26.1-9.12.1'
      -
          id: 'glibc*.x86_64'
          title: '*2.19*'
      -
          id: 'dhcp*'
          title: '0:4.3.3-9.1'
      -
          id: 'lib*'
  ```
+ **Ubuntu Server **

  ```
  patches:
      -
          id: 'apparmor.amd64'
          title: '2.10.95-0ubuntu2.9'
      -
          id: 'cryptsetup.amd64'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'cryptsetup-bin.*'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'apt.amd64'
          title: '*1.2.27'
      -
          id: 'apt-utils.amd64'
          title: '*1.2.25'
  ```
+ **Windows**

  ```
  patches:
      -
          id: 'KB4284819'
          title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
      -
          id: 'KB4284833'
      -
          id: 'KB4284835'
          title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
      -
          id: 'KB4284880'
      -
          id: 'KB4338814'
  ```

### Parametername: `RebootOption`
<a name="patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption"></a>

**Nutzung**: optional.

**Optionen**: `RebootIfNeeded` \$1 `NoReboot` 

**Standardwert**: `RebootIfNeeded`

**Warnung**  
Die Standardoption ist `RebootIfNeeded`. Stellen Sie sicher, dass Sie die richtige Option für Ihren Anwendungsfall auswählen. Wenn Ihre Instances beispielsweise sofort neu starten müssen, um einen Konfigurationsprozess abzuschließen, wählen Sie `RebootIfNeeded` aus. Oder wenn Sie die Verfügbarkeit von Instances bis zu einer geplanten Neustartzeit beibehalten müssen, wählen Sie `NoReboot` aus.

**Wichtig**  
Die Option `NoReboot` verhindert nur Neustarts auf Betriebssystemebene. Im Rahmen des Patch-Vorgangs können weiterhin Neustarts auf Service-Ebene erfolgen. Wenn Docker beispielsweise aktualisiert wird, können abhängige Services wie Amazon Elastic Container Service automatisch neu gestartet werden, auch wenn `NoReboot` aktiviert ist. Wenn Sie wichtige Services haben, die nicht unterbrochen werden dürfen, sollten Sie zusätzliche Maßnahmen in Betracht ziehen. Sie könnten z. B. Instances vorübergehend außer Betrieb nehmen oder Patches während Wartungsfenstern planen.

**Wichtig**  
Wir empfehlen nicht, Cluster-Instances in Amazon EMR (früher Amazon Elastic MapReduce genannt) zum Patchen zu verwendenPatch Manager. Wählen Sie insbesondere nicht die Option `RebootIfNeeded` für den Parameter `RebootOption` aus. (Diese Option ist in den SSM-Befehlsdokumenten für das Patchen von `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` und `AWS-RunPatchBaselineWithHooks` verfügbar.)  
Die zugrunde liegenden Befehle für das Patchen mithilfe von Patch Manager verwenden `yum`- und `dnf`-Befehle. Daher führen die Operationen aufgrund der Art und Weise, wie Pakete installiert werden, zu Inkompatibilitäten. Informationen zu den bevorzugten Methoden für die Aktualisierung von Software auf Amazon-EMR-Clustern finden Sie unter [Verwenden des Standard-AMI für Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) im *Amazon EMR Management Guide*.

RebootIfNeeded  
Wenn Sie die Option `RebootIfNeeded` auswählen, wird die Instance in einem der folgenden Fälle neu gestartet:   
+ Patch Manager ist auf einem oder mehreren Patches installiert. 

  Patch Manager wertet nicht aus, ob ein Neustart vom Patch *erfordert* wird. Das System wird neu gestartet, auch wenn der Patch keinen Neustart erfordert.
+ Patch Manager erkennt ein oder mehrere Patches mit dem Status `INSTALLED_PENDING_REBOOT` während der `Install`-Operation. 

  Der `INSTALLED_PENDING_REBOOT`-Status kann bedeuten, dass die Option `NoReboot` ausgewählt wurde, als der `Install`-Vorgang das letzte Mal ausgeführt wurde, oder dass ein Patch außerhalb von Patch Manager seit dem letzten Neustart des verwalteten Knotens installiert wurde.
Durch den Neustart von Instances wird in diesen beiden Fällen sichergestellt, dass aktualisierte Pakete aus dem Speicher gelöscht werden und das Patch- und Neustartverhalten über alle Betriebssysteme hinweg konsistent bleibt.

NoReboot  
Wenn Sie die Option `NoReboot` auswählen, startet Patch Manager eine Instance nicht neu, selbst wenn über ihn während der `Install`-Operation Patches installiert wurden. Diese Option ist nützlich, wenn Sie wissen, dass für Ihre Instances nach dem Anwenden von Patches kein Neustart erforderlich ist oder Anwendungen bzw. Prozesse auf einer Instance ausgeführt werden, die nicht durch einen Neustart des Patches unterbrochen werden sollten. Sie ist auch nützlich, wenn Sie mehr Kontrolle über das Timing von Instance-Neustarts wünschen, z. B. durch die Verwendung eines Wartungsfensters.

**Datei zum Nachverfolgen der Patch-Installation (Tracking-Datei)**: Um die Patch-Installation nachzuverfolgen, insbesondere von Patches, die seit dem letzten Neustart des Systems installiert wurden, erstellt Systems Manager eine Datei auf der verwalteten Instance.

**Wichtig**  
Löschen oder ändern Sie die Tracking-Datei nicht. Wenn diese Datei gelöscht oder beschädigt wird, ist der Patch-Compliance-Bericht für die Instance ungenau. Starten Sie in diesem Fall die Instance neu und führen Sie einen Patch-Scan-Vorgang aus, um die Datei wiederherzustellen.

Diese Tracking-Datei wird an den folgenden Speicherorten auf Ihren verwalteten Instances gespeichert:
+ Linux-Betriebssysteme: 
  + `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
  + `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server-Betriebssystem:
  + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
  + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`

# SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaselineWithHooks`
<a name="patch-manager-aws-runpatchbaselinewithhooks"></a>

AWS Systems Manager unterstützt`AWS-RunPatchBaselineWithHooks`, ein Systems Manager Manager-Dokument (SSM-Dokument) fürPatch Manager, ein Tool in AWS Systems Manager. Dieses SSM-Dokument führt Patch-Operationen auf verwaltete Knoten sowohl für sicherheitsrelevante als auch für andere Arten von Updates durch. 

`AWS-RunPatchBaselineWithHooks` unterscheidet sich auf folgende Weise von `AWS-RunPatchBaseline`:
+ **Ein Wrapper-Dokument** – `AWS-RunPatchBaselineWithHooks` ist ein Wrapper für `AWS-RunPatchBaseline` und setzt für einige seiner Operationen auf`AWS-RunPatchBaseline`.
+ **Die `Install`-Operation** – `AWS-RunPatchBaselineWithHooks` unterstützt Lebenszyklus-Hooks, die während dem Patchen von verwalteten Knoten an festgelegten Punkten ausgeführt werden. Da Patch-Installationen manchmal den Neustart von verwalteten Knoten erfordern, ist die Patch-Operation in zwei Ereignisse unterteilt, wobei insgesamt drei Hooks enthalten sind, die benutzerdefinierte Funktion unterstützen. Der erste Hook ist vor der `Install with NoReboot`-Operation. Der zweite Hook ist nach der `Install with NoReboot`-Operation. Der dritte Hook ist nach dem Neustart des verwalteten Knoten verfügbar.
+ **Keine Unterstützung für benutzerdefinierte Patchlisten** – `AWS-RunPatchBaselineWithHooks` unterstützt den `InstallOverrideList`-Parameter nicht.
+ **SSM Agent-Support** – `AWS-RunPatchBaselineWithHooks` erfordert die Installation von SSM Agent 3.0.502 oder höher auf dem zu patchenden verwalteten Knoten.

Wenn das Dokument ausgeführt wird, verwendet es die Patch-Baseline, die aktuell der „Standard“ für einen Betriebssystemtyp ist, wenn keine Patch-Gruppe angegeben ist. Andernfalls werden die Patch-Baselines verwendet, die der Patch-Gruppe zugeordnet sind. Informationen zu Patch-Gruppen finden Sie unter [Patch-Gruppen](patch-manager-patch-groups.md). 

Sie können das Dokument `AWS-RunPatchBaselineWithHooks` verwenden, um Patches sowohl für Betriebssysteme als auch für Anwendungen durchzuführen. (Unter Windows Server ist der Anwendungssupport auf Updates für Microsoft-Anwendungen beschränkt.)

Dieses Dokument unterstützt von Linux und von Windows Server verwaltete Knoten. Das Dokument führt die entsprechenden Aktionen für jede Plattform durch.

**Anmerkung**  
`AWS-RunPatchBaselineWithHooks` wird in macOS nicht unterstützt.

------
#### [ Linux ]

Auf Linux-verwalteten Knoten ruft das Dokument `AWS-RunPatchBaselineWithHooks` ein Python-Modul auf, das wiederum einen entsprechenden Snapshot der Patch-Baseline für den verwalteten Knoten herunterlädt. Dieser Patch-Baseline-Snapshot verwendet die definierten Regeln und Listen der genehmigten und gesperrten Patches, um den entsprechenden Paketmanager für jeden Knoten-Typ anzutreiben: 
+ Von Amazon Linux 2, Oracle Linux und RHEL 7 verwaltete Knoten verwenden YUM. Für YUM-Operationen ist eine `Python 2.6` oder eine Patch Manager neuere unterstützte Version (2.6 - 3.12) erforderlich. Amazon Linux 2023 verwendet DNF. Für DNF-Operationen Patch Manager ist eine unterstützte Version von `Python 2` oder `Python 3` (2.6 - 3.12) erforderlich.
+ Von RHEL 8 verwaltete Knoten verwenden DNF. Für DNF-Operationen Patch Manager ist eine unterstützte Version von `Python 2` or `Python 3` (2.6 - 3.12) erforderlich. (Keine der beiden Versionen ist standardmäßig auf RHEL 8 installiert. Sie müssen die eine oder andere Version manuell installieren.)
+ Debian Serverund Ubuntu Server Instanzen verwenden APT. Für APT-Operationen Patch Manager ist eine unterstützte Version von `Python 3` (3.0 - 3.12) erforderlich.

------
#### [ Windows Server ]

Auf Windows Server verwalteten Knoten lädt das `AWS-RunPatchBaselineWithHooks` Dokument ein PowerShell Modul herunter und ruft es auf, das wiederum einen Snapshot der Patch-Baseline herunterlädt, die für den verwalteten Knoten gilt. Dieser Patch-Baseline-Snapshot enthält eine Liste genehmigter Patches, die kompiliert werden, indem die Patch-Baseline auf einem WSUS-Server (Windows Server Update Services) abgefragt wird. Diese Liste wird an die Windows Update-API weitergeleitet, die das Herunterladen und Installieren des genehmigten Patches entsprechend steuert. 

------

Jeder Snapshot ist spezifisch für eine AWS-Konto Patch-Gruppe, ein Betriebssystem und eine Snapshot-ID. Der Snapshot wird über eine vorsignierte Amazon Simple Storage Service (Amazon S3)-URL bereitgestellt, die 24 Stunden nach Erstellung des Snapshots abläuft. Wenn Sie jedoch denselben Snapshot-Inhalt auf andere verwaltete Knoten anwenden möchten, können Sie nach Ablauf der URL bis zu drei Tage nach Erstellung des Snapshots eine neue vorsignierte Amazon-S3-URL generieren. Verwenden Sie dazu den Befehl [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html). 

Nachdem alle genehmigten und zutreffenden Updates installiert und je nach Bedarf Neustarts durchgeführt wurden, werden Patch-Compliance-Informationen auf einem verwalteten Knoten generiert und wieder an Patch Manager gemeldet. 

Wenn der Parameter `RebootOption` im Dokument `AWS-RunPatchBaselineWithHooks` auf `NoReboot` gesetzt ist, wird der verwaltete Knoten nach dem Ausführen von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).

**Wichtig**  
Die Option `NoReboot` verhindert zwar Neustarts des Betriebssystems, aber keine Neustarts auf Service-Ebene, die beim Aktualisieren bestimmter Pakete erfolgen können. Beispielsweise kann die Aktualisierung von Paketen wie Docker automatische Neustarts abhängiger Services auslösen (etwa Container-Orchestrierungsservices), selbst wenn `NoReboot` angegeben ist.

Weitere Informationen zum Anzeigen von Patch-Compliance-Daten finden Sie unter [Info zu Patch Compliance](compliance-about.md#compliance-monitor-patch).

## `AWS-RunPatchBaselineWithHooks`-Betriebsschritte
<a name="patch-manager-aws-runpatchbaselinewithhooks-steps"></a>

Wenn `AWS-RunPatchBaselineWithHooks` ausgeführt wird, werden die folgenden Schritte durchgeführt:

1. **Scan** – Eine `Scan`-Operation mit `AWS-RunPatchBaseline` wird auf dem verwalteten Knoten ausgeführt und ein Compliance-Bericht wird generiert und hochgeladen. 

1. **Überprüfen der lokalen Patch-Zustände** – Ein Skript wird ausgeführt, um zu bestimmen, welche Schritte auf der Grundlage der ausgewählten Operation und dem `Scan`-Ergebnis aus Schritt 1 ausgeführt werden. 

   1. Wenn die ausgewählte Operation `Scan` ist, wird die Operation als abgeschlossen markiert. Die Operation ist abgeschlossen. 

   1. Wenn die ausgewählte Operation `Install` ist, werte Patch Manager das `Scan`-Ergebnis aus Schritt 1, um zu bestimmen, was als nächstes ausgeführt werden soll: 

      1. Wenn keine fehlenden Patches erkannt werden und keine ausstehenden Neustarts erforderlich sind, fährt die Operation direkt mit dem letzten Schritt (Schritt 8) fort, der einen von Ihnen bereitgestellten Hook enthält. Alle Schritte dazwischen werden übersprungen. 

      1. Wenn keine fehlenden Patches erkannt werden, aber ausstehende Neustarts erforderlich sind und die Neustartoption `NoReboot` ist, fährt die Operation direkt mit dem letzten Schritt (Schritt 8) fort, der einen von Ihnen bereitgestellten Hook enthält. Alle Schritte dazwischen werden übersprungen. 

      1. Andernfalls fährt die Operation mit dem nächsten Schritt fort.

1. **Hook-Operation vor dem Patchen** – Das SSM-Dokument, das Sie für den ersten Lebenszyklus-Hook bereitgestellt haben, `PreInstallHookDocName` wird auf dem verwalteten Knoten ausgeführt. 

1. **Installation mit NoReboot** — Auf dem verwalteten Knoten `AWS-RunPatchBaseline` wird ein `Install` Vorgang `NoReboot` mit der Neustartoption ausgeführt, und es wird ein Konformitätsbericht generiert und hochgeladen. 

1. **Hook-Operation nach der Installation** – Das SSM-Dokument, das Sie für den zweiten Lebenszyklus-Hook bereitgestellt haben, `PostInstallHookDocName` wird auf dem verwalteten Knoten ausgeführt.

1. **Überprüfen des Neustarts** – Ein Skript wird ausgeführt, um festzustellen, ob ein Neustart für den verwalteten Knoten erforderlich ist und welche Schritte ausgeführt werden sollen:

   1. Wenn die ausgewählte Neustartoption `NoReboot` ist, geht die Operation direkt zum letzten Schritt (Schritt 8) über, der einen von Ihnen bereitgestellten Hook enthält. Alle Schritte dazwischen werden übersprungen. 

   1. Wenn die ausgewählte Neustartoption `RebootIfNeeded` ist, prüft Patch Manager, ob ausstehende Neustarts aus dem in Schritt 4 erfassten Bestand erforderlich sind. Dies bedeutet, dass der Vorgang mit Schritt 7 fortgesetzt wird und der verwaltete Knoten in einem der folgenden Fälle neu gestartet wird:

      1. Patch Manager hat einen oder mehrere Patches installiert. (Patch Manager wertet nicht aus, ob für den Patch ein Neustart erforderlich ist. Das System wird auch dann neu gestartet, wenn der Patch keinen Neustart erfordert.)

      1. Patch Manager erkennt ein oder mehrere Patches mit dem Status `INSTALLED_PENDING_REBOOT` während des Installationsvorgangs. Der `INSTALLED_PENDING_REBOOT`-Status kann bedeuten, dass die Option `NoReboot` ausgewählt wurde, als der Installations-Vorgang das letzte Mal ausgeführt wurde, oder dass ein Patch außerhalb von Patch Manager seit dem letzten Neustart des verwalteten Knotens installiert wurde. 

      Wenn keine Patches gefunden werden, die diese Kriterien erfüllen, ist der Patch-Vorgang für verwaltete Knoten abgeschlossen, und der Vorgang fährt direkt mit dem letzten Schritt (Schritt 8) fort, der einen von Ihnen bereitgestellten Hook enthält. Alle Schritte dazwischen werden übersprungen.

1. **Neustart und Bericht** – Eine Installations-Operation mit der Neustart-Option `RebootIfNeeded` wird auf dem verwalteten Knoten unter Verwendung von `AWS-RunPatchBaseline` ausgeführt und ein Compliance-Bericht wird generiert und hochgeladen. 

1. **Hook-Operation nach Neustart** – Das SSM-Dokument, das Sie für den dritten Lebenszyklus-Hook bereitgestellt haben, `OnExitHookDocName` wird auf dem verwalteten Knoten ausgeführt. 

Bei einer `Scan`-Operation wird der Prozess der Ausführung des Dokuments beendet, wenn Schritt 1 fehlschlägt, und der Schritt wird als fehlgeschlagen gemeldet, obwohl nachfolgende Schritte als erfolgreich gemeldet werden. 

 Wenn bei einem `Install`-Vorgang einer der `aws:runDocument`-Schritte während des Vorgangs fehlschlagen, werden diese Schritte als fehlgeschlagen gemeldet, und der Vorgang fährt direkt mit dem letzten Schritt (Schritt 8) fort, der einen von Ihnen bereitgestellten Hook enthält. Alle Schritte dazwischen werden übersprungen. Dieser Schritt wird als fehlgeschlagen gemeldet, der letzte Schritt meldet den Status des Vorgangsergebnisses, und alle dazwischen liegenden Schritte werden als erfolgreich gemeldet.

## `AWS-RunPatchBaselineWithHooks`-Parameter
<a name="patch-manager-aws-runpatchbaselinewithhooks-parameters"></a>

`AWS-RunPatchBaselineWithHooks` unterstützt sechs Parameter. 

Der Parameter `Operation` muss angegeben werden. 

Die Parameter `RebootOption`, `PreInstallHookDocName`, `PostInstallHookDocName` und `OnExitHookDocName` sind optional. 

`Snapshot-ID` ist eigentlich optional, wir empfehlen jedoch, einen benutzerdefinierten Wert dafür anzugeben, wenn Sie `AWS-RunPatchBaselineWithHooks` außerhalb eines Wartungsfensters ausführen. Lassen Sie Patch Manager den Wert automatisch angeben, wenn das Dokument als Teil einer Wartungsfenster-Operation ausgeführt wird.

**Topics**
+ [Parametername: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Parametername: `Snapshot ID`](#patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id)
+ [Parametername: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)
+ [Parametername: `PreInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname)
+ [Parametername: `PostInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname)
+ [Parametername: `OnExitHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname)

### Parametername: `Operation`
<a name="patch-manager-aws-runpatchbaseline-parameters-operation"></a>

**Nutzung**: erforderlich.

**Optionen**: `Scan` \$1 `Install`. 

Scan  
Wenn Sie die Option `Scan` wählen, verwende das System das Dokument `AWS-RunPatchBaseline`, um den Patch-Compliance-Zustand des verwalteten Knoten zu bestimmen und diese Informationen an Patch Manager zu melden. `Scan` fordert nicht zum Installieren von Updates oder zum Neustarten von verwalteten Knoten auf. Stattdessen erkennt die Operation, wo für den Knoten genehmigte und geeignete Updates fehlen. 

Installieren  
Bei Auswahl der Option `Install` versucht `AWS-RunPatchBaselineWithHooks`, die genehmigten und geeigneten Updates zu installieren, die auf dem verwalteten Knoten fehlen. Patch-Compliance-Informationen, die als Teil eines `Install`-Vorgangs generiert wurden, enthalten keine fehlenden Updates, melden allerdings möglicherweise Updates im Fehlerzustand, wenn die Installation des Updates aus einem beliebigen Grund nicht erfolgreich war. Immer wenn ein Update auf einem verwalteten Knoten installiert wird, wird der Knoten neu gestartet, um sicherzustellen, dass das Update installiert und aktiviert ist. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaselineWithHooks` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption).)  
Wenn ein von den Basisregeln festgelegter Patch installiert wird, *bevor* der Patch Manager den verwalteten Knoten aktualisiert, wird das System möglicherweise nicht wie erwartet neu gestartet. Dies kann passieren, wenn ein Patch manuell von einem Benutzer oder automatisch von einem anderen Programm, z. B. dem `unattended-upgrades`-Paket auf Ubuntu Server, installiert wird.

### Parametername: `Snapshot ID`
<a name="patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id"></a>

**Nutzung**: optional.

`Snapshot ID` ist eine eindeutige ID (GUID), die von Patch Manager verwendet wird, um sicherzustellen, dass ein Satz von verwalteten Knoten, für die in einer einzelnen Operation Patches durchgeführt werden, den genau gleichen Satz genehmigter Patches aufweist. Auch wenn der Parameter als optional definiert ist, hängen unsere Empfehlungen für bewährte Methoden davon ab, ob Sie `AWS-RunPatchBaselineWithHooks` in einem Wartungsfenster, wie in der folgenden Tabelle beschrieben, ausführen.


**Bewährte Methoden für `AWS-RunPatchBaselineWithHooks`**  

| Mode | Bewährte Methode | Details | 
| --- | --- | --- | 
| Ausführen von AWS-RunPatchBaselineWithHooks innerhalb eines Wartungsfensters | Geben Sie keine Snapshot ID an. Patch Manager wird sie für Sie bereitstellen. |  Falls Sie ein Wartungsfenster zum Ausführen von `AWS-RunPatchBaselineWithHooks` verwenden, dürfen Sie Ihre eigene generierte Snapshot ID nicht angeben. In diesem Szenario stellt Systems Manager einen GUID-Wert auf Grundlage der Wartungsfensterausführungs-ID bereit. Auf diese Weise wird sichergestellt, dass eine richtige ID für alle Aufrufe von `AWS-RunPatchBaselineWithHooks` in diesem Wartungsfenster verwendet wird.  Wenn Sie einen Wert in diesem Szenario angeben, beachten Sie, dass der Snapshot der Patch-Baseline möglicherweise nicht länger als drei Tagen erhalten bleibt. Danach wird ein neuer Snapshot erstellt, auch wenn Sie dieselbe ID angeben, nachdem der Snapshot abgelaufen ist.   | 
| Ausführen von AWS-RunPatchBaselineWithHooks außerhalb eines Wartungsfensters | Generieren Sie einen benutzerdefinierten GUID-Wert für die Snapshot-ID und geben Sie ihn an.¹ |  Wenn Sie kein Wartungsfenster zum Ausführen von `AWS-RunPatchBaselineWithHooks` verwenden, empfehlen wir, dass Sie eine eindeutige Snapshot-ID für jede Patch-Baseline generieren und angeben, insbesondere wenn Sie das Dokument `AWS-RunPatchBaselineWithHooks` auf mehreren verwaltete Knoten in derselben Operation ausführen. Wenn Sie keine ID in diesem Szenario angeben, generiert Systems Manager eine andere Snapshot-ID für jeden verwalteten Knoten, an den der Befehl gesendet wird. Dies kann zu unterschiedlichen Sätzen von Patches führen, die auf den Knoten angegeben sind. Angenommen, Sie führen das Dokument `AWS-RunPatchBaselineWithHooks` direkt über Run Command aus, ein Tool in AWS Systems Manager, und richten es auf eine Gruppe von 50 verwalteten Knoten aus. Das Angeben einer benutzerdefinierten Snapshot-ID führt zur Erstellung eines einzelnen Baseline-Snapshots, der verwendet wird, um alle verwaltete Knoten zu bewerten und zu patchen. Dadurch wird gewährleistet, dass sie letztendlich einen konsistenten Zustand aufweisen.   | 
|  ¹ Sie können jedes beliebige Tool zum Generieren eines Werts für den Snapshot-ID-Parameter verwenden, das eine GUID generieren kann. In können Sie PowerShell beispielsweise das `New-Guid` Cmdlet verwenden, um eine GUID im Format von zu generieren. `12345699-9405-4f69-bc5e-9315aEXAMPLE`  | 

### Parametername: `RebootOption`
<a name="patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption"></a>

**Nutzung**: optional.

**Optionen**: `RebootIfNeeded` \$1 `NoReboot` 

**Standardwert**: `RebootIfNeeded`

**Warnung**  
Die Standardoption ist `RebootIfNeeded`. Stellen Sie sicher, dass Sie die richtige Option für Ihren Anwendungsfall auswählen. Wenn Ihre verwalteten Knoten beispielsweise sofort neu gestartet werden müssen, um einen Konfigurationsprozess abzuschließen, wählen Sie `RebootIfNeeded` aus. Oder wenn Sie die Verfügbarkeit von verwalteten Knoten bis zu einer geplanten Neustartzeit beibehalten müssen, wählen Sie `NoReboot` aus.

**Wichtig**  
Wir empfehlen nicht, Cluster-Instances in Amazon EMR (früher Amazon Elastic MapReduce genannt) zum Patchen zu verwendenPatch Manager. Wählen Sie insbesondere nicht die Option `RebootIfNeeded` für den Parameter `RebootOption` aus. (Diese Option ist in den SSM-Befehlsdokumenten für das Patchen von `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` und `AWS-RunPatchBaselineWithHooks` verfügbar.)  
Die zugrunde liegenden Befehle für das Patchen mithilfe von Patch Manager verwenden `yum`- und `dnf`-Befehle. Daher führen die Operationen aufgrund der Art und Weise, wie Pakete installiert werden, zu Inkompatibilitäten. Informationen zu den bevorzugten Methoden für die Aktualisierung von Software auf Amazon-EMR-Clustern finden Sie unter [Verwenden des Standard-AMI für Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) im *Amazon EMR Management Guide*.

RebootIfNeeded  
Wenn Sie die Option `RebootIfNeeded` auswählen, wird der verwaltete Knoten in einem der folgenden Fälle neu gestartet:   
+ Patch Manager ist auf einem oder mehreren Patches installiert. 

  Patch Manager wertet nicht aus, ob ein Neustart vom Patch *erfordert* wird. Das System wird neu gestartet, auch wenn der Patch keinen Neustart erfordert.
+ Patch Manager erkennt ein oder mehrere Patches mit dem Status `INSTALLED_PENDING_REBOOT` während der `Install`-Operation. 

  Der `INSTALLED_PENDING_REBOOT`-Status kann bedeuten, dass die Option `NoReboot` ausgewählt wurde, als der `Install`-Vorgang das letzte Mal ausgeführt wurde, oder dass ein Patch außerhalb von Patch Manager seit dem letzten Neustart des verwalteten Knotens installiert wurde.
Durch den Neustart von verwalteten Knoten wird in diesen beiden Fällen sichergestellt, dass aktualisierte Pakete aus dem Speicher gelöscht werden und das Patch- und Neustartverhalten über alle Betriebssysteme hinweg konsistent bleibt.

NoReboot  
Wenn Sie die Option `NoReboot` auswählen, startet Patch Manager einen verwalteten Knoten nicht neu, selbst wenn über ihn während der `Install`-Operation Patches installiert wurden. Diese Option ist nützlich, wenn Sie wissen, dass für Ihre verwalteten Knoten nach dem Anwenden von Patches kein Neustart erforderlich ist oder Anwendungen bzw. Prozesse auf einem Knoten ausgeführt werden, die nicht durch einen Neustart beim Patchen unterbrochen werden sollten. Sie ist auch nützlich, wenn Sie mehr Kontrolle über das Timing von Neustarts von verwalteten Knoten wünschen, z. B. durch die Verwendung eines Wartungsfensters.  
Wenn Sie die Option `NoReboot` auswählen und ein Patch installiert ist, wird dem Patch der Status `InstalledPendingReboot` zugewiesen. Der verwaltete Knoten selbst wird jedoch als `Non-Compliant` gekennzeichnet. Nach einem Neustart und Ausführung einer `Scan`-Operation wird der Knoten-Status in `Compliant` aktualisiert.

**Datei zum Nachverfolgen der Patch-Installation**: Um die Patch-Installation nachzuverfolgen, insbesondere von Patches, die seit dem letzten Neustart des Systems installiert wurden, erstellt Systems Manager eine Datei auf dem verwalteten Knoten.

**Wichtig**  
Löschen oder ändern Sie die Tracking-Datei nicht. Wenn diese Datei gelöscht oder beschädigt wird, ist der Patch-Compliance-Bericht für den verwalteten Knoten ungenau. Starten Sie in diesem Fall den Knoten neu und führen Sie eine Patch-Scan-Operation aus, um die Datei wiederherzustellen.

Diese Tracking-Datei wird an den folgenden Speicherorten auf Ihren verwalteten Knoten gespeichert:
+ Linux-Betriebssysteme: 
  + `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
  + `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server-Betriebssystem:
  + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
  + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`

### Parametername: `PreInstallHookDocName`
<a name="patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname"></a>

**Nutzung**: optional.

**Standard**: `AWS-Noop`. 

Der Wert, der für den `PreInstallHookDocName`-Parameter anzugeben ist, ist der Name oder der Amazon-Ressourcenname (ARN) eines SSM-Dokuments Ihrer Wahl. Sie können den Namen eines AWS verwalteten Dokuments oder den Namen oder ARN eines benutzerdefinierten SSM-Dokuments angeben, das Sie erstellt haben oder das für Sie freigegeben wurde. (Für ein SSM-Dokument, das von einem anderen für Sie freigegeben wurde AWS-Konto, müssen Sie den vollständigen Ressourcen-ARN angeben, z. `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument` B.)

Das von Ihnen angegebene SSM-Dokument wird vor der `Install`-Operation ausgeführt und führt alle Aktionen aus, die von SSM Agent unterstützt werden, z. B. ein Shell-Skript, um die Zustandsprüfung der Anwendung zu überprüfen, bevor der verwaltete Knoten gepatcht wird. (Eine Liste der Aktionen finden Sie unter [Referenz für Befehlsdokument-Plugins](documents-command-ssm-plugin-reference.md)). Der SSM-Dokumentname ist standardmäßig `AWS-Noop`, was keine Operation für den verwalteten Knoten ausführt. 

Informationen zum Erstellen eines benutzerdefinierten SSM-Dokuments finden Sie unter [Erstellen von SSM-Dokumentinhalten](documents-creating-content.md). 

### Parametername: `PostInstallHookDocName`
<a name="patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname"></a>

**Nutzung**: optional.

**Standard**: `AWS-Noop`. 

Der Wert, der für den `PostInstallHookDocName`-Parameter anzugeben ist, ist der Name oder der Amazon-Ressourcenname (ARN) eines SSM-Dokuments Ihrer Wahl. Sie können den Namen eines AWS verwalteten Dokuments oder den Namen oder ARN eines benutzerdefinierten SSM-Dokuments angeben, das Sie erstellt haben oder das für Sie freigegeben wurde. (Für ein SSM-Dokument, das von einem anderen für Sie freigegeben wurde AWS-Konto, müssen Sie den vollständigen Ressourcen-ARN angeben, z. `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument` B.)

Das von Ihnen angegebene SSM-Dokument wird nach der `Install with NoReboot`-Operation ausgeführt und führt alle Aktionen aus, die von SSM Agent unterstützt werden, z. B. ein Shell-Skript zum Installieren von Updates von Drittanbietern vor dem Neustart. (Eine Liste der Aktionen finden Sie unter [Referenz für Befehlsdokument-Plugins](documents-command-ssm-plugin-reference.md)). Der SSM-Dokumentname ist standardmäßig `AWS-Noop`, was keine Operation für den verwalteten Knoten ausführt. 

Informationen zum Erstellen eines benutzerdefinierten SSM-Dokuments finden Sie unter [Erstellen von SSM-Dokumentinhalten](documents-creating-content.md). 

### Parametername: `OnExitHookDocName`
<a name="patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname"></a>

**Nutzung**: optional.

**Standard**: `AWS-Noop`. 

Der Wert, der für den `OnExitHookDocName`-Parameter anzugeben ist, ist der Name oder der Amazon-Ressourcenname (ARN) eines SSM-Dokuments Ihrer Wahl. Sie können den Namen eines AWS verwalteten Dokuments oder den Namen oder ARN eines benutzerdefinierten SSM-Dokuments angeben, das Sie erstellt haben oder das für Sie freigegeben wurde. (Für ein SSM-Dokument, das aus einem anderen AWS-Konto freigegeben wurde, müssen Sie den vollständigen Ressourcen-ARN angeben, z. B. `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`.)

Das von Ihnen angegebene SSM-Dokument wird nach dem Neustart des verwalteten Knoten ausgeführt und führt alle Aktionen aus, die von SSM Agent unterstützt werden, z. B. ein Shell-Skript, um den Knoten-Zustand nach Abschluss des Patchvorgangs zu überprüfen. (Eine Liste der Aktionen finden Sie unter [Referenz für Befehlsdokument-Plugins](documents-command-ssm-plugin-reference.md)). Der SSM-Dokumentname ist standardmäßig `AWS-Noop`, was keine Operation für den verwalteten Knoten ausführt. 

Informationen zum Erstellen eines benutzerdefinierten SSM-Dokuments finden Sie unter [Erstellen von SSM-Dokumentinhalten](documents-creating-content.md). 

# Beispielszenario für die Verwendung des InstallOverrideList Parameters in `AWS-RunPatchBaseline` oder `AWS-RunPatchBaselineAssociation`
<a name="patch-manager-override-lists"></a>

Sie können den Parameter `InstallOverrideList` verwenden, wenn Sie die von der aktuellen Standard-Patch-Baseline in Patch Manager, ein Tool in AWS Systems Manager, angegebenen Patches überschreiben möchten. In diesem Thema finden Sie Beispiele, die zeigen, wie Sie diesen Parameter verwenden, um Folgendes zu erreichen:
+ Anwendung verschiedener Sätzen von Patches auf eine Zielgruppe von verwalteten Knoten.
+ Anwendung dieser Patch-Sets auf verschiedene Häufigkeiten
+ Verwendung derselben Patch-Baseline für beide Operationen

Angenommen, Sie möchten zwei verschiedene Kategorien von Patches auf Ihren von Amazon Linux 2 verwalteten Knoten installieren. Sie möchten diese Patches mithilfe von Wartungsfenstern nach verschiedenen Zeitplänen installieren. Sie möchten, dass jede Woche ein Wartungsfenster ausgeführt wird und alle `Security`-Patches installiert werden. Sie möchten, dass einmal im Monat ein weiteres Wartungsfenster ausgeführt wird und dabei alle verfügbaren Patches oder Kategorien von Patches außer `Security` installiert werden. 

Es kann jedoch nur jeweils eine Patch-Baseline als Standard für ein Betriebssystem definiert werden. Diese Anforderung hilft, Situationen zu vermeiden, in denen eine Patch-Baseline einen Patch genehmigt, während eine andere ihn blockiert, was zu Problemen zwischen in Konflikt stehenden Versionen führen kann.

Mit der folgenden Strategie können Sie den Parameter `InstallOverrideList` verwenden, um verschiedene Patch-Typen nach verschiedenen Zeitplänen auf eine Zielgruppe anzuwenden und dabei dennoch dieselbe Patch-Baseline zu verwenden:

1. Stellen Sie in der Standard-Patch-Baseline sicher, dass nur `Security`-Updates angegeben sind.

1. Erstellen Sie ein Wartungsfenster, das `AWS-RunPatchBaseline` oder `AWS-RunPatchBaselineAssociation` jede Woche ausführt. Geben Sie keine Überschreibungsliste an.

1. Erstellen Sie eine Überschreibungsliste der Patches aller Typen, die Sie monatlich anwenden möchten, und speichern Sie sie in einem Amazon Simple Storage Service (Amazon S3)-Bucket. 

1. Erstellen Sie ein zweites Wartungsfenster, das einmal im Monat ausgeführt wird. Geben Sie für die Run Command-Aufgabe, die Sie für dieses Wartungsfenster registrieren, jedoch den Speicherort Ihrer Überschreibungsliste an.

Das Ergebnis: Jede Woche werden nur `Security`-Patches installiert, wie in Ihrer Standard-Patch-Baseline definiert. Die Installation aller verfügbaren Patches oder einer von Ihnen definierten Teilmenge von Patches erfolgt jeden Monat.

**Anmerkung**  
Wenn Sie einen Knoten patchen, der nur verwendet IPv6, stellen Sie sicher, dass die angegebene URL vom Knoten aus erreichbar ist. Wenn die SSM Agent Konfigurationsoption auf gesetzt `UseDualStackEndpoint` ist`true`, wird ein Dual-Stack-S3-Client verwendet, wenn eine S3-URL bereitgestellt wird. Weitere Informationen [Tutorial: Einen Server in einer IPv6 einzigen Umgebung patchen](patch-manager-server-patching-iPv6-tutorial.md) zur Konfiguration des Agenten für die Verwendung von Dualstack finden Sie unter.

Weitere Informationen und Beispiellisten finden Sie unter [Parametername: `InstallOverrideList`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist).

# Verwenden des BaselineOverride Parameters
<a name="patch-manager-baselineoverride-parameter"></a>

Sie können Patching-Voreinstellungen zur Laufzeit mit der Baseline-Überschreibungsfunktion in Patch Manager definieren, einem Tool in AWS Systems Manager. Geben Sie dazu einen Amazon Simple Storage Service (Amazon S3)-Bucket an, der ein JSON-Objekt mit einer Liste mit Patch-Baselines enthält. Beim Patchvorgang werden die im JSON-Objekt bereitgestellten Baselines verwendet, die mit dem Hostbetriebssystem übereinstimmen, anstatt die Regeln aus der Standard-Patch-Baseline anzuwenden.

**Wichtig**  
Der `BaselineOverride`-Dateiname darf die folgenden Zeichen nicht enthalten: Backtick (`), einfaches Anführungszeichen ('), doppeltes Anführungszeichen („) und Dollarzeichen (\$1).

Wenn Sie Patch-Policy verwenden, wird die Patch-Compliance der im `BaselineOverride`-Parameter angegebenen Baseline nicht überschrieben. Die Ausgabe wird in den Stdout-Protokollen von Run Command aufgezeichnet, einem Tool in AWS Systems Manager. Die Ergebnisse drucken nur Pakete aus, die als `NON_COMPLIANT` gekennzeichnet sind. Das bedeutet, dass das Paket als `Missing`, `Failed`, `InstalledRejected` oder `InstalledPendingReboot` gekennzeichnet ist.

Wenn ein Patch-Vorgang jedoch eine Patch-Richtlinie verwendet, übergibt das System den Override-Parameter aus dem zugehörigen S3-Bucket, und der Compliance-Wert wird für den verwalteten Knoten aktualisiert. Weitere Informationen zum Patch-Richtlinienverhalten finden Sie unter [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md).

**Anmerkung**  
Wenn Sie einen Knoten patchen, der nur verwendet IPv6, stellen Sie sicher, dass die angegebene URL vom Knoten aus erreichbar ist. Wenn die SSM Agent Konfigurationsoption auf gesetzt `UseDualStackEndpoint` ist`true`, wird ein Dual-Stack-S3-Client verwendet, wenn eine S3-URL bereitgestellt wird. Weitere Informationen [Tutorial: Einen Server in einer IPv6 einzigen Umgebung patchen](patch-manager-server-patching-iPv6-tutorial.md) zur Konfiguration des Agenten für die Verwendung von Dualstack finden Sie unter.

## Verwenden der Patch-Baseline-Überschreibung mit den Parametern „Snapshot-ID“ oder „Install Override List“
<a name="patch-manager-baselineoverride-parameter-other-parameters"></a>

Es gibt zwei Fälle, in denen die Patch-Baseline-Überschreibung ein bemerkenswertes Verhalten aufweist.

**Gleichzeitiges Verwenden von Baseline-Überschreiben und Snapshot-ID**  
Snapshot-IDs stellen sicher, dass alle verwalteten Knoten in einem bestimmten Patching-Befehl dasselbe anwenden. Wenn Sie beispielsweise 1 000 Knoten gleichzeitig patchen, sind die Patches identisch.

Wenn Sie sowohl eine Snapshot-ID als auch eine Patch-Baseline-Überschreibung verwenden, hat die Snapshot-ID Vorrang vor der Patch-Baseline-Überschreibung. Die Baseline-Überschreibungsregeln werden weiterhin verwendet, aber sie werden nur einmal ausgewertet. Im vorangegangenen Beispiel sind die Patches für Ihre 1 000 verwaltete Knoten immer gleich. Wenn Sie in der Mitte des Patching-Vorgangs die JSON-Datei im referenzierten S3-Bucket auf etwas anderes geändert haben, sind die angewendeten Patches immer noch identisch. Dies liegt daran, dass die Snapshot-ID bereitgestellt wurde.

**Gleichzeitiges Verwenden der Baseline-Überschreibung und des Parameters „Override List“**  
Sie können diese beiden Parameter nicht gleichzeitig verwenden. Das Patching-Dokument schlägt fehl, wenn beide Parameter angegeben sind, und es führt keine Scans oder Installationen auf dem verwalteten Knoten durch.

## Codebeispiele
<a name="patch-manager-baselineoverride-parameter-code"></a>

Das folgende Codebeispiel für Python zeigt, wie die Patch-Baseline-Überschreibung generiert wird.

```
import boto3
import json

ssm = boto3.client('ssm')
s3 = boto3.resource('s3')
s3_bucket_name = 'my-baseline-override-bucket'
s3_file_name = 'MyBaselineOverride.json'
baseline_ids_to_export = ['pb-0000000000000000', 'pb-0000000000000001']

baseline_overrides = []
for baseline_id in baseline_ids_to_export:
    baseline_overrides.append(ssm.get_patch_baseline(
        BaselineId=baseline_id
    ))

json_content = json.dumps(baseline_overrides, indent=4, sort_keys=True, default=str)
s3.Object(bucket_name=s3_bucket_name, key=s3_file_name).put(Body=json_content)
```

So wird eine Patch-Baseline-Überschreibung wie die folgende erstellt.

```
[
    {
        "ApprovalRules": {
            "PatchRules": [
                {
                    "ApproveAfterDays": 0, 
                    "ComplianceLevel": "UNSPECIFIED", 
                    "EnableNonSecurity": false, 
                    "PatchFilterGroup": {
                        "PatchFilters": [
                            {
                                "Key": "PRODUCT", 
                                "Values": [
                                    "*"
                                ]
                            }, 
                            {
                                "Key": "CLASSIFICATION", 
                                "Values": [
                                    "*"
                                ]
                            }, 
                            {
                                "Key": "SEVERITY", 
                                "Values": [
                                    "*"
                                ]
                            }
                        ]
                    }
                }
            ]
        }, 
        "ApprovedPatches": [], 
        "ApprovedPatchesComplianceLevel": "UNSPECIFIED", 
        "ApprovedPatchesEnableNonSecurity": false, 
        "GlobalFilters": {
            "PatchFilters": []
        }, 
        "OperatingSystem": "AMAZON_LINUX_2", 
        "RejectedPatches": [], 
        "RejectedPatchesAction": "ALLOW_AS_DEPENDENCY", 
        "Sources": []
    }, 
    {
        "ApprovalRules": {
            "PatchRules": [
                {
                    "ApproveUntilDate": "2021-01-06", 
                    "ComplianceLevel": "UNSPECIFIED", 
                    "EnableNonSecurity": true, 
                    "PatchFilterGroup": {
                        "PatchFilters": [
                            {
                                "Key": "PRODUCT", 
                                "Values": [
                                    "*"
                                ]
                            }, 
                            {
                                "Key": "CLASSIFICATION", 
                                "Values": [
                                    "*"
                                ]
                            }, 
                            {
                                "Key": "SEVERITY", 
                                "Values": [
                                    "*"
                                ]
                            }
                        ]
                    }
                }
            ]
        }, 
        "ApprovedPatches": [
            "open-ssl*"
        ], 
        "ApprovedPatchesComplianceLevel": "UNSPECIFIED", 
        "ApprovedPatchesEnableNonSecurity": false, 
        "GlobalFilters": {
            "PatchFilters": []
        }, 
        "OperatingSystem": "SUSE", 
        "RejectedPatches": [
            "python*"
        ], 
        "RejectedPatchesAction": "ALLOW_AS_DEPENDENCY", 
        "Sources": []
    }
]
```

# Patch-Baselines
<a name="patch-manager-patch-baselines"></a>

In den Themen in diesem Abschnitt finden Sie Informationen zur Funktionsweise von Patch-Baselines in Patch Manager, einem Tool in AWS Systems Manager, wenn Sie einen `Scan`- oder `Install`-Vorgang auf Ihren verwalteten Knoten ausführen.

**Topics**
+ [Vordefinierte und benutzerdefinierte Patch-Baselines](patch-manager-predefined-and-custom-patch-baselines.md)
+ [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md)
+ [Patch-Gruppen](patch-manager-patch-groups.md)
+ [Informationen zum Patchen von Anwendungen, die von Microsoft unter Windows Server veröffentlicht wurden](patch-manager-patching-windows-applications.md)

# Vordefinierte und benutzerdefinierte Patch-Baselines
<a name="patch-manager-predefined-and-custom-patch-baselines"></a>

Patch Manager, ein Tool in AWS Systems Manager, bietet vordefinierte Patch-Baselines für jedes der Betriebssysteme, die von unterstützt werden. Patch Manager Sie können diese Baselines in ihrer aktuellen Konfiguration verwenden (eine Anpassung ist nicht möglich) oder eigene benutzerdefinierte Patch-Baselines erstellen. Benutzerdefinierte Patch-Baselines ermöglichen Ihnen eine bessere Kontrolle darüber, welche Patches für Ihre Umgebung genehmigt oder abgelehnt werden. Außerdem weisen die vordefinierten Baselines allen Patches, die mit diesen Baselines installiert wurden, die Compliance-Ebene `Unspecified` zu. Für die Zuweisung von Compliance-Werten können Sie eine Kopie einer vordefinierten Baseline erstellen und die Compliance-Werte angeben, die Patches zugewiesen werden sollen. Weitere Informationen erhalten Sie unter [Benutzerdefinierte Baselines](#patch-manager-baselines-custom) und [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md).

**Anmerkung**  
Die Informationen in diesem Thema gelten unabhängig davon, welche Methode oder Art der Konfiguration Sie für Ihren Patching-Vorgang verwenden:  
Eine in Quick Setup konfigurierte Patch-Richtlinie
Eine in Quick Setup konfigurierte Host-Management-Option
Ein Wartungsfenster zum Ausführen eines Patch-`Scan` oder einer `Install`-Aufgabe
Ein On-Demand-**Jetzt patchen**-Vorgang

**Topics**
+ [Vordefinierte Baselines](#patch-manager-baselines-pre-defined)
+ [Benutzerdefinierte Baselines](#patch-manager-baselines-custom)

## Vordefinierte Baselines
<a name="patch-manager-baselines-pre-defined"></a>

Die folgende Tabelle beschreibt die mit Patch Manager bereitgestellten vordefinierten Patch-Baselines.

Informationen dazu, welche Versionen der einzelnen Betriebssysteme von Patch Manager unterstützt werden, finden Sie unter [Patch Manager-Voraussetzungen](patch-manager-prerequisites.md).


****  

| Name | Unterstütztes Betriebssystem | Details | 
| --- | --- | --- | 
|  `AWS-AlmaLinuxDefaultPatchBaseline`  |  AlmaLinux  |  Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Genehmigt außerdem alle Patches mit der Klassifizierung „Bugfix“. Patches werden sieben Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.¹  | 
| AWS-AmazonLinux2DefaultPatchBaseline | Amazon Linux 2 | Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Genehmigt außerdem alle Patches mit der Klassifizierung „Bugfix“. Patches werden automatisch sieben Tage nach der Veröffentlichung genehmigt.¹ | 
| AWS-AmazonLinux2023DefaultPatchBaseline | Amazon Linux 2023 |  Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Patches werden automatisch sieben Tage nach der Veröffentlichung genehmigt. Genehmigt außerdem alle Patches mit einer Klassifizierung „Bugfix“ sieben Tage nach der Veröffentlichung.  | 
| AWS-CentOSDefaultPatchBaseline | CentOS Stream | Genehmigt alle Aktualisierungen sieben Tage nach ihrer Verfügbarkeit, einschließlich nicht sicherheitsrelevanter Aktualisierungen. | 
| AWS-DebianDefaultPatchBaseline | Debian Server | Genehmigt sofort alle sicherheitsrelevanten Patches für Betriebssysteme mit der Priorität „Required“, „Important“, „Standard“, „Optional“ oder „Extra“. Die Genehmigung erfolgt unverzüglich, weil in den Repositorys keine zuverlässigen Datumsangaben zur Veröffentlichung verfügbar sind. | 
| AWS-MacOSDefaultPatchBaseline | macOS | Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“. Genehmigt auch alle Pakete mit einem aktuellen Update. | 
| AWS-OracleLinuxDefaultPatchBaseline | Oracle Linux | Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Important“ oder „Moderate“. Genehmigt außerdem alle als „Bugfix“ eingestuften Patches 7 Tage nach Veröffentlichung. Patches werden sieben Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.¹ | 
|  `AWS-RedHatDefaultPatchBaseline`  |  Red Hat Enterprise Linux (RHEL)   |  Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Genehmigt außerdem alle Patches mit der Klassifizierung „Bugfix“. Patches werden sieben Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.¹  | 
|  `AWS-RockyLinuxDefaultPatchBaseline`  |  Rocky Linux  |  Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Genehmigt außerdem alle Patches mit der Klassifizierung „Bugfix“. Patches werden sieben Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.¹  | 
| AWS-SuseDefaultPatchBaseline | SUSE Linux Enterprise Server (SLES) | Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Patches werden sieben Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.¹ | 
|  `AWS-UbuntuDefaultPatchBaseline`  |  Ubuntu Server  |  Genehmigt sofort alle sicherheitsrelevanten Patches für Betriebssysteme mit der Priorität „Required“, „Important“, „Standard“, „Optional“ oder „Extra“. Die Genehmigung erfolgt unverzüglich, weil in den Repositorys keine zuverlässigen Datumsangaben zur Veröffentlichung verfügbar sind.  | 
| AWS-DefaultPatchBaseline |  Windows Server  |  Genehmigt alle Windows Server Betriebssystem-Patches, die als "" oder CriticalUpdates SecurityUpdates "eingestuft sind und die den MSRC-Schweregrad „Kritisch“ oder „Wichtig“ haben. Patches werden 7 Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.²  | 
| AWS-WindowsPredefinedPatchBaseline-OS |  Windows Server  |  Genehmigt alle Windows Server Betriebssystem-Patches, die als "oder" CriticalUpdates "eingestuft sind und die den MSRC-Schweregrad „Kritisch“ oder „Wichtig“ haben. SecurityUpdates Patches werden 7 Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.²  | 
| AWS-WindowsPredefinedPatchBaseline-OS-Applications | Windows Server | Genehmigt für das Windows Server Betriebssystem alle Patches, die als "oder CriticalUpdatesSecurityUpdates" eingestuft sind und die den MSRC-Schweregrad „Kritisch“ oder „Wichtig“ haben. Genehmigt für von Microsoft veröffentlichte Anwendungen alle Patches. Patches für Betriebssysteme und Anwendungen werden 7 Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.² | 

¹ Für Amazon Linux 2 wird die 7-Tage-Wartezeit, bevor Patches automatisch genehmigt werden, aus einem `Updated Date`-Wert in `updateinfo.xml` und nicht aus einem `Release Date`-Wert berechnet. Verschiedene Faktoren können den `Updated Date`-Wert beeinflussen. Andere Betriebssysteme behandeln Veröffentlichungs- und Aktualisierungsdaten unterschiedlich. Informationen dazu, wie Sie unerwartete Ergebnisse durch Verzögerungen bei der automatischen Genehmigung vermeiden können, finden Sie unter [So werden Veröffentlichungs- und Aktualisierungsdaten von Paketen berechnet](patch-manager-release-dates.md).

² Für Windows Server enthalten die Standard-Baselines eine Verzögerung von 7 Tagen für die automatische Genehmigung. Um einen Patch innerhalb von 7 Tagen nach der Veröffentlichung zu installieren, müssen Sie eine benutzerdefinierte Baseline erstellen.

## Benutzerdefinierte Baselines
<a name="patch-manager-baselines-custom"></a>

Mithilfe der folgenden Informationen können Sie benutzerdefinierte Patch-Baselines erstellen, um Ihre Patching-Ziele zu erreichen.

**Topics**
+ [Automatische Genehmigungen in benutzerdefinierten Baselines verwenden](#baselines-auto-approvals)
+ [Zusätzliche Informationen zum Erstellen von Patch-Baselines](#baseline-additional-info)

### Automatische Genehmigungen in benutzerdefinierten Baselines verwenden
<a name="baselines-auto-approvals"></a>

Wenn Sie eine eigene Patch-Baseline herstellen, können Sie die Patches wahlweise automatisch genehmigen, indem Sie die folgenden Kategorien verwenden.
+ **Betriebssystem**: Unterstützte Versionen von Windows Server, Amazon Linux, Ubuntu Server, usw.
+ **Produktname **(für Betriebssysteme): Beispielsweise RHEL 7.5, Amazon Linux 2023 2023.8.20250808, Windows Server 2012, Windows Server 2012 R2 usw.
+ **Produktname** (Windows Servernur für von Microsoft veröffentlichte Anwendungen): Zum Beispiel Word 2016, BizTalk Server usw.
+ **Klassifizierung**: Beispielsweise kritische Updates, Sicherheitsupdates usw.
+ **Schweregrad**: Beispielsweise kritisch, wichtig usw.

Für jede von Ihnen erstellte Genehmigungsregel können Sie eine Verzögerung für die automatische Genehmigung oder ein Stichdatum für die Patch-Genehmigung angeben. 

**Anmerkung**  
Da es nicht möglich ist, die Veröffentlichungsdaten von Updatepaketen für Ubuntu Server zuverlässig zu bestimmen, werden die Optionen für die automatische Genehmigung für dieses Betriebssystem nicht unterstützt.

Eine Verzögerung der automatischen Genehmigung ist die Anzahl an Tagen, die gewartet werde soll, nachdem die Patch veröffentlicht oder zuletzt aktualisiert wurde, bevor der Patch automatisch genehmigt wird. Wenn Sie beispielsweise eine Regel mit der `CriticalUpdates`-Klassifizierung erstellen und für sie für eine Verzögerung der automatischen Genehmigung von sieben Tagen konfigurieren, wird ein neuer kritischer Patch, der am 7. Juli veröffentlicht wird, am 14. Juli automatisch genehmigt.

Wenn ein Linux-Repository keine Informationen zum Veröffentlichungsdatum von Paketen bereitstellt, verwendet Patch Manager den Erstellungszeitpunkt des Pakets als Datum zur automatischen Genehmigung der Datumsangaben für Amazon Linux 2, Amazon Linux 2023 und Red Hat Enterprise Linux (RHEL). Wenn die Erstellungszeit des Pakets nicht bestimmt werden kann, verwendet Patch Manager als Standarddatum den 1. Januar 1970. Dies führt dazu, dass alle Angaben zum Datum der automatischen Genehmigung in Patch-Baselines von Patch Manager umgangen werden, die so konfiguriert sind, dass Patches für jedes Datum nach dem 1. Januar 1970 genehmigt werden.

Wenn Sie ein Stichdatum für die automatische Genehmigung angeben, wendet Patch Manager automatisch alle Patches an, die an oder vor diesem Datum veröffentlicht oder zuletzt aktualisiert wurden. Wenn Sie beispielsweise den 07. Juli 2023 als Stichtag angeben, werden keine Patches automatisch installiert, die an oder nach dem 08. Juli 2023 veröffentlicht oder zuletzt aktualisiert wurden.

Wenn Sie eine benutzerdefinierte Patch-Baseline erstellen, können Sie für Patches, die von dieser Patch-Baseline genehmigt wurden, einen Schweregrad für die Konformität angeben, beispielsweise `Critical` oder `High`. Wenn der Patch-Status eines genehmigten Patches als `Missing` gemeldet wird, dann ist der insgesamt gemeldete Konformitätsschweregrad der Patch-Baseline der von Ihnen angegebene Schweregrad.

### Zusätzliche Informationen zum Erstellen von Patch-Baselines
<a name="baseline-additional-info"></a>

Beachten Sie bei der Erstellung einer Patch-Baseline Folgendes:
+ Patch Manager stellt eine vordefinierte Patch-Baseline für jedes unterstützte Betriebssystem bereit. Diese vordefinierten Patch-Baselines werden als Standard-Patch-Baselines für alle Betriebssystemtypen verwendet, wenn Sie nicht eigene Patch-Baselines erstellen und diese als Standard für den jeweiligen Betriebssystemtyp festlegen. 
**Anmerkung**  
Für Windows Server werden drei vordefinierte Patch-Baselines bereitgestellt. Die Patch-Baselines `AWS-DefaultPatchBaseline` und `AWS-WindowsPredefinedPatchBaseline-OS` unterstützen nur Betriebssystemupdates auf dem Windows-Betriebssystem selbst. `AWS-DefaultPatchBaseline` wird als Standard-Patch-Baseline für von Windows Server verwalteten Knoten verwendet, es sei denn, Sie geben eine andere Patch-Baseline an. Die Konfigurationseinstellungen in diesen beiden Patch-Baselines sind identisch. Die neuere der beiden, `AWS-WindowsPredefinedPatchBaseline-OS`, wurde erstellt, um sie von der dritten vordefinierten Patch-Baseline für Windows Server zu unterscheiden. Diese Patch-Baseline, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, kann verwendet werden, um Patches sowohl auf das Windows Server-Betriebssystem als auch auf unterstützte Anwendungen, die von Microsoft veröffentlicht wurden, anzuwenden.
+ Standardmäßig entfernen Windows Server 2019 und Windows Server 2022 Updates, die durch spätere Updates ersetzt werden. Wenn Sie also den `ApproveUntilDate`-Parameter in einer Windows Server-Patch-Baseline verwenden, das im `ApproveUntilDate`-Parameter ausgewählte Datum jedoch vor dem Datum des neuesten Patches liegt, wird der neue Patch nicht installiert, wenn der Patching-Vorgang ausgeführt wird. Weitere Informationen zu Windows Server-Patching-Regeln, finden Sie in der Registerkarte Windows Server in [Wie Sicherheitspatches ausgewählt werden](patch-manager-selecting-patches.md).

  Das bedeutet, dass der verwaltete Knoten die Anforderungen des Systems-Manager-Betriebs erfüllt, auch wenn ein kritischer Patch aus dem Vormonat möglicherweise nicht installiert wurde. Das gleiche Szenario kann bei Verwendung des `ApproveAfterDays`-Parameters auftreten. Aufgrund des Verhaltens von Microsoft bei abgelösten Patches ist es möglich, eine Zahl (im Allgemeinen größer als 30 Tage) festzulegen, sodass Patches für Windows Server nie installiert werden, wenn der neueste verfügbare Patch von Microsoft veröffentlicht wird, bevor die Anzahl der Tage in `ApproveAfterDays` verstrichen ist. 
+ Nur für Windows Server kann ein verfügbarer Sicherheitsupdate-Patch, der nicht von der Patch-Baseline genehmigt wurde, den Konformitätswert `Compliant` oder `Non-Compliant` haben, wie in einer benutzerdefinierten Patch-Baseline definiert. 

  Wenn Sie eine Patch-Baseline erstellen oder aktualisieren, wählen Sie den Status, den Sie Sicherheitspatches zuweisen möchten, die zwar verfügbar, aber nicht genehmigt sind, weil sie die in der Patch-Baseline angegebenen Installationskriterien nicht erfüllen. Beispielsweise können Sicherheitspatches, die Sie möglicherweise installieren möchten, übersprungen werden, wenn Sie eine lange Wartezeit für die Installation nach der Veröffentlichung eines Patches angegeben haben. Wenn während der von Ihnen angegebenen Wartezeit ein Update für den Patch veröffentlicht wird, beginnt die Wartezeit für die Installation des Patches von vorne. Wenn die Wartezeit zu lang ist, können mehrere Versionen des Patches veröffentlicht, aber nie installiert werden.

  Wenn Sie die Konsole verwenden, um eine Patch-Baseline zu erstellen oder zu aktualisieren, geben Sie diese Option im Feld **Compliance-Status für verfügbare Sicherheitsupdates** an. Mit AWS CLI dem [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html)Befehl [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html)oder geben Sie diese Option im `available-security-updates-compliance-status` Parameter an. 
+ Patch ManagerVersucht bei lokalen Servern und virtuellen Maschinen (VMs), Ihre benutzerdefinierte Standard-Patch-Baseline zu verwenden. Wenn keine benutzerdefinierte Standard-Patch-Baseline vorhanden ist, verwendet das System die vordefinierte Patch-Baseline für das entsprechende Betriebssystem.
+ Wenn ein Patch sowohl als genehmigt als auch als abgelehnt aufgelistet ist, wird der Patch abgelehnt.
+ Für einen verwalteten Knoten kann nur eine einzige Patch-Baseline definiert werden.
+ Die Formate der Paketnamen, die Sie zu den Listen der genehmigten und abgelehnten Patches für eine Patch-Baseline hinzufügen können, hängen von der Art des Betriebssystems ab, das gepatcht wird.

  Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
+ Wenn Sie eine [Patch-Richtlinienkonfiguration](patch-manager-policies.md) in Quick Setup verwenden, werden Aktualisierungen, die Sie an benutzerdefinierten Patch-Baselines vornehmen, einmal pro Stunde mit Quick Setup synchronisiert. 

  Wenn eine benutzerdefinierte Patch-Baseline gelöscht wird, auf die in einer Patch-Richtlinie verwiesen wurde, wird auf der Seite mit den Quick Setup-**Konfigurationsdetails** ein Banner für Ihre Patch-Richtlinie angezeigt. Das Banner informiert Sie darüber, dass die Patch-Richtlinie auf eine nicht mehr vorhandene Patch-Baseline verweist und nachfolgende Patching-Vorgänge fehlschlagen werden. Kehren Sie in diesem Fall zur Seite Quick Setup-**Konfigurationen** zurück, wählen Sie die Patch Manager-Konfiguration aus und wählen Sie **Aktionen**, **Konfiguration bearbeiten**. Der Name der gelöschten Patch-Baseline wird hervorgehoben, und Sie müssen eine neue Patch-Baseline für das betroffene Betriebssystem auswählen.
+ Wenn Sie eine Genehmigungsregel mit mehreren `Classification`- und `Severity`-Werten erstellen, werden Patches auf der Grundlage ihrer verfügbaren Attribute genehmigt. Pakete mit beiden `Classification`- und `Severity`-Attributen und entsprechen den ausgewählten Basiswerten für beide Felder. Pakete, die nur `Classification`-Attribute enthalten, werden nur mit den ausgewählten `Classification`-Basiswerten verglichen. Schweregradanforderungen in derselben Regel werden für Pakete ohne `Severity`-Attribute ignoriert. 

Informationen zum Erstellen einer Patch-Baseline finden Sie unter [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md) und [Tutorial: Patchen Sie eine Serverumgebung mit dem AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md).

# Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen
<a name="patch-manager-approved-rejected-package-name-formats"></a>

Die Formate der Paketnamen, die Sie zu den Listen der genehmigten und abgelehnten Patches hinzufügen können, hängen von der Art des Betriebssystems ab, das gepatcht wird.

## Paketnamen-Formate für Linux-Betriebssysteme
<a name="patch-manager-approved-rejected-package-name-formats-linux"></a>

Die Formate, die Sie für genehmigte und abgelehnte Patches in der Patch-Baseline festlegen können, variieren je nach Linux-Typ. Genauer gesagt hängen die unterstützten Formate von dem Paket-Manager ab, der vom Linux-Betriebssystemtyp verwendet wird.

**Topics**
+ [Amazon Linux 2, Amazon Linux 2023, Oracle Linux und Red Hat Enterprise Linux (RHEL)](#patch-manager-approved-rejected-package-name-formats-standard)
+ [Debian Server und Ubuntu Server](#patch-manager-approved-rejected-package-name-formats-ubuntu)
+ [SUSE Linux Enterprise Server (SLES)](#patch-manager-approved-rejected-package-name-formats-sles)

### Amazon Linux 2, Amazon Linux 2023, Oracle Linux und Red Hat Enterprise Linux (RHEL)
<a name="patch-manager-approved-rejected-package-name-formats-standard"></a>

**Paket-Manager**: YUM, außer unter Amazon Linux 2023 und RHEL 8, die DNF als Paket-Manager verwenden.

**Genehmigte Patches**: Für genehmigte Patches können Sie Folgendes festlegen:
+ Bugzilla IDs, im Format `1234567` (Das System verarbeitet Zeichenketten, die nur Zahlen enthalten, als Bugzilla.) IDs
+ CVE IDs, im Format `CVE-2018-1234567`
+ Beratung IDs, in Formaten wie und `RHSA-2017:0864` `ALAS-2018-123`
+ Paketnamen, die unter Verwendung einer oder mehrerer der verfügbaren Komponenten für die Paketbenennung erstellt wurden. Zur Veranschaulichung lauten die Komponenten für das genannte `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`-Paket wie folgt: 
  + `name`: `dbus`
  + `architecture`: `x86_64`
  + `epoch`: `1`
  + `version`: `1.12.28`
  + `release`: `1.amzn2023.0.1`

  Paketnamen mit den folgenden Konstruktionen werden unterstützt:
  + `name`
  + `name.arch`
  + `name-version`
  + `name-version-release`
  + `name-version-release.arch`
  + `version`
  + `version-release`
  + `epoch:version-release`
  + `name-epoch:version-release`
  + `name-epoch:version-release.arch`
  + `epoch:name-version-release.arch`
  + `name.arch:epoch:version-release`

  Hier einige Beispiele:
  + `dbus.x86_64`
  + `dbus-1.12.28`
  + `dbus-1.12.28-1.amzn2023.0.1`
  + `dbus-1:1.12.28-1.amzn2023.0.1.x86_64`
+ Wir unterstützen auch Paketnamenkomponenten mit einem einzigen Platzhalter in den oben genannten Formaten, z. B. in den folgenden:
  + `dbus*` 
  + `dbus-1.12.2*`
  + `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`

**Abgelehnte Patches**: Für abgelehnte Patches können Sie Folgendes festlegen:
+ Paketnamen, die unter Verwendung einer oder mehrerer der verfügbaren Komponenten für die Paketbenennung erstellt wurden. Zur Veranschaulichung lauten die Komponenten für das genannte `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`-Paket wie folgt: 
  + `name`: `dbus`
  + `architecture`; `x86_64`
  + `epoch`: `1`
  + `version`: `1.12.28`
  + `release`: `1.amzn2023.0.1`

  Paketnamen mit den folgenden Konstruktionen werden unterstützt:
  + `name`
  + `name.arch`
  + `name-version`
  + `name-version-release`
  + `name-version-release.arch`
  + `version`
  + `version-release`
  + `epoch:version-release`
  + `name-epoch:version-release`
  + `name-epoch:version-release.arch`
  + `epoch:name-version-release.arch`
  + `name.arch:epoch:version-release`

  Hier einige Beispiele:
  + `dbus.x86_64`
  + `dbus-1.12.28`
  + `dbus-1.12.28-1.amzn2023.0.1`
  + `dbus-1:1.12.28-1.amzn2023.0.1.x86_64` 
+ Wir unterstützen auch Paketnamenkomponenten mit einem einzigen Platzhalter in den oben genannten Formaten, z. B. in den folgenden:
  + `dbus*` 
  + `dbus-1.12.2*`
  + `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`

### Debian Server und Ubuntu Server
<a name="patch-manager-approved-rejected-package-name-formats-ubuntu"></a>

**Paket-Manager**: APT

**Genehmigte Patches** und **abgelehnte Patches**: Legen Sie für genehmigte sowie abgelehnte Patches Folgendes fest:
+ Paketnamen im Format `ExamplePkg33`
**Anmerkung**  
Verwenden Sie für Debian Server- und Ubuntu Server-Listen keine Elemente wie Architektur oder Versionen. Beispiel: Sie legen den Paketnamen `ExamplePkg33` fest, um alles Folgende in einer Patch-Liste einzubeziehen:  
`ExamplePkg33.x86.1`
`ExamplePkg33.x86.2`
`ExamplePkg33.x64.1`
`ExamplePkg33.3.2.5-364.noarch`

### SUSE Linux Enterprise Server (SLES)
<a name="patch-manager-approved-rejected-package-name-formats-sles"></a>

**Paket-Manager**: Zypper

**Genehmigte Patches** und **abgelehnte Patches**: Sie können für genehmigte sowie abgelehnte Patch-Listen Folgendes festlegen:
+ Vollständige Paketnamen in Formaten wie z. B.:
  + `SUSE-SLE-Example-Package-15-2023-123`
  + `example-pkg-2023.15.4-46.17.1.x86_64.rpm`
+ Paketnamen mit einem einzigen Platzhalter wie z. B.:
  + `SUSE-SLE-Example-Package-15-2023-*`
  + `example-pkg-2023.15.4-46.17.1.*.rpm`

## Paketnamen-Formate für macOS
<a name="patch-manager-approved-rejected-package-name-formats-macos"></a>

**Unterstützte Paketmanager**: Softwareupdate, Installationsprogramm, Brew, Brew Cask

**Genehmigte Patches** und **abgelehnte Patches**: Geben Sie für genehmigte sowie abgelehnte Patch-Listen vollständige Paketnamen in folgenden formaten an:
+ `XProtectPlistConfigData`
+ `MRTConfigData`

Platzhalter werden in Listen genehmigter und abgelehnter Patches für macOS nicht unterstützt.

## Paketnamen-Formate für Windows-Betriebssysteme
<a name="patch-manager-approved-rejected-package-name-formats-windows"></a>

Geben Sie für Windows-Betriebssysteme Patches mithilfe von Microsoft Knowledge Base IDs und Microsoft Security Bulletin an IDs. Beispiel:

```
KB2032276,KB2124261,MS10-048
```

# Patch-Gruppen
<a name="patch-manager-patch-groups"></a>

**Anmerkung**  
Patch-Gruppen werden nicht in Patch-Vorgängen verwendet, die auf *Patch-Richtlinien* basieren. Weitere Informationen zur Arbeit mit Patch-Richtlinien finden Sie unter [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md).  
Die Patchgruppenfunktion wird in der Konsole für Konto-Regionen-Paare nicht unterstützt, die vor der Veröffentlichung der Patch-Richtlinienunterstützung am 22. Dezember 2022 noch keine Patchgruppen verwendet haben. Die Patchgruppenfunktion ist weiterhin für Konto-Regionen-Paare verfügbar, die vor diesem Datum mit der Verwendung von Patchgruppen begonnen haben.

Mithilfe einer *Patch-Gruppe* können Sie verwaltete Knoten einer bestimmten Patch-Baseline in Patch Manager, ein Tool in AWS Systems Manager, zuordnen. Mit Patch-Gruppen können Sie sicherstellen, dass Sie geeignete Patches basierend auf den zugeordneten Patch-Baseline-Regeln für die richtigen Sätze von Knoten bereitstellen. Patch-Gruppen können außerdem dazu beitragen, die Bereitstellung von Patches zu vermeiden, bevor diese angemessen getestet sind. So können Sie Patch-Gruppen beispielsweise für unterschiedliche Umgebungen (Entwicklung, Test und Produktion) erstellen und jede Patch-Gruppe für eine geeignete Patch-Baseline registrieren. 

Wenn Sie `AWS-RunPatchBaseline` oder andere SSM-Befehlsdokumente zum Patching ausführen, können Sie verwaltete Knoten über deren ID oder Tags anvisieren. Basierend auf dem Patch-Gruppenwert, den Sie dem verwalteten Knoten hinzugefügt haben, werten dann SSM Agent und Patch Manager aus, welche Patch-Baseline verwendet werden soll.

## Verwendung von Tags zur Definition von Patchgruppen
<a name="patch-group-tags"></a>

Sie können eine Patchgruppe erstellen, indem Sie Tags verwenden, die auf Ihre Instances der Amazon Elastic Compute Cloud (Amazon EC2) und Nicht-EC2-Knoten in Ihrer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) angewendet werden. Beachten Sie die folgenden Details zum Verwenden von Tags für Patchgruppen:
+ 

  Eine Patchgruppe muss entweder mithilfe des Tag-Schlüssels `Patch Group` oder `PatchGroup` definiert werden, die auf Ihre verwalteten Knoten angewendet werden. Bei der Registrierung einer Patchgruppe für eine Patch-Baseline werden alle identischen *Werte*, die für diese beiden Schlüssel angegeben wurden, als Teil derselben Gruppe interpretiert. Nehmen wir zum Beispiel an, Sie haben fünf Knoten mit dem ersten der folgenden Schlüssel-Wert-Paare und fünf mit dem zweiten getaggt:
  + `key=PatchGroup,value=DEV` 
  + `key=Patch Group,value=DEV`

  Der Patch Manager-Befehl zum Erstellen einer Baseline fasst diese 10 verwalteten Knoten auf der Grundlage des Werts `DEV` zu einer einzigen Gruppe zusammen. Das AWS CLI-Äquivalent für den Befehl zum Erstellen einer Patch-Baseline für Patch-Gruppen lautet wie folgt:

  ```
  aws ssm register-patch-baseline-for-patch-group \
      --baseline-id pb-0c10e65780EXAMPLE \
      --patch-group DEV
  ```

  Die Kombination von Werten aus verschiedenen Schlüsseln zu einem einzigen Ziel ist einzigartig für diesen Patch Manager-Befehl zum Erstellen einer neuen Patchgruppe und wird von anderen API-Aktionen nicht unterstützt. Wenn Sie beispielsweise [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)-Aktionen mit `PatchGroup`- und `Patch Group`-Schlüsseln und mit denselben Werten ausführen, zielen Sie auf zwei völlig unterschiedliche Gruppen von Knoten ab:

  ```
  aws ssm send-command \
      --document-name AWS-RunPatchBaseline \
      --targets "Key=tag:PatchGroup,Values=DEV"
  ```

  ```
  aws ssm send-command \
      --document-name AWS-RunPatchBaseline \
      --targets "Key=tag:Patch Group,Values=DEV"
  ```
+ Es gibt Beschränkungen für das Tag-basierte Targeting. Jedes Ziele-Array für `SendCommand` kann maximal fünf Schlüssel-Wert-Paare haben.
+ Es wird empfohlen, nur eine dieser Konventionen für Tag-Schlüssel zu wählen, entweder `PatchGroup` (ohne Leerzeichen) oder `Patch Group` (mit Leerzeichen). Wenn Sie [Tags in EC2-Instance-Metadaten zugelassen haben](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), müssen Sie jedoch `PatchGroup` verwenden.
+ Bei dem Schlüssel wird die Groß-/Kleinschreibung berücksichtigt. Sie können einen beliebigen *Wert* angeben, um die Ressourcen in dieser Gruppe zu identifizieren und darauf auszurichten, z. B. „Webserver“ oder „US-EAST-PROD“, aber der Schlüssel muss `Patch Group` oder `PatchGroup` sein.

Wenn Sie eine Patch-Gruppe erstellt und verwaltete Knoten mit Tags markiert haben, können Sie die Patch-Gruppe für eine Patch-Baseline anmelden. Indem Sie die Patch-Gruppe für eine Patch-Baseline registrieren, stellen Sie sicher, dass die Knoten innerhalb der Patch-Gruppe die in der zugehörigen Patch-Baseline definierten Regeln befolgen. 

Weitere Informationen zum Erstellen von Patch-Gruppen und Zuordnen von Patch-Gruppen zu einer Patch-Baseline finden Sie unter [Erstellen und Verwalten von Patch-Gruppen](patch-manager-tag-a-patch-group.md) und [Einer Patch-Baseline eine Patch-Gruppe hinzufügen](patch-manager-tag-a-patch-group.md#sysman-patch-group-patchbaseline).

Ein Beispiel für das Erstellen einer Patch-Baseline und von Patch-Gruppen über die AWS Command Line Interface (AWS CLI) finden Sie unter [Tutorial: Patchen Sie eine Serverumgebung mit dem AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md). Weitere Informationen über Amazon-EC2-Tags finden Sie unter [Ihre Amazon-EC2-Ressourcen markieren](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) im *Amazon-EC2-Benutzerhandbuch*.

## Funktionsweise
<a name="how-it-works-patch-groups"></a>

Wenn das System eine Patch-Baseline auf einen verwalteten Knoten anwendet, überprüft SSM Agent, ob für den Knoten ein Patch-Gruppenwert definiert wurde. Wenn der Knoten einer Patch-Gruppe zugewiesen wurde, ermittelt Patch Manager anschließend, welche Patch-Baseline für diese Gruppe registriert wurde. Wenn für die Gruppe eine Patch-Baseline gefunden wird, weist Patch Manager SSM Agent an, die zugehörige Patch-Baseline zu verwenden. Wenn ein Knoten nicht für eine Patch-Gruppe konfiguriert wurde, weist Patch Manager SSM Agent automatisch an, die aktuell konfigurierte Standard-Patch-Baseline zu verwenden.

**Wichtig**  
Ein verwalteter Knoten kann sich nur in einer Patch-Gruppe befinden.  
Eine Patch-Gruppe kann nur für eine Patch-Baseline für jeden Betriebssystemtyp registriert werden.  
Sie können das `Patch Group`-Tag (mit einem Leerzeichen) nicht auf eine Amazon-EC2-Instance anwenden, wenn die Option **Allow tags in instance metadata** (Tags in Instance-Metadaten zulassen) auf der Instance aktiviert ist. Durch das Zulassen von Tags in Instance-Metadaten wird verhindert, dass Tag-Schlüsselnamen Leerzeichen enthalten. Wenn Sie [Tags in EC2-Instance-Metadaten zugelassen haben](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), müssen Sie den Tag-Schlüssel `PatchGroup` (ohne Leerzeichen) verwenden.

**Abbildung 1: Allgemeines Beispiel für den Prozessablauf beim Patch-Vorgang**

In der folgenden Abbildung sehen Sie ein allgemeines Beispiel der Prozesse, die Systems Manager beim Senden einer Run Command-Aufgabe an Ihre Serverflotte sendet, um mit Patch Manager Patches einzuspielen. Diese Prozesse bestimmen, welche Patch-Baselines für Patch-Vorgänge verwendet werden sollen. (Ein ähnlicher Prozess wird verwendet, wenn ein Wartungsfenster konfiguriert wurde, um einen Befehl zum Patchen mithilfe von Patch Manager zu senden.)

Der vollständige Vorgang wird unter der Abbildung erklärt.

![\[Patch Manager-Workflow zum Bestimmen, welche Patch-Baselines beim Ausführen von Patchvorgängen verwendet werden sollen.\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/patch-groups-how-it-works.png)


In diesem Beispiel haben wir drei Gruppen von EC2-Instances für Windows Server mit den folgenden Tags:


****  

| EC2-Instances-Gruppe | Tags | 
| --- | --- | 
|  Gruppe 1  |  `key=OS,value=Windows` `key=PatchGroup,value=DEV`  | 
|  Gruppe 2  |  `key=OS,value=Windows`  | 
|  Gruppe 3  |  `key=OS,value=Windows` `key=PatchGroup,value=QA`  | 

In diesem Beispiel haben wir außerdem diese beiden Windows Server-Patch-Baselines:


****  

| Patch-Baseline-ID | Standard | Zugehörige Patch-Gruppe | 
| --- | --- | --- | 
|  `pb-0123456789abcdef0`  |  Ja  |  `Default`  | 
|  `pb-9876543210abcdef0`  |  Nein  |  `DEV`  | 

Der allgemeine Ablauf zum Scannen bzw. Installieren von Patches mit Run Command, einem Tool in AWS Systems Manager, und Patch Manager sieht wie folgt aus:

1. **Einen Patchbefehl senden**: Verwenden Sie die Systems Manager-Konsole, das SDK, die AWS Command Line Interface (AWS CLI) oder AWS Tools for Windows PowerShell zum Senden einer Run Command-Aufgabe mithilfe des Dokuments `AWS-RunPatchBaseline`. Die Abbildung zeigt eine Run Command-Aufgabe zum Patchen verwalteter Instances mit dem Tag `key=OS,value=Windows` als Ziel.

1. **Patch-Baseline bestimmen**: SSM Agent überprüft die auf die EC2-Instance angewendeten Patch-Gruppen-Tags und sendet eine Anfrage an Patch Manager für die entsprechende Patch-Baseline.
   + **Passender Patch-Gruppenwert einer Patch-Baseline zugeordnet:**

     1. SSM Agent, das auf EC2-Instance in Gruppe 1 installiert ist, empfängt den in Schritt 1 gesendeten Befehl, mit dem Patchvorgang zu beginnen. SSM Agent überprüft, ob die EC2-Instances über den Patch-Gruppen-Tag-Wert `DEV` verfügen und sendet eine Anfrage an Patch Manager für die zugehörige Patch-Baseline.

     1. Patch Manager überprüft, ob der Patch-Baseline `pb-9876543210abcdef0` die Patch-Gruppe `DEV` zugeordnet ist, und sendet eine Benachrichtigung an SSM Agent.

     1. SSM Agent ruft basierend auf den in Patch Manager konfigurierten Genehmigungsregeln und Ausnahmen einen Snapshot der Patch-Baseline von `pb-9876543210abcdef0` ab und fährt mit dem nächsten Schritt fort.
   + **Instance verfügt nicht über ein Patch-Gruppen-Tag:**

     1. SSM Agent, das auf EC2-Instance in Gruppe 2 installiert ist, empfängt den in Schritt 1 gesendeten Befehl, mit dem Patchvorgang zu beginnen. SSM Agent überprüft, ob die EC2-Instances nicht über das Patch-Gruppen-Tag `Patch Group` oder `PatchGroup` verfügen. SSM Agent sendet daraufhin eine Anfrage an Patch Manager für die Standard-Windows-Patch-Baseline.

     1. Patch Manager überprüft, ob die Standard-Patch-Baseline für Windows Server `pb-0123456789abcdef0` ist, und benachrichtigt SSM Agent.

     1. SSM Agent ruft basierend auf den in der Standard-Patch-Baseline Patch Manager konfigurierten Genehmigungsregeln und Ausnahmen einen Snapshot der Patch-Baseline von `pb-0123456789abcdef0` ab und fährt mit dem nächsten Schritt fort.
   + **Es gibt keinen passenden, einer Patch-Baseline zugeordneten Patch-Gruppenwert:**

     1. SSM Agent, das auf EC2-Instance in Gruppe 3 installiert ist, empfängt den in Schritt 1 gesendeten Befehl, mit dem Patchvorgang zu beginnen. SSM Agent überprüft, ob die EC2-Instances über den Patch-Gruppen-Tag-Wert `QA` verfügen und sendet eine Anfrage an Patch Manager für die zugehörige Patch-Baseline.

     1. Patch Manager findet keine Patch-Baseline mit der zugeordneten Patch-Gruppe `QA`.

     1. Patch Manager benachrichtigt SSM Agent, die Standard-Patch-Baseline für Windows, `pb-0123456789abcdef0`, zu verwenden.

     1. SSM Agent ruft basierend auf den in der Standard-Patch-Baseline Patch Manager konfigurierten Genehmigungsregeln und Ausnahmen einen Snapshot der Patch-Baseline von `pb-0123456789abcdef0` ab und fährt mit dem nächsten Schritt fort.

1. **Auf Patches scannen oder Patches installieren**: Nachdem die anzuwendende Patch-Baseline bestimmt wurde, beginnt SSM Agent basierend auf dem in Schritt 1 festgelegten Vorgangswert entweder damit, nach Patches zu scannen oder diese zu installieren. Nach welchen Patches gescannt bzw. welche Patches installiert werden, wird durch die Genehmigungsregeln und Patch-Ausnahmen bestimmt, die im von Patch Manager bereitgestellten Patch-Baseline-Snapshot definiert sind.

**Weitere Informationen**  
+ [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md)

# Informationen zum Patchen von Anwendungen, die von Microsoft unter Windows Server veröffentlicht wurden
<a name="patch-manager-patching-windows-applications"></a>

Verwenden Sie die Informationen in diesem Thema, um die Vorbereitung auf Patchanwendungen auf Windows Server mit Patch Manager, einem Tool in AWS Systems Manager, zu erleichtern.

**Patching von Microsoft-Anwendungen**  
Patching-Support für Anwendungen auf von Windows Server verwalteten Knoten ist auf Anwendungen beschränkt, die von Microsoft veröffentlicht werden.

**Anmerkung**  
In einigen Fällen veröffentlicht Microsoft Patches für Anwendungen, die kein aktualisiertes Datum und keine aktualisierte Uhrzeit angeben. In diesen Fällen wird ein aktualisiertes Datum und eine Uhrzeit von `01/01/1970` standardmäßig angegeben.

**Patch-Baselines, um von Microsoft veröffentlichte Anwendungen zu patchen**  
Für Windows Server werden drei vordefinierte Patch-Baselines bereitgestellt. Die Patch-Baselines `AWS-DefaultPatchBaseline` und `AWS-WindowsPredefinedPatchBaseline-OS` unterstützen nur Betriebssystemupdates auf dem Windows-Betriebssystem selbst. `AWS-DefaultPatchBaseline` wird als Standard-Patch-Baseline für von Windows Server verwalteten Knoten verwendet, es sei denn, Sie geben eine andere Patch-Baseline an. Die Konfigurationseinstellungen in diesen beiden Patch-Baselines sind identisch. Die neuere der beiden, `AWS-WindowsPredefinedPatchBaseline-OS`, wurde erstellt, um sie von der dritten vordefinierten Patch-Baseline für Windows Server zu unterscheiden. Diese Patch-Baseline, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, kann verwendet werden, um Patches sowohl auf das Windows Server-Betriebssystem als auch auf unterstützte Anwendungen, die von Microsoft veröffentlicht wurden, anzuwenden.

Sie können zum Aktualisieren von Anwendungen, die von Microsoft veröffentlicht wurden, auf Windows Server-Computern auch benutzerdefinierte Patch-Baselines erstellen.

**Support für Patch-Anwendungen, die von Microsoft auf On-Premises-Servern, Edge-Geräten, VMs und anderen Nicht-EC2-Knoten veröffentlicht wurden**  
Aktivieren Sie das Advanced-Instances-Kontingent, um Anwendungen, die von Microsoft auf virtuellen Maschinen (VMs) und anderen nicht EC2-verwalteten Knoten veröffentlicht wurden, zu patchen. Die Nutzung des Advanced-Instances-Kontingents ist kostenpflichtig. **Für Patch-Anwendungen, die von Microsoft auf Amazon Elastic Compute Cloud (Amazon EC2)-Instances veröffentlicht wurden, fallen jedoch keine zusätzlichen Gebühren an.** Weitere Informationen finden Sie unter [Konfigurieren von Instance-Kontingenten](fleet-manager-configure-instance-tiers.md).

**Windows-Update-Option für „andere Microsoft-Produkte“**  
Damit Patch Manager von Microsoft auf Ihren von Windows Server verwalteten Knoten veröffentlichte Anwendungen patchen kann, muss die Windows-Update-Option **Ich möchte Updates für andere Microsoft-Produkte erhalten, wenn ich Windows aktualisiere** auf dem verwalteten Knoten aktiviert sein. 

Informationen zum Zulassen dieser Option für einen einzelnen verwalteten Knoten finden Sie unter [Aktualisieren von Office mit Microsoft Update](https://support.microsoft.com/en-us/office/update-office-with-microsoft-update-f59d3f9d-bd5d-4d3b-a08e-1dd659cf5282) auf der Microsoft-Support-Website.

Bei einer Flotte von verwalteten Knoten auf Windows Server 2016 und höher können Sie die Einstellung mithilfe eines Group Policy Object (GPO, Gruppenrichtlinienobjekt) aktivieren. Navigieren Sie im Gruppenrichtlinien-Verwaltungseditor zu **Computer-Konfiguration**, **Administrative Vorlagen**, **Windows-Komponenten**, **Windows-Updates** und wählen Sie **Installieren von Updates für andere Microsoft-Produkte** aus. Wir empfehlen außerdem, das GPO mit zusätzlichen Parametern zu konfigurieren, die ungeplante automatische Updates und Neustarts außerhalb von Patch Manager verhindern. Weitere Informationen finden Sie unter [Konfigurieren automatischer Updates in einer Umgebung ohne Active Directory](https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127499) auf der Website für technische Dokumentation von Microsoft.

Bei einer Flotte von verwalteten Knoten, die auf Windows Server 2012 oder 2012 R2 ausgeführt werden, können Sie die Option mithilfe eines Skripts aktivieren, wie unter [Aktivieren und Deaktivieren von Microsoft Update in Windows 7 über Skript](https://docs.microsoft.com/en-us/archive/blogs/technet/danbuche/enabling-and-disabling-microsoft-update-in-windows-7-via-script) auf der Microsoft-Docs-Blog-Website beschrieben. Sie können z. B. Folgendes tun:

1. Speichern Sie das Skript aus dem Blogbeitrag in einer Datei.

1. Laden Sie die Datei in einen Amazon Simple Storage Service (Amazon S3)-Bucket oder an einem anderen zugänglichen Speicherort hoch.

1. Verwenden SieRun Command, ein Tool in AWS Systems Manager, um das Skript mithilfe des Systems Manager Manager-Dokuments (SSM-Dokument) `AWS-RunPowerShellScript` mit einem Befehl ähnlich dem folgenden auf Ihren verwalteten Knoten auszuführen.

   ```
   Invoke-WebRequest `
       -Uri "https://s3.aws-api-domain/amzn-s3-demo-bucket/script.vbs" `
       -Outfile "C:\script.vbs" cscript c:\script.vbs
   ```

**Mindestparameteranforderungen**  
Um von Microsoft veröffentlichte Anwendungen in Ihre benutzerdefinierte Patch-Baseline aufzunehmen, müssen Sie mindestens das Produkt angeben, das Sie patchen möchten. Der folgende Befehl AWS Command Line Interface (AWS CLI) veranschaulicht die Mindestanforderungen für das Patchen eines Produkts, z. B. Microsoft Office 2016.

------
#### [ Linux & macOS ]

```
aws ssm create-patch-baseline \
    --name "My-Windows-App-Baseline" \
    --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```

------
#### [ Windows Server ]

```
aws ssm create-patch-baseline ^
    --name "My-Windows-App-Baseline" ^
    --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```

------

Wenn Sie die Produktfamilie der Microsoft-Anwendung angeben, müssen alle Produkte der ausgewählten Produktfamilie unterstützt werden. Um beispielsweise das Produkt „Active Directory Rights Management Services Client 2.0“ zu patchen, müssen Sie dessen Produktfamilie als „Active Directory“ und nicht beispielsweise als „Office“ oder „SQL Server“ angeben. Der folgende AWS CLI Befehl demonstriert eine übereinstimmende Kombination von Produktfamilie und Produkt.

------
#### [ Linux & macOS ]

```
aws ssm create-patch-baseline \
    --name "My-Windows-App-Baseline" \
    --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```

------
#### [ Windows Server ]

```
aws ssm create-patch-baseline ^
    --name "My-Windows-App-Baseline" ^
    --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```

------

**Anmerkung**  
Wenn Sie eine Fehlermeldung über eine nicht übereinstimmende Produkt- und Familienkopplung erhalten, finden Sie unter [Problem: Nicht übereinstimmende Produktpaare family/product](patch-manager-troubleshooting.md#patch-manager-troubleshooting-product-family-mismatch) Tipps zur Lösung des Problems.

# Verwenden von Kernel Live Patching auf von Amazon Linux 2 verwalteten Knoten
<a name="patch-manager-kernel-live-patching"></a>

Kernel Live Patching für Amazon Linux 2 ermöglicht es Ihnen, Patches für Sicherheitsschwachstellen und kritische Fehler auf einen laufenden Linux-Kernel anzuwenden, ohne Neustarts oder Unterbrechungen der laufenden Anwendungen. Sie profitieren damit von einer verbesserten Service- und Anwendungsverfügbarkeit, gleichzeitig bleibt Ihre Infrastruktur sicher und auf dem neuesten Stand. Kernel Live Patching wird auf Amazon-EC2-Instances und AWS IoT Greengrass -Core-Geräten unterstützt sowie auf [virtuellen On-Premises-Maschinen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-2-virtual-machine.html), die auf Amazon Linux 2 ausgeführt werden.

Allgemeine Informationen zu Kernel Live Patching finden Sie unter [Kernel Live Patchingon AL2](https://docs.aws.amazon.com/linux/al2/ug/al2-live-patching.html) im *Amazon Linux 2-Benutzerhandbuch*.

Nachdem Sie Kernel Live Patching auf einem von Amazon Linux 2 verwalteten Knoten aktiviert haben, können Sie Patch Manager, ein Tool in AWS Systems Manager, verwenden, um Kernel-Live-Patches auf den verwalteten Knoten anzuwenden. Die Verwendung des Patch Manager ist eine Alternative zur Verwendung vorhandener Yum-Workflows auf dem Knoten, um die Updates anzuwenden.

**Bevor Sie beginnen**  
Um mithilfe des Patch Manager Kernel-Live-Patches auf Ihre von Amazon Linux 2 verwalteten Knoten anzuwenden, stellen Sie sicher, dass Ihre Knoten auf der richtigen Architektur und Kernel-Version basieren. Weitere Informationen finden Sie unter [Unterstützte Konfigurationen und Voraussetzungen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq) im *Amazon-EC2-Benutzerhandbuch*.

**Topics**
+ [Kernel Live Patching mit Patch Manager verwenden](#about-klp)
+ [So funktioniert Patch Manager mit Kernel Live Patching](#how-klp-works)
+ [Aktivieren von Kernel Live Patching mit Run Command](enable-klp.md)
+ [Anwenden von Kernel-Live-Patches unter Verwendung von Run Command](install-klp.md)
+ [Deaktivieren von Kernel Live Patching mit Run Command](disable-klp.md)

## Kernel Live Patching mit Patch Manager verwenden
<a name="about-klp"></a>

Aktualisieren der Kernel-Version  
Sie müssen einen verwalteten Knoten nicht neu starten, nachdem Sie ein Kernel-Live-Patch-Update angewendet haben. AWS Stellt jedoch Kernel-Live-Patches für eine Amazon Linux 2-Kernelversion für bis zu drei Monate nach ihrer Veröffentlichung bereit. Nach Ablauf der dreimonatigen Frist müssen Sie auf eine spätere Kernel-Version aktualisieren, um weiterhin Kernel-Live-Patches zu erhalten. Wir empfehlen Ihnen, mithilfe eines Wartungsfensters mindestens einmal alle drei Monate einen Neustart Ihres Knoten zu planen, um das Update der Kernel-Version zu veranlassen.

Deinstallieren von Kernel-Live-Patches  
Kernel-Live-Patches können nicht mit dem Patch Manager deinstalliert werden. Stattdessen können Sie Kernel Live Patching deaktivieren, wodurch die RPM-Pakete für die angewendeten Kernel-Live-Patches entfernt werden. Weitere Informationen finden Sie unter [Deaktivieren von Kernel Live Patching mit Run Command](disable-klp.md).

Kernel-Compliance  
In einigen Fällen kann der Kernel durch die Installation aller CVE-Fixes von Live-Patches für die aktuelle Kernel-Version die Compliance-Ebene erreichen, die auch eine neuere Kernel-Version hätte. Wenn dies geschieht, wird die neuere Version als `Installed` und der verwaltete Knoten als `Compliant` gemeldet. Für die neuere Kernel-Version wird jedoch keine Installationszeit gemeldet.

Ein Kernel-Live-Patch, mehrere CVEs  
Wenn ein Kernel-Live-Patch mehrere CVEs adressiert und diese unterschiedliche Klassifizierungs- und Schweregradwerte CVEs haben, CVEs wird für den Patch nur die höchste Klassifizierung und der höchste Schweregrad gemeldet. 

Im weiteren Teil dieses Abschnitts wird erläutert, wie Patch Manager zum Anwenden von Kernel-Live-Patches auf verwaltete Knoten verwendet wird, die diese Anforderungen erfüllen.

## So funktioniert Patch Manager mit Kernel Live Patching
<a name="how-klp-works"></a>

AWS veröffentlicht zwei Arten von Kernel-Live-Patches für Amazon Linux 2: Sicherheitsupdates und Bugfixes. Um diese Patch-Typen anzuwenden, verwenden Sie ein Patch-Baseline-Dokument, das nur auf die in der folgenden Tabelle aufgeführten Klassifizierungen und Schweregrade ausgerichtet ist.


| Klassifizierung | Schweregrad | 
| --- | --- | 
| Security | Critical, Important | 
| Bugfix | All | 

Sie können eine benutzerdefinierte Patch-Baseline erstellen, die nur auf diese Patches ausgerichtet ist, oder die vordefinierte Patch-Baseline `AWS-AmazonLinux2DefaultPatchBaseline` verwenden. Mit anderen Worten, Sie können `AWS-AmazonLinux2DefaultPatchBaseline` mit von Amazon Linux 2 verwalteten Knoten verwenden, auf denen Kernel Live Patching aktiviert ist, und es werden Kernel-Live-Updates angewendet.

**Anmerkung**  
Die `AWS-AmazonLinux2DefaultPatchBaseline`-Konfiguration hat eine Wartezeit von sieben Tagen nach Veröffentlichung oder letzten Aktualisierung eines Patches, bevor er automatisch installiert wird. Wenn Sie nicht sieben Tage warten möchten, bis Kernel-Live-Patches automatisch genehmigt werden, können Sie eine benutzerdefinierte Patch-Baseline erstellen und verwenden. In der Patch-Baseline können Sie keine Wartezeit für automatische Genehmigung oder einen kürzeren oder längeren Zeitraum angeben. Weitere Informationen finden Sie unter [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md).

Wir empfehlen die folgende Strategie zum Patchen Ihrer verwalteten Knoten mit Kernel-Live-Updates:

1. Aktivieren Sie Kernel Live Patching auf Ihren von Amazon Linux 2 verwalteten Knoten.

1. Verwenden SieRun Command, ein Tool in AWS Systems Manager, um einen `Scan` Vorgang auf Ihren verwalteten Knoten unter Verwendung der vordefinierten `AWS-AmazonLinux2DefaultPatchBaseline` oder einer benutzerdefinierten Patch-Baseline auszuführen, die auch nur auf `Security` Updates abzielt, deren Schweregrad als `Critical` und und eingestuft ist`Important`, und dem `Bugfix` Schweregrad von`All`. 

1. Verwenden Sie Compliance, ein Tool in AWS Systems Manager, um zu überprüfen, ob für einen der verwalteten Knoten, die gescannt wurden, Verstöße wegen Patches gemeldet wurden. Wenn dies der Fall ist, zeigen Sie die Compliance-Details für den Knoten an, um festzustellen, ob Kernel-Live-Patches im verwalteten Knoten fehlen.

1. Um fehlende Kernel-Live-Patches zu installieren, verwenden Sie Run Command mit derselben Patch-Baseline, die Sie zuvor angegeben haben, führen Sie dieses Mal jedoch eine `Install`-Operation anstelle einer `Scan`-Operation aus.

   Da Kernel-Live-Patches installiert werden, ohne dass ein Neustart erforderlich ist, können Sie die Neustartoption `NoReboot` für diese Operation auswählen. 
**Anmerkung**  
Sie können den verwalteten Knoten dennoch neu starten, wenn dies für andere auf dem Knoten installierte Patch-Typen erforderlich ist oder wenn Sie auf einen neueren Kernel aktualisieren möchten. Wählen Sie in diesen Fällen stattdessen die Neustartoption `RebootIfNeeded` aus.

1. Kehren Sie zu Compliance zurück, um zu überprüfen, ob die Kernel-Live-Patches installiert wurden.

# Aktivieren von Kernel Live Patching mit Run Command
<a name="enable-klp"></a>

Um Kernel Live Patching zu aktivieren, können Sie entweder `yum`-Befehle auf Ihren verwalteten Knoten ausführen oder Run Command und ein benutzerdefiniertes Systems-Manager-Dokument (SSM-Dokument) verwenden, das Sie erstellen.

Weitere Informationen zum Aktivieren von Kernel Live Patching durch Ausführen von `yum`-Befehlen direkt auf dem verwalteten Knoten finden Sie unter [Aktivieren von Kernel Live Patching](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq) im *Benutzerhandbuch zu Amazon EC2*.

**Anmerkung**  
Wenn Sie Kernel-Live-Patching aktivieren und der bereits auf dem verwalteten Knoten ausgeführte Kernel eine *frühere* Version als `kernel-4.14.165-131.185.amzn2.x86_64` (die unterstützte Mindestversion) ist, installiert der Prozess die neueste verfügbare Kernel-Version und startet den verwalteten Knoten neu. Wenn der Knoten bereits `kernel-4.14.165-131.185.amzn2.x86_64` oder höher ausführt, installiert der Prozess keine neuere Version und startet den Knoten nicht neu.

**So aktivieren Sie Kernel Live Patching mit Run Command (Konsole)**

1. Öffnen Sie die AWS Systems Manager-Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Wählen Sie im Navigationsbereich **Run Command** aus.

1. Wählen Sie **Befehl ausführen** aus.

1. Wählen Sie in der Liste **Command document (Befehlsdokument)** das benutzerdefinierte SSM-Dokument `AWS-ConfigureKernelLivePatching` aus.

1. Geben Sie im Abschnitt **Command parameters** (Befehlsparameter) an, ob verwaltete Knoten als Teil dieser Operation neu gestartet werden sollen.

1. Weitere Informationen zur Verwendung der übrigen Steuerelemente auf dieser Seite finden Sie unter [Ausführen von Befehlen über die Konsole](running-commands-console.md).

1. Wählen Sie **Ausführen** aus.

**Aktivieren von Kernel Live Patching (AWS CLI)**
+ Führen Sie den folgenden Befehl auf Ihrem lokalen Computer aus.

------
#### [ Linux & macOS ]

  ```
  aws ssm send-command \
      --document-name "AWS-ConfigureKernelLivePatching" \
      --parameters "EnableOrDisable=Enable" \
      --targets "Key=instanceids,Values=instance-id"
  ```

------
#### [ Windows Server ]

  ```
  aws ssm send-command ^
      --document-name "AWS-ConfigureKernelLivePatching" ^
      --parameters "EnableOrDisable=Enable" ^
      --targets "Key=instanceids,Values=instance-id"
  ```

------

  Ersetzen Sie *instance-id* durch die ID des von Amazon Linux 2 verwalteten Knoten, auf dem Sie das Feature aktivieren möchten, beispielsweise i-02573cafcfEXAMPLE. Um das Feature auf mehreren verwalteten Knoten zu aktivieren, können Sie eines der folgenden Formate verwenden.
  + `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
  + `--targets "Key=tag:tag-key,Values=tag-value"`

  Informationen über andere Optionen, die Sie in dem Befehl verwenden können, finden Sie im Abschnitt [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) in der *AWS CLI-Befehlsreferenz*.

# Anwenden von Kernel-Live-Patches unter Verwendung von Run Command
<a name="install-klp"></a>

Um Kernel-Live-Patches anzuwenden, können Sie entweder `yum`-Befehle auf Ihren verwalteten Knoten ausführen oder Run Command und das SSM-Dokument `AWS-RunPatchBaseline` verwenden. 

Weitere Informationen zum Anwenden von Kernel-Live-Patches durch Ausführung von `yum`-Befehlen direkt auf dem verwalteten Knoten finden Sie unter [Anwenden von Kernel-Live-Patches](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-apply) im *Benutzerhandbuch zu Amazon EC2*.

**So wenden Sie Kernel-Live-Patches unter Verwendung von Run Command an (Konsole)**

1. Öffnen Sie die AWS Systems Manager-Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Wählen Sie im Navigationsbereich **Run Command** aus.

1. Wählen Sie **Befehl ausführen** aus.

1. Wählen Sie in der Liste **Command document (Befehlsdokument)** das SSM-Dokument `AWS-RunPatchBaseline` aus.

1. Führen Sie im Abschnitt **Command parameters (Befehlsparameter)** einen der folgenden Schritte aus:
   + Wenn Sie prüfen, ob neue Kernel-Live-Patches verfügbar sind, wählen Sie für **Operation** die Option `Scan` aus. Wenn Ihre verwalteten Knoten nach dieser Operation nicht neu gestartet werden sollen, wählen Sie für **Reboot Option** (Neustartoption) `NoReboot` aus. Nach Abschluss der Operation können Sie in Compliance prüfen, ob neue Patches vorhanden sind und wie der Compliance-Status lautet.
   + Wenn Sie die Patch-Compliance bereits überprüft haben und bereit sind, verfügbare Kernel-Live-Patches anzuwenden, wählen Sie für **Operation** die Option `Install` aus. Wenn Ihre verwalteten Knoten nach dieser Operation nicht neu gestartet werden sollen, wählen Sie für **Reboot Option** (Neustartoption) `NoReboot` aus.

1. Weitere Informationen zur Verwendung der übrigen Steuerelemente auf dieser Seite finden Sie unter [Ausführen von Befehlen über die Konsole](running-commands-console.md).

1. Wählen Sie **Ausführen** aus.

**So wenden Sie Kernel-Live-Patches unter Verwendung von Run Command an (AWS CLI)**

1. Führen Sie den folgenden Befehl von Ihrem lokalen Computer aus, um eine `Scan`-Operation auszuführen, bevor Sie Ihre Ergebnisse in Compliance überprüfen.

------
#### [ Linux & macOS ]

   ```
   aws ssm send-command \
       --document-name "AWS-RunPatchBaseline" \
       --targets "Key=InstanceIds,Values=instance-id" \
       --parameters '{"Operation":["Scan"],"RebootOption":["RebootIfNeeded"]}'
   ```

------
#### [ Windows Server ]

   ```
   aws ssm send-command ^
       --document-name "AWS-RunPatchBaseline" ^
       --targets "Key=InstanceIds,Values=instance-id" ^
       --parameters {\"Operation\":[\"Scan\"],\"RebootOption\":[\"RebootIfNeeded\"]}
   ```

------

   Informationen über andere Optionen, die Sie in dem Befehl verwenden können, finden Sie im Abschnitt [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) in der *AWS CLI-Befehlsreferenz*.

1. Führen Sie den folgenden Befehl von Ihrem lokalen Computer aus, um eine `Install`-Operation auszuführen, nachdem Sie die Ergebnisse in Compliance überprüft haben.

------
#### [ Linux & macOS ]

   ```
   aws ssm send-command \
       --document-name "AWS-RunPatchBaseline" \
       --targets "Key=InstanceIds,Values=instance-id" \
       --parameters '{"Operation":["Install"],"RebootOption":["NoReboot"]}'
   ```

------
#### [ Windows Server ]

   ```
   aws ssm send-command ^
       --document-name "AWS-RunPatchBaseline" ^
       --targets "Key=InstanceIds,Values=instance-id" ^
       --parameters {\"Operation\":[\"Install\"],\"RebootOption\":[\"NoReboot\"]}
   ```

------

Ersetzen Sie in den beiden vorangegangenen Befehlen *instance-id* durch die ID des von Amazon Linux 2 verwalteten Knoten, auf dem Sie Kernel-Live-Patches anwenden möchten, beispielsweise i-02573cafcfEXAMPLE. Um das Feature auf mehreren verwalteten Knoten zu aktivieren, können Sie eines der folgenden Formate verwenden.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`

Informationen über andere Optionen, die Sie in diesen Befehlen verwenden können, finden Sie im Abschnitt [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) in der *AWS CLI-Befehlsreferenz*.

# Deaktivieren von Kernel Live Patching mit Run Command
<a name="disable-klp"></a>

Um Kernel Live Patching zu deaktivieren, können Sie entweder `yum`-Befehle auf Ihren verwalteten Knoten ausführen oder Run Command und das benutzerdefinierte SSM-Dokument `AWS-ConfigureKernelLivePatching`.

**Anmerkung**  
Wenn Sie das Kernel-Live-Patching nicht mehr verwenden möchten, können Sie es jederzeit deaktivieren. In den meisten Fällen ist das Deaktivieren des Features nicht erforderlich.

Weitere Informationen zum Deaktivieren von Kernel Live Patching durch Ausführen von `yum`-Befehlen direkt auf dem verwalteten Knoten finden Sie unter [Aktivieren von Kernel Live Patching](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-enable) im *Benutzerhandbuch zu Amazon EC2*.

**Anmerkung**  
Wenn Sie Kernel Live Patching deaktivieren, deinstalliert der Prozess das Kernel Live Patching-Plugin und startet dann den verwalteten Knoten neu.

**Deaktivieren von Kernel Live Patching mit Run Command (Konsole)**

1. Öffnen Sie die AWS Systems Manager-Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Wählen Sie im Navigationsbereich **Run Command** aus.

1. Wählen Sie **Befehl ausführen** aus.

1. Wählen Sie in der Liste **Command document (Befehlsdokument)** das SSM-Dokument `AWS-ConfigureKernelLivePatching` aus.

1. Geben Sie im Abschnitt **Befehlsparameter** Werte für erforderliche Parameter an.

1. Weitere Informationen zur Verwendung der übrigen Steuerelemente auf dieser Seite finden Sie unter [Ausführen von Befehlen über die Konsole](running-commands-console.md).

1. Wählen Sie **Ausführen** aus.

**Deaktivieren von Kernel Live Patching (AWS CLI)**
+ Verwenden Sie einen Befehl ähnlich dem folgenden:

------
#### [ Linux & macOS ]

  ```
  aws ssm send-command \
      --document-name "AWS-ConfigureKernelLivePatching" \
      --targets "Key=instanceIds,Values=instance-id" \
      --parameters "EnableOrDisable=Disable"
  ```

------
#### [ Windows Server ]

  ```
  aws ssm send-command ^
      --document-name "AWS-ConfigureKernelLivePatching" ^
      --targets "Key=instanceIds,Values=instance-id" ^
      --parameters "EnableOrDisable=Disable"
  ```

------

  Ersetzen Sie *instance-id* durch die ID des von Amazon Linux 2 verwalteten Knoten, auf dem Sie das Feature deaktivieren möchten, beispielsweise i-02573cafcfEXAMPLE. Um das Feature auf mehreren verwalteten Knoten zu deaktivieren, können Sie eines der folgenden Formate verwenden.
  + `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
  + `--targets "Key=tag:tag-key,Values=tag-value"`

  Informationen über andere Optionen, die Sie in dem Befehl verwenden können, finden Sie im Abschnitt [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) in der *AWS CLI-Befehlsreferenz*.

# Arbeiten mit Patch Manager-Ressourcen und Compliance mithilfe der Konsole
<a name="patch-manager-console"></a>

Um ein Tool in zu verwenden Patch Manager AWS Systems Manager, führen Sie die folgenden Aufgaben aus. Diese Aufgaben werden später in diesem Abschnitt ausführlich erläutert.

1. Stellen Sie sicher, dass die AWS vordefinierte Patch-Baseline für jeden von Ihnen verwendeten Betriebssystemtyp Ihren Anforderungen entspricht. Ist dies nicht der Fall, sollten Sie eine Patch-Baseline erstellen, in der Standard-Patches für diesen Typ von verwalteten Knoten definiert sind, und diese als Standard-Patch-Baseline festlegen.

1. Organisieren Sie verwaltete Knoten mithilfe von Amazon Elastic Compute Cloud (Amazon EC2)-Tags in Patch-Gruppen (optional, aber empfohlen).

1. Führen Sie eine der folgenden Aktionen aus:
   + (Empfohlen) Konfigurieren Sie eine Patch-Richtlinie in Quick Setup, einem Tool in Systems Manager, mit dem Sie fehlende Patches nach einem Zeitplan für eine gesamte Organisation, eine Teilmenge von Organisationseinheiten oder ein einzelnes AWS-Konto installieren können. Weitere Informationen finden Sie unter [Das Patchen für Instances in einer Organisation mithilfe einer Patch-Richtlinie für Quick Setup konfigurieren](quick-setup-patch-manager.md).
   + Erstellen Sie ein Wartungsfenster, das das Systems Manager-Dokument (SSM-Dokument) `AWS-RunPatchBaseline` in einem Run Command-Aufgabentyp verwendet. Weitere Informationen finden Sie unter [Tutorial: Erstellen Sie ein Wartungsfenster zum Patchen über die Konsole](maintenance-window-tutorial-patching.md).
   + Führen Sie `AWS-RunPatchBaseline` manuell in einer Run Command-Operation aus. Weitere Informationen finden Sie unter [Ausführen von Befehlen über die Konsole](running-commands-console.md).
   + Patchen Sie Knoten bei Bedarf manuell mit der Funktion **Patch now** (Jetzt patchen). Weitere Informationen finden Sie unter [On-Demand-Patchen von verwalteten Knoten](patch-manager-patch-now-on-demand.md).

1. Überwachen Sie das Patching, um die Compliance zu überprüfen und Fehler zu untersuchen.

**Topics**
+ [Erstellen einer Patch-Richtlinie](patch-manager-create-a-patch-policy.md)
+ [Patch-Dashboard-Zusammenfassungen anzeigen](patch-manager-view-dashboard-summaries.md)
+ [Arbeiten mit Patch-Compliance-Berichten](patch-manager-compliance-reports.md)
+ [On-Demand-Patchen von verwalteten Knoten](patch-manager-patch-now-on-demand.md)
+ [Arbeiten mit Patch-Baselines](patch-manager-create-a-patch-baseline.md)
+ [Anzeigen verfügbarer Patches](patch-manager-view-available-patches.md)
+ [Erstellen und Verwalten von Patch-Gruppen](patch-manager-tag-a-patch-group.md)
+ [Integrieren Patch Manager mit AWS Security Hub CSPM](patch-manager-security-hub-integration.md)

# Erstellen einer Patch-Richtlinie
<a name="patch-manager-create-a-patch-policy"></a>

Eine Patch-Richtlinie ist eine Konfiguration, die Sie mit Quick Setup, einem Tool in AWS Systems Manager, einrichten. Patch-Richtlinien bieten eine umfassendere und zentralisiertere Kontrolle über Ihre Patching-Vorgänge, als dies mit anderen Methoden zum Konfigurieren von Patches möglich ist. Eine Patch-Richtlinie definiert den Zeitplan und die Baseline, die beim automatischen Patchen Ihrer Knoten und Anwendungen verwendet werden sollen.

Weitere Informationen finden Sie unter den folgenden Themen:
+ [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md)
+ [Das Patchen für Instances in einer Organisation mithilfe einer Patch-Richtlinie für Quick Setup konfigurieren](quick-setup-patch-manager.md)

# Patch-Dashboard-Zusammenfassungen anzeigen
<a name="patch-manager-view-dashboard-summaries"></a>

Die **Dashboard**-Registerkarte in Patch Manager bietet eine Übersicht über die Konsole, die Sie verwenden können, um Ihre Patch-Vorgänge in einer konsolidierten Ansicht zu überwachen. Patch Manager ist ein Tool in AWS Systems Manager. Auf der Registerkarte **Dashboard** können Sie folgenden Tabellen anzeigen:
+ Ein Snapshot, wie viele verwaltete Knoten mit Patching-Regeln konform bzw. nicht konform sind.
+ Ein Snapshot des Alters der Patch-Compliance-Ergebnisse für Ihre verwalteten Knoten.
+ Eine verknüpfte Anzahl davon, wie viele nicht konforme verwaltete Knoten für jeden der häufigsten Gründe für Nicht-Compliance vorhanden sind.
+ Eine verknüpfte Liste der letzten Patching-Vorgänge.
+ Eine verknüpfte Liste der wiederkehrenden Patching-Vorgänge, die eingerichtet wurden.

**So zeigen Sie Patch-Dashboard-Übersichten**

1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Wählen Sie im Navigationsbereich **Patch Manager** aus.

1. Wählen Sie die Registerkarte **Dashboard** aus.

1. Scrollen Sie zu dem Abschnitt mit zusammenfassenden Daten, den Sie anzeigen möchten:
   + **Amazon-EC2-Instance-Management**
   + **Zusammenfassung der Compliance**
   + **Anzahl der Nichteinhaltungen der Compliance**
   + **Compliance-Berichte**
   + **Nicht auf Patch-Richtlinien basierende Vorgänge**
   + **Wiederkehrende Aufgaben, die nicht auf Patch-Richtlinien basieren**

# Arbeiten mit Patch-Compliance-Berichten
<a name="patch-manager-compliance-reports"></a>

Die Informationen in den folgenden Themen helfen Ihnen beim Erstellen von und Arbeiten mit Patch-Compliance-Berichten in Patch Manager, einem Tool in AWS Systems Manager.

Die Informationen in den folgenden Themen gelten unabhängig davon, welche Methode oder Art der Konfiguration Sie für Ihre Patching-Vorgänge verwenden: 
+ Eine in Quick Setup konfigurierte Patch-Richtlinie
+ Eine in Quick Setup konfigurierte Host-Management-Option
+ Ein Wartungsfenster zum Ausführen eines Patch-`Scan` oder einer `Install`-Aufgabe
+ Ein On-Demand-**Jetzt patchen**-Vorgang

**Wichtig**  
Patch-Compliance-Berichte sind point-in-time Schnappschüsse, die nur bei erfolgreichen Patch-Vorgängen generiert werden. Jeder Bericht enthält eine Erfassungszeit, aus der hervorgeht, wann der Compliance-Status berechnet wurde.  
Wenn Sie mehrere Arten von Vorgängen einsetzen, um Ihre Instances auf Patch-Compliance zu überprüfen, beachten Sie, dass jeder Scan die Patch-Compliance-Daten der vorherigen Scans überschreibt. Dies kann zu unerwarteten Ergebnissen in Ihren Patch-Compliance-Daten führen. Weitere Informationen finden Sie unter [Identifizieren der Ausführung, die Patch-Compliance-Daten erstellt hat](patch-manager-compliance-data-overwrites.md).  
Um zu überprüfen, welche Patch-Baseline verwendet wurde, um die neuesten Compliance-Informationen zu generieren, navigieren Sie zur Registerkarte **Compliance-Berichte** in Patch Manager, suchen Sie die Zeile für den verwalteten Knoten, zu dem Sie Informationen wünschen, und wählen Sie dann die Baseline-ID in der Spalte **Verwendete Baseline-ID** aus.

**Topics**
+ [Anzeigen der Patch-Compliance-Ergebnisse](patch-manager-view-compliance-results.md)
+ [Generieren von Patch-Compliance-Berichten im .csv-Format](patch-manager-store-compliance-results-in-s3.md)
+ [Behebung nicht konformer verwalteter Knoten mit Patch Manager](patch-manager-noncompliant-nodes.md)
+ [Identifizieren der Ausführung, die Patch-Compliance-Daten erstellt hat](patch-manager-compliance-data-overwrites.md)

# Anzeigen der Patch-Compliance-Ergebnisse
<a name="patch-manager-view-compliance-results"></a>

Gehen Sie wie folgt vor, um Patch-Compliance-Informationen zu Ihren verwalteten Knoten anzuzeigen.

Dieses Verfahren gilt für Patchvorgänge, die das `AWS-RunPatchBaseline`-Dokument verwenden. Weitere Informationen zum Anzeigen von Patch-Compliance-Informationen für Patch-Operationen, die das `AWS-RunPatchBaselineAssociation`-Dokument verwenden, finden Sie unter [Identifizieren von nicht konformen verwalteten Knoten](patch-manager-find-noncompliant-nodes.md).

**Anmerkung**  
Die Patchscanvorgänge für das Dokument Quick Setup und die Explorer Verwendung des `AWS-RunPatchBaselineAssociation` Dokuments. Quick Setupund Explorer sind beide Tools in AWS Systems Manager.

**Identifizieren der Patch-Lösung für ein bestimmtes CVE-Problem (Linux)**  
Für viele Linux-basierte Betriebssysteme geben die Patch-Compliance-Ergebnisse an, welche CVE (Common Vulnerabilities and Exposure) Bulletin-Probleme durch welche Patches behoben werden. Mithilfe dieser Informationen können Sie feststellen, wie dringend Sie einen fehlenden oder fehlgeschlagenen Patch installieren müssen.

CVE-Details sind für unterstützte Versionen der folgenden Betriebssystemtypen enthalten:
+ AlmaLinux
+ Amazon Linux 2
+ Amazon Linux 2023
+ Oracle Linux
+ Red Hat Enterprise Linux (RHEL)
+ Rocky Linux

**Anmerkung**  
Standardmäßig stellt CentOS Stream keine CVE-Informationen zu Updates bereit. Sie können diese Unterstützung jedoch zulassen, indem Sie Repositorys von Drittanbietern wie das EPEL-Repository (EPEL), das von Fedora veröffentlicht wurde, verwenden. Weitere Informationen finden Sie unter [EPEL](https://fedoraproject.org/wiki/EPEL) im Fedora-Wiki.  
Derzeit werden CVE-ID-Werte nur für Patches mit dem Status `Missing` oder `Failed` gemeldet.

Sie können CVE auch IDs zu Ihren Listen mit genehmigten oder abgelehnten Patches in Ihren Patch-Baselines hinzufügen, je nachdem, was die Situation und Ihre Patch-Ziele erfordern.

Weitere Informationen zum Arbeiten mit genehmigten und abgelehnten Patch-Listen finden Sie in den folgenden Themen:
+ [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md)
+ [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md)
+ [Funktionsweise von Patch-Baseline-Regeln auf Linux-basierten Systemen](patch-manager-linux-rules.md)
+ [Wie Patches installiert werden](patch-manager-installing-patches.md)

**Anmerkung**  
In einigen Fällen veröffentlicht Microsoft Patches für Anwendungen, die kein aktualisiertes Datum und keine aktualisierte Uhrzeit angeben. In diesen Fällen wird ein aktualisiertes Datum und eine Uhrzeit von `01/01/1970` standardmäßig angegeben.

## Anzeigen der Patch-Compliance-Ergebnisse
<a name="viewing-patch-compliance-results-console"></a>

Verwenden Sie die folgenden Verfahren, um Patch-Compliance-Ergebnisse in der AWS Systems Manager -Konsole anzuzeigen. 

**Anmerkung**  
Weitere Informationen zum Erstellen von Patch-Compliance-Berichten, die in einen Amazon Simple Storage Service (Amazon S3)-Bucket heruntergeladen werden, finden Sie unter [Generieren von Patch-Compliance-Berichten im .csv-Format](patch-manager-store-compliance-results-in-s3.md).

**Anzeigen der Patch-Compliance-Ergebnisse**

1. Führen Sie eine der folgenden Aufgaben aus.

   **Option 1** (empfohlen) – Navigieren Sie von Patch Manager, einem Tool in AWS Systems Manager:
   + Wählen Sie im Navigationsbereich **Patch Manager** aus.
   + Wählen Sie die Registerkarte **Compliance reporting** (Compliance-Berichte).
   + Wählen Sie im Bereich **Details zum Knoten-Patching** die Knoten-ID des verwalteten Knotens aus, für den Sie die Ergebnisse der Patch-Compliance überprüfen möchten. Knoten, die hier angezeigt werden `stopped` oder nicht `terminated` angezeigt werden.
   + Wählen Sie im Bereich **Details** in der **Eigenschaftenliste** die Option **Patches** aus.

   **Option 2** – Navigieren Sie ab Compliance, einem Tool in AWS Systems Manager:
   + Wählen Sie im linken Navigationsbereich **Compliance**.
   + Für **Zusammenfassung von Compliance-Ressourcen** wählen Sie in der Spalte für die Typen von Patch-Ressourcen, die Sie überprüfen möchten, z. B. **Nicht regelkonforme Ressourcen**, eine Zahl aus.
   + In der **Ressourcen**-Liste unten wählen Sie die ID des verwalteten Knoten aus, für den Sie die Patch-Compliance-Ergebnisse prüfen möchten.
   + Wählen Sie im Bereich **Details** in der **Eigenschaftenliste** die Option **Patches** aus.

   **Option 3** – Navigieren Sie von Fleet Manager, einem Tool in AWS Systems Manager.
   + Wählen Sie im Navigationsbereich **Fleet Manager** aus.
   + Wählen Sie im Bereich **Verwaltete instances** die ID des verwalteten Knotens aus, für den Sie die Ergebnisse der Patch-Compliance überprüfen möchten.
   + Wählen Sie im Bereich **Details** in der **Eigenschaftenliste** die Option **Patches** aus.

1. (Optional) Wählen Sie im Suchfeld (![\[The Search icon\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/search-icon.png)) einen der verfügbaren Filter aus.

   Wählen Sie zum Beispiel für Red Hat Enterprise Linux (RHEL) aus den folgenden Optionen aus:
   + Name
   + Klassifizierung
   + Status
   + Schweregrad

    Wählen Sie für Windows Server eine der folgenden Optionen aus:
   + KB
   + Klassifizierung
   + Status
   + Schweregrad

1. Wählen Sie einen der verfügbaren Werte für den ausgewählten Filtertyp aus. Wenn Sie beispielsweise „**Status**“ ausgewählt haben, wählen Sie jetzt einen Konformitätsstatus wie **InstalledPendingReboot**„**Fehlgeschlagen**“ oder „**Fehlt“**.
**Anmerkung**  
Derzeit werden CVE-ID-Werte nur für Patches mit dem Status `Missing` oder `Failed` gemeldet.

1. Abhängig vom Compliance-Zustand des verwalteten Knoten können Sie auswählen, welche Maßnahmen zum Beheben von nicht konformen Knoten ergriffen werden sollen.

   Sie können beispielsweise wählen, dass Ihre nicht konformen verwalteten Knoten sofort gepatcht werden sollen. Informationen zum On-Demand-Patching Ihrer verwalteten Knoten finden Sie unter [On-Demand-Patchen von verwalteten Knoten](patch-manager-patch-now-on-demand.md).

   Weitere Informationen zu Patch-Compliance-Status finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).

# Generieren von Patch-Compliance-Berichten im .csv-Format
<a name="patch-manager-store-compliance-results-in-s3"></a>

Sie können die AWS Systems Manager Konsole verwenden, um Patch-Compliance-Berichte zu erstellen, die als CSV-Datei in einem Amazon Simple Storage Service (Amazon S3) -Bucket Ihrer Wahl gespeichert werden. Sie können einen einzelnen On-Demand-Bericht erstellen oder einen Zeitplan für die automatische Generierung der Berichte angeben. 

Berichte können für einen einzelnen verwalteten Knoten oder für alle verwalteten Knoten in Ihrem ausgewählten AWS-Konto und AWS-Region generiert werden. Für einen einzelnen Knoten enthält ein Bericht umfassende Details, einschließlich der Patches, die IDs sich auf die Nichtkonformität eines Knotens beziehen. Für einen Bericht über alle verwaltete Knoten werden nur zusammenfassende Informationen und die Anzahl der Patches von nicht konformen Knoten bereitgestellt.

Nachdem ein Bericht generiert wurde, können Sie ein Tool wie Amazon Quick verwenden, um die Daten zu importieren und zu analysieren. Quick ist ein Business Intelligence (BI) -Service, mit dem Sie Informationen in einer interaktiven visuellen Umgebung untersuchen und interpretieren können. Weitere Informationen finden Sie in der [Amazon-Kurzanleitung](https://docs.aws.amazon.com/quicksuite/latest/userguide/what-is.html).

**Anmerkung**  
Wenn Sie eine benutzerdefinierte Patch-Baseline erstellen, können Sie für Patches, die von dieser Patch-Baseline genehmigt wurden, einen Schweregrad für die Konformität angeben, beispielsweise `Critical` oder `High`. Wenn der Patch-Status eines genehmigten Patches als `Missing` gemeldet wird, dann ist der insgesamt gemeldete Konformitätsschweregrad der Patch-Baseline der von Ihnen angegebene Schweregrad.

Sie können auch ein Thema zum Amazon Simple Notification Service (Amazon SNS) angeben, um Benachrichtigungen zu senden, wenn ein Bericht erstellt wird.

**Servicerollen zum Generieren von Patch-Compliance-Berichten**  
Wenn Sie zum ersten Mal einen Bericht erstellen, erstellt Systems Manager eine angenommene Automatisierungsrolle mit dem Namen `AWS-SystemsManager-PatchSummaryExportRole`, die für den Exportprozess zu S3 verwendet wird.

**Anmerkung**  
Wenn Sie Compliance-Daten in einen verschlüsselten S3-Bucket exportieren, müssen Sie die zugehörige AWS KMS Schlüsselrichtlinie aktualisieren, um die erforderlichen Berechtigungen für bereitzustellen`AWS-SystemsManager-PatchSummaryExportRole`. Fügen Sie beispielsweise der AWS KMS Richtlinie Ihres S3-Buckets eine ähnliche Berechtigung hinzu:  

```
{
    "Effect": "Allow",
    "Action": [
        "kms:GenerateDataKey"
    ],
    "Resource": "role-arn"
}
```
*role-arn*Ersetzen Sie es durch den Amazon-Ressourcennamen (ARN) der in Ihrem Konto erstellten Datei im Format`arn:aws:iam::111222333444:role/service-role/AWS-SystemsManager-PatchSummaryExportRole`.  
Weitere Informationen finden Sie unter [Schlüsselrichtlinien in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) im *Entwicklerhandbuch für AWS Key Management Service *.

Wenn Sie zum ersten Mal einen Bericht nach einem Zeitplan generieren, erstellt Systems Manager eine weitere Servicerolle mit dem Namen `AWS-EventBridge-Start-SSMAutomationRole` zusammen mit der Servicerolle `AWS-SystemsManager-PatchSummaryExportRole` (falls nicht bereits erstellt), die für den Exportvorgang verwendet werden soll. `AWS-EventBridge-Start-SSMAutomationRole`ermöglicht Amazon EventBridge , eine Automatisierung mit dem Runbook [AWS ExportPatchReportToS3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3) zu starten.

Es wird empfohlen, diese Richtlinien und Rollen zu ändern. Dies kann dazu führen, dass die Erstellung von Patch-Compliance-Berichten fehlschlägt. Weitere Informationen finden Sie unter [Problembehandlung bei der Erstellung von Patch-Compliance-Berichten](#patch-compliance-reports-troubleshooting).

**Topics**
+ [Was ist in einem generierten Patch-Compliance-Bericht enthalten?](#patch-compliance-reports-to-s3-examples)
+ [Generieren von Patch-Compliance-Berichten für einen einzelnen verwalteten Knoten](#patch-compliance-reports-to-s3-one-instance)
+ [Generieren von Patch-Compliance-Berichten für alle verwaltete Knoten](#patch-compliance-reports-to-s3-all-instances)
+ [Berichtsverlauf für Patch-Compliance anzeigen](#patch-compliance-reporting-history)
+ [Zeitpläne für Patch-Compliance-Berichte anzeigen](#patch-compliance-reporting-schedules)
+ [Problembehandlung bei der Erstellung von Patch-Compliance-Berichten](#patch-compliance-reports-troubleshooting)

## Was ist in einem generierten Patch-Compliance-Bericht enthalten?
<a name="patch-compliance-reports-to-s3-examples"></a>

Dieses Thema enthält Informationen zu den Inhaltstypen, die in den Patch-Compliance-Berichten enthalten sind, die generiert und in einen angegebenen S3-Bucket heruntergeladen werden.

### Berichtsformat für einen einzelnen verwalteten Knoten
<a name="patch-compliance-reports-to-s3-examples-single-instance"></a>

Ein für einen einzelnen verwalteten Knoten generierter Bericht liefert sowohl zusammenfassende als auch detaillierte Informationen.

[Herunterladen eines Beispielberichts (einzelner Knoten)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-single-instance-patch-compliance-report.zip)

Zu den zusammenfassenden Informationen für einen einzelnen verwalteten Knoten gehört Folgendes:
+ Index
+ Instance-ID
+ Instance name
+ Instance IP
+ Plattformname
+ Version der Plattform
+ SSM Agent-Version
+ Patch-Baseline
+ Patch-Gruppe
+ Compliance status (Compliance-Status)
+ Compliance-Schweregrad
+ Anzahl nicht konformer Patches mit kritischem Schweregrad
+ Anzahl nicht konformer Patches mit hohem Schweregrad
+ Anzahl nicht konformer Patches mit der Schweregrad Mittel
+ Anzahl nicht konformer Patches mit niedrigem Schweregrad
+ Anzahl nicht konformer Patches mit informativen Schweregrad
+ Anzahl nicht konformer Patches mit nicht spezifiziertem Schweregrad

Zu den detaillierten Informationen für einen verwalteten einzelnen Knoten gehört Folgendes:
+ Index
+ Instance-ID
+ Instance name
+ Patch-Name
+  ID/Patch KB-ID
+ Patch-Status
+ Zeitpunkt des letzten Berichts
+ Compliance-Stufe
+ Patch-Schweregrad
+ Patch-Klassifizierung
+ CVE-ID
+ Patch-Baseline
+ Logs-URL
+ Instance IP
+ Plattformname
+ Version der Plattform
+ SSM Agent-Version

**Anmerkung**  
Wenn Sie eine benutzerdefinierte Patch-Baseline erstellen, können Sie für Patches, die von dieser Patch-Baseline genehmigt wurden, einen Schweregrad für die Konformität angeben, beispielsweise `Critical` oder `High`. Wenn der Patch-Status eines genehmigten Patches als `Missing` gemeldet wird, dann ist der insgesamt gemeldete Konformitätsschweregrad der Patch-Baseline der von Ihnen angegebene Schweregrad.

### Berichtsformat für alle verwaltete Knoten
<a name="patch-compliance-reports-to-s3-examples-all-instances"></a>

Ein für alle verwaltete Knoten generierter Bericht enthält nur zusammenfassende Informationen.

[Herunterladen eines Beispielberichts (alle verwaltete Knoten)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-all-instances-patch-compliance-report.zip)

Zu den zusammenfassenden Informationen für alle verwaltete Knoten gehört Folgendes:
+ Index
+ Instance-ID
+ Instance name
+ Instance IP
+ Plattformname
+ Version der Plattform
+ SSM Agent-Version
+ Patch-Baseline
+ Patch-Gruppe
+ Compliance status (Compliance-Status)
+ Compliance-Schweregrad
+ Anzahl nicht konformer Patches mit kritischem Schweregrad
+ Anzahl nicht konformer Patches mit hohem Schweregrad
+ Anzahl nicht konformer Patches mit der Schweregrad Mittel
+ Anzahl nicht konformer Patches mit niedrigem Schweregrad
+ Anzahl nicht konformer Patches mit informativen Schweregrad
+ Anzahl nicht konformer Patches mit nicht spezifiziertem Schweregrad

## Generieren von Patch-Compliance-Berichten für einen einzelnen verwalteten Knoten
<a name="patch-compliance-reports-to-s3-one-instance"></a>

Gehen Sie wie folgt vor, um einen Patch-Zusammenfassungs-Bericht für einen einzelnen verwalteten Knoten in Ihrem AWS-Konto zu generieren. Der Bericht für einen einzelnen verwalteten Knoten enthält Details zu jedem Patch, der nicht konform ist, einschließlich Patch-Namen und IDs. 

**So generieren Sie Patch-Compliance-Berichte für einen einzelnen verwalteten Knoten**

1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Wählen Sie im Navigationsbereich **Patch Manager** aus.

1. Wählen Sie die Registerkarte **Compliance reporting** (Compliance-Berichte) aus.

1. Wählen Sie die Schaltfläche für die Zeile des verwalteten Knoten aus, für den Sie einen Bericht erstellen möchten, und wählen Sie dann **View detail** (Detail anzeigen) aus.

1. Wählen Sie Abschnitt mit der **Patch-Zusammenfassung** **Exportieren nach S3** aus.

1. Für **Berichtname** geben Sie einen Namen ein, damit Sie den Bericht später leichter identifizieren können.

1. Für **Meldehäufigkeit** wählen Sie eine der folgenden Optionen aus:
   + **On Demand** – Erstellen Sie einen einmaligen Bericht. Fahren Sie mit Schritt 9 fort.
   + **Nach einem Plan** – Geben Sie einen wiederkehrenden Zeitplan für die automatische Erstellung von Berichten an. Fahren Sie fort mit Schritt 8.

1. Für den **Typ „Nach einem Plan“** geben Sie entweder einen Kursausdruck an, z. B. alle 3 Tage, oder geben Sie einen Cron-Ausdruck an, um die Berichtshäufigkeit festzulegen.

   Informationen zu Cron-Ausdrücken finden Sie unter [Referenz: Cron- und Rate-Ausdrücke für System Manager](reference-cron-and-rate-expressions.md).

1. Für **Bucket-Name** wählen Sie den Namen eines S3-Buckets aus, in dem die CSV-Berichtsdateien gespeichert werden sollen.
**Wichtig**  
Wenn Sie in einem System arbeiten AWS-Region , das nach dem 20. März 2019 gestartet wurde, müssen Sie einen S3-Bucket in derselben Region auswählen. Nach diesem Datum gestartete Regionen wurden standardmäßig deaktiviert. Weitere Informationen und eine Liste dieser Regionen finden Sie unter [Aktivieren einer Region](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable) in der *Allgemeine Amazon Web Services-Referenz*.

1. (Optional) Um Benachrichtigungen zu senden, wenn der Bericht erstellt wird, erweitern Sie den Abschnitt **SNS-Thema** und wählen Sie dann aus **SNS-Thema Amazon-Ressourcenname (ARN)** ein vorhandenes Amazon-SNS-Thema aus.

1. Wählen Sie **Absenden** aus.

Informationen zum Anzeigen eines Verlaufs von generierten Berichten finden Sie unter [Berichtsverlauf für Patch-Compliance anzeigen](#patch-compliance-reporting-history).

Informationen zum Anzeigen von Details zu von Ihnen erstellten Berichtszeitplänen finden Sie unter [Zeitpläne für Patch-Compliance-Berichte anzeigen](#patch-compliance-reporting-schedules).

## Generieren von Patch-Compliance-Berichten für alle verwaltete Knoten
<a name="patch-compliance-reports-to-s3-all-instances"></a>

Gehen Sie wie folgt vor, um einen Patch-Zusammenfassungs-Bericht für alle verwaltete Knoten in Ihrem AWS-Konto zu generieren. Der Bericht für alle verwalteten Knoten zeigt an, welche Knoten nicht konform sind und wie viele Patches nicht konform sind. Es gibt keine Namen oder andere Bezeichner der Patches. Für diese zusätzlichen Details können Sie einen Patch-Compliance-Bericht für einen einzelnen verwalteten Knoten erstellen. Informationen finden Sie unter [Generieren von Patch-Compliance-Berichten für einen einzelnen verwalteten Knoten](#patch-compliance-reports-to-s3-one-instance) weiter vorne in diesem Thema. 

**Generieren von Patch-Compliance-Berichten für alle verwaltete Knoten**

1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Wählen Sie im Navigationsbereich **Patch Manager** aus.

1. Wählen Sie die Registerkarte **Compliance reporting** (Compliance-Berichte) aus.

1. Klicken Sie auf **Export to S3** (Exportieren nach S3). (Wählen Sie nicht zuerst eine Knoten-ID aus.)

1. Für **Berichtname** geben Sie einen Namen ein, damit Sie den Bericht später leichter identifizieren können.

1. Für **Meldehäufigkeit** wählen Sie eine der folgenden Optionen aus:
   + **On Demand** – Erstellen Sie einen einmaligen Bericht. Fahren Sie mit Schritt 8 fort.
   + **Nach einem Plan** – Geben Sie einen wiederkehrenden Zeitplan für die automatische Erstellung von Berichten an. Fahren Sie fort mit Schritt 7.

1. Für den **Typ „Nach einem Plan“** geben Sie entweder einen Kursausdruck an, z. B. alle 3 Tage, oder geben Sie einen Cron-Ausdruck an, um die Berichtshäufigkeit festzulegen.

   Informationen zu Cron-Ausdrücken finden Sie unter [Referenz: Cron- und Rate-Ausdrücke für System Manager](reference-cron-and-rate-expressions.md).

1. Für **Bucket-Name** wählen Sie den Namen eines S3-Buckets aus, in dem die CSV-Berichtsdateien gespeichert werden sollen.
**Wichtig**  
Wenn Sie in einem System arbeiten AWS-Region , das nach dem 20. März 2019 gestartet wurde, müssen Sie einen S3-Bucket in derselben Region auswählen. Nach diesem Datum gestartete Regionen wurden standardmäßig deaktiviert. Weitere Informationen und eine Liste dieser Regionen finden Sie unter [Aktivieren einer Region](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable) in der *Allgemeine Amazon Web Services-Referenz*.

1. (Optional) Um Benachrichtigungen zu senden, wenn der Bericht erstellt wird, erweitern Sie den Abschnitt **SNS-Thema** und wählen Sie dann aus **SNS-Thema Amazon-Ressourcenname (ARN)** ein vorhandenes Amazon-SNS-Thema aus.

1. Wählen Sie **Absenden** aus.

Informationen zum Anzeigen eines Verlaufs von generierten Berichten finden Sie unter [Berichtsverlauf für Patch-Compliance anzeigen](#patch-compliance-reporting-history).

Informationen zum Anzeigen von Details zu von Ihnen erstellten Berichtszeitplänen finden Sie unter [Zeitpläne für Patch-Compliance-Berichte anzeigen](#patch-compliance-reporting-schedules).

## Berichtsverlauf für Patch-Compliance anzeigen
<a name="patch-compliance-reporting-history"></a>

Mithilfe der Informationen in diesem Thema können Sie sich Details zu den Patch-Compliance-Berichten anzeigen lassen, die in Ihrem erstellt wurden AWS-Konto.

**Anzeigen des Berichtsverlaufs für Patch-Compliance**

1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Wählen Sie im Navigationsbereich **Patch Manager** aus.

1. Wählen Sie die Registerkarte **Compliance reporting** (Compliance-Berichte) aus.

1. Klicken Sie auf **Alle S3-Exporte anzeigen** und danach auf die Registerkarte **Exportieren des Verlaufs**.

## Zeitpläne für Patch-Compliance-Berichte anzeigen
<a name="patch-compliance-reporting-schedules"></a>

Mithilfe der Informationen in diesem Thema können Sie sich Details zu den in Ihrem erstellten Zeitplan für die Erstellung von Berichten zur Patch-Konformität anzeigen lassen AWS-Konto.

**Anzeigen des Berichtsverlaufs für Patch-Compliance**

1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Wählen Sie im Navigationsbereich **Patch Manager** aus.

1. Wählen Sie die Registerkarte **Compliance reporting** (Compliance-Berichte) aus.

1. Wählen Sie **View all S3 exports** (Alle S3-Exporte anzeigen) und danach die Registerkarte **Report schedule rules** (Regeln für die Berichtsplanung) aus.

## Problembehandlung bei der Erstellung von Patch-Compliance-Berichten
<a name="patch-compliance-reports-troubleshooting"></a>

Im Folgenden finden Sie Informationen zur Behandlung von Problemen mit Patch-Compliance-Berichten in Patch Manager, einem Tool in AWS Systems Manager.

**Topics**
+ [Eine Nachricht meldet, dass die `AWS-SystemsManager-PatchManagerExportRolePolicy`-Richtlinie beschädigt ist](#patch-compliance-reports-troubleshooting-1)
+ [Nach dem Löschen von Patch-Compliance-Richtlinien oder -Rollen werden geplante Berichte nicht erfolgreich generiert](#patch-compliance-reports-troubleshooting-2)

### Eine Nachricht meldet, dass die `AWS-SystemsManager-PatchManagerExportRolePolicy`-Richtlinie beschädigt ist
<a name="patch-compliance-reports-troubleshooting-1"></a>

**Problem**: Sie erhalten eine Fehlermeldung ähnlich der folgenden, die angibt, dass `AWS-SystemsManager-PatchManagerExportRolePolicy` beschädigt ist:

```
An error occurred while updating the AWS-SystemsManager-PatchManagerExportRolePolicy
policy. If you have edited the policy, you might need to delete the policy, and any 
role that uses it, then try again. Systems Manager recreates the roles and policies 
you have deleted.
```
+ **Lösung**: Verwenden Sie die Patch Manager Konsole oder löschen AWS CLI Sie die betroffenen Rollen und Richtlinien, bevor Sie einen neuen Patch-Compliance-Bericht erstellen.

**So löschen Sie die beschädigte Richtlinie über die Konsole**

  1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.

  1. Führen Sie eine der folgenden Aktionen aus:

     **On-Demand-Berichte** – Wenn das Problem beim Generieren eines einmaligen On-Demand-Berichts aufgetreten ist, wählen Sie in der linken Navigation **Richtlinien** aus und suchen Sie nach `AWS-SystemsManager-PatchManagerExportRolePolicy`. Löschen Sie dann die Richtlinie. Wählen Sie anschließend **Rollen** aus, suchen Sie nach `AWS-SystemsManager-PatchSummaryExportRole` und löschen Sie sie.

     **Geplante Berichte** – Wenn der Fehler während der Erstellung eines geplanten Berichts aufgetreten ist, wählen Sie in der linken Navigation **Richtlinien** aus, suchen Sie nacheinander nach `AWS-EventBridge-Start-SSMAutomationRolePolicy` und `AWS-SystemsManager-PatchManagerExportRolePolicy` und löschen Sie jede Richtlinie. Wählen Sie anschließend **Rollen** aus, schen Sie nacheinander nach `AWS-EventBridge-Start-SSMAutomationRole` und `AWS-SystemsManager-PatchSummaryExportRole` und löschen Sie jede Rolle.

**Um die beschädigte Richtlinie mit dem zu löschen AWS CLI**

  Ersetzen Sie das *placeholder values* durch Ihre Konto-ID.
  + Wenn das Problem bei der Erstellung eines einmaligen On-Demand-Berichts aufgetreten ist, führen Sie die folgenden Befehle aus:

    ```
    aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
    ```

    ```
    aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
    ```

    Wenn das Problem bei der Erstellung eines Zeitplanberichts auftritt, führen Sie die folgenden Befehle aus:

    ```
    aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-EventBridge-Start-SSMAutomationRolePolicy
    ```

    ```
    aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
    ```

    ```
    aws iam delete-role --role-name AWS-EventBridge-Start-SSMAutomationRole
    ```

    ```
    aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
    ```

  Nachdem Sie eines der beiden Verfahren abgeschlossen haben, folgen Sie den Schritten, um einen neuen Patch-Compliance-Bericht zu erstellen oder zu planen.

### Nach dem Löschen von Patch-Compliance-Richtlinien oder -Rollen werden geplante Berichte nicht erfolgreich generiert
<a name="patch-compliance-reports-troubleshooting-2"></a>

**Problem**: Wenn Sie zum ersten Mal einen Bericht erstellen, erstellt Systems Manager eine Servicerolle und eine Richtlinie für den Exportprozess (`AWS-SystemsManager-PatchSummaryExportRole` und `AWS-SystemsManager-PatchManagerExportRolePolicy`). Wenn Sie zum ersten Mal einen geplanten Bericht erstellen, erstellt Systems Manager eine weitere Servicerolle und eine Richtlinie (`AWS-EventBridge-Start-SSMAutomationRole` und `AWS-EventBridge-Start-SSMAutomationRolePolicy`). Diese ermöglichen es Amazon, eine Automatisierung mithilfe des Runbooks [AWS ExportPatchReportToS3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3) zu EventBridge starten.

Wenn Sie eine dieser Richtlinien oder Rollen löschen, gehen die Verbindungen zwischen Ihrem Zeitplan und Ihrem angegebenen S3-Bucket und Amazon SNS-Thema möglicherweise verloren. 
+ **Lösung**: Um dieses Problem zu umgehen, empfehlen wir, den vorherigen Zeitplan zu löschen und einen neuen Zeitplan zu erstellen, um den zu ersetzen, bei dem Probleme aufgetreten sind.

# Behebung nicht konformer verwalteter Knoten mit Patch Manager
<a name="patch-manager-noncompliant-nodes"></a>

Die Themen in diesem Abschnitt enthalten eine Übersicht darüber, wie verwaltete Knoten, die die Patch-Compliance nicht erfüllen, identifiziert werden können und wie sie konform gemacht werden.

**Topics**
+ [Identifizieren von nicht konformen verwalteten Knoten](patch-manager-find-noncompliant-nodes.md)
+ [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md)
+ [Patchen nicht konformer verwalteter Knoten](patch-manager-compliance-remediation.md)

# Identifizieren von nicht konformen verwalteten Knoten
<a name="patch-manager-find-noncompliant-nodes"></a>

Out-of-compliance verwaltete Knoten werden identifiziert, wenn eines von zwei AWS Systems Manager Dokumenten (SSM-Dokumente) ausgeführt wird. Diese SSM-Dokumente verweisen auf die entsprechende Patch-Baseline für jeden verwalteten Knoten in Patch Manager, einem Tool in AWS Systems Manager. Anschließend werten sie den Patch-Zustand des verwalteten Knoten aus und stellen Ihnen dann Compliance-Ergebnisse zur Verfügung.

Es gibt zwei SSM-Dokumente, die verwendet werden, um nicht konforme verwaltete Knoten zu identifizieren oder zu aktualisieren: `AWS-RunPatchBaseline` und `AWS-RunPatchBaselineAssociation`. Jedes wird von verschiedenen Prozessen verwendet, und ihre Compliance-Ergebnisse sind über verschiedene Kanäle verfügbar. In der folgenden Tabelle werden die Unterschiede zwischen diesen Dokumenten aufgeführt.

**Anmerkung**  
Daten zur Patch-Konformität von Patch Manager können an AWS Security Hub CSPM gesendet werden. Security Hub CSPM bietet Ihnen einen umfassenden Überblick über Ihre Sicherheitswarnungen mit hoher Priorität und den Compliance-Status. Er überwacht auch den Patching-Status Ihrer Flotte. Weitere Informationen finden Sie unter [Integrieren Patch Manager mit AWS Security Hub CSPM](patch-manager-security-hub-integration.md). 


|  | `AWS-RunPatchBaseline` | `AWS-RunPatchBaselineAssociation` | 
| --- | --- | --- | 
| Prozesse, die das Dokument verwenden |  **On-Demand-Patchen** – Sie können verwaltete Knoten bei Bedarf scannen oder patchen, indem Sie die Option **Patch now** (Jetzt patchen) verwenden. Weitere Informationen finden Sie unter [On-Demand-Patchen von verwalteten Knoten](patch-manager-patch-now-on-demand.md). **Quick Setup-Patch-Richtlinien von Systems Manager** – Sie können eine Patching-Konfiguration in Quick Setup, einem Tool in AWS Systems Manager, erstellen, die fehlende Patches in separaten Zeitplänen für eine gesamte Organisation, eine Teilmenge von Organisationseinheiten oder ein einzelnes AWS-Konto scannen oder installieren kann. Weitere Informationen finden Sie unter [Das Patchen für Instances in einer Organisation mithilfe einer Patch-Richtlinie für Quick Setup konfigurieren](quick-setup-patch-manager.md). **Einen Befehl ausführen** – Sie können `AWS-RunPatchBaseline` manuell in einem Vorgang in Run Command, einem Tool in AWS Systems Manager, ausführen. Weitere Informationen finden Sie unter [Ausführen von Befehlen über die Konsole](running-commands-console.md). **Wartungsfenster** – Sie können ein Wartungsfenster erstellen, das das SSM-Dokument `AWS-RunPatchBaseline` in einem Run Command-Aufgabentyp verwendet. Weitere Informationen finden Sie unter [Tutorial: Erstellen Sie ein Wartungsfenster zum Patchen über die Konsole](maintenance-window-tutorial-patching.md).  |  **Quick Setup-Host-Verwaltung für Systems Manager** – Sie können eine Host-Management-Konfigurationsoption in Quick Setup aktivieren, um Ihre verwalteten Instances täglich auf Patch-Compliance zu scannen. Weitere Informationen finden Sie unter [Amazon-EC2-Host-Verwaltung mit Quick Setup einrichten](quick-setup-host-management.md). **Systems Manager [Explorer](Explorer.md)**— Wenn Sie es zulassenExplorer, scannt ein Tool Ihre verwalteten Instanzen regelmäßig auf Patch-Konformität und meldet die Ergebnisse im Explorer Dashboard. AWS Systems Manager  | 
| Format der Patch-Scan-Ergebnisdaten |  Nach der Ausführung von `AWS-RunPatchBaseline` sendet Patch Manager ein `AWS:PatchSummary`-Objekt an Inventory, ein Tool in AWS Systems Manager. Dieser Bericht wird nur nach erfolgreichen Patch-Vorgängen generiert und enthält eine Erfassungszeit, anhand derer angegeben wird, wann der Compliance-Status berechnet wurde.  |  Nach der Ausführung von `AWS-RunPatchBaselineAssociation` sendet Patch Manager ein `AWS:ComplianceItem`-Objekt an Systems Manager Inventory.  | 
| So zeigen Sie aktuelle Compliance-Berichte in der Konsole an |  Sie können Patch-Compliance-Informationen für Prozesse anzeigen, die `AWS-RunPatchBaseline` in [Systems Manager Compliance](systems-manager-compliance.md) und [Arbeiten mit verwalteten Knoten](fleet-manager-managed-nodes.md) verwenden. Weitere Informationen finden Sie unter [Anzeigen der Patch-Compliance-Ergebnisse](patch-manager-view-compliance-results.md).  |  Wenn Sie Quick Setup verwenden, um Ihre verwalteten Instances auf Patch-Compliance zu überprüfen, finden Sie den Compliance-Bericht unter [Systems Manager Fleet Manager](fleet-manager.md). Wählen Sie in der Fleet Manager-Konsole die Knoten-ID Ihres verwalteten Knotens aus. Wählen Sie im Menü **Allgemein** die Option **Konfigurationskonformität** aus. Wenn Sie Explorer verwenden, um Ihre verwalteten Instances auf Patch-Compliance zu überprüfen, finden Sie den Compliance-Bericht sowohl unter Explorer als auch unter [Systems Manager OpsCenter](OpsCenter.md).  | 
| AWS CLI Befehle zum Anzeigen der Patch-Konformitätsergebnisse |  Für Prozesse, die dies verwenden`AWS-RunPatchBaseline`, können Sie die folgenden AWS CLI Befehle verwenden, um zusammenfassende Informationen zu Patches auf einem verwalteten Knoten anzuzeigen. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html)  |  Für Prozesse, die dies verwenden`AWS-RunPatchBaselineAssociation`, können Sie den folgenden AWS CLI Befehl verwenden, um zusammenfassende Informationen zu Patches auf einer Instanz anzuzeigen. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html)  | 
| Patch-Operationen |  Für Prozesse, die `AWS-RunPatchBaseline` verwenden, geben Sie an, ob der Vorgang nur eine `Scan`-Operation oder eine `Scan and install`-Operation ausführen soll. Wenn Ihr Ziel darin besteht, nicht konforme verwaltete Knoten zu identifizieren und nicht zu beheben, führen Sie nur eine `Scan`-Operation durch.  | Quick Setup- und Explorer-Prozesse, die AWS-RunPatchBaselineAssociation verwenden, führen nur eine Scan-Operation aus. | 
| Weitere Informationen |  [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)  |  [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)  | 

Informationen zu den verschiedenen Patch-Compliance-Status, die möglicherweise gemeldet werden, finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md)

Informationen zur Behebung verwalteter Knoten, die die Patch-Compliance nicht erfüllen, finden Sie unter [Patchen nicht konformer verwalteter Knoten](patch-manager-compliance-remediation.md).

# Statuswerte der Patch-Compliance
<a name="patch-manager-compliance-states"></a>

Zu den Informationen über Patches für einen verwalteten Knoten gehört ein Bericht über den Zustand oder den Status jedes einzelnen Patches.

**Tipp**  
Wenn Sie einem verwalteten Knoten einen bestimmten Patch-Compliance-Status zuweisen möchten, können Sie den Befehl [https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html) AWS Command Line Interface (AWS CLI) oder die [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html)API-Operation verwenden. Das Zuweisen eines Compliance-Zustands wird in der Konsole nicht unterstützt.

Verwenden Sie die Informationen in den folgenden Tabellen, um zu ermitteln, warum ein verwalteter Knoten möglicherweise nicht die Patch-Compliance erfüllt.

## Patch-Compliance-Werte für Debian Server und Ubuntu Server
<a name="patch-compliance-values-ubuntu"></a>

Für Debian Server und Ubuntu Server werden die Regeln für die Paketklassifizierung in verschiedene Compliance-Zustände in der folgenden Tabelle beschrieben.

**Anmerkung**  
Beachten Sie bei der Auswertung der Statuswerte `INSTALLED`, `INSTALLED_OTHER` und `MISSING` Folgendes: Wenn Sie beim Erstellen oder Aktualisieren einer Patch-Baseline das Kontrollkästchen **Funktionsupdates einschließen** nicht aktivieren, sind Patch-Kandidaten-Versionen auf Patches in den folgenden Repositorys beschränkt:   
Ubuntu Server 16.04 LTS: `xenial-security`
Ubuntu Server 18.04 LTS: `bionic-security`
Ubuntu Server 20.04 LTS: `focal-security`
Ubuntu Server 22.04 LTS (`jammy-security`)
Ubuntu Server 24.04 LTS (`noble-security`)
Ubuntu Server 25.04 (`plucky-security`)
`debian-security` (Debian Server)
Wenn Sie die Option **Nicht sicherheitsrelevante Aktualisierungen einschließen** auswählen, werden auch Patches aus anderen Repositorys berücksichtigt.


| Patch-Status | Description | Compliance status (Compliance-Status) | 
| --- | --- | --- | 
|  **`INSTALLED`**  |  Der Patch wird in der Patch-Baseline aufgeführt und ist auf dem verwalteten Knoten installiert. Er könnte entweder manuell von einer Person oder automatisch von Patch Manager installiert worden sein, wenn das `AWS-RunPatchBaseline`-Dokument auf dem verwalteten Knoten ausgeführt wurde.  | Konform | 
|  **`INSTALLED_OTHER`**  |  Der Patch ist nicht in der Baseline enthalten oder wird von der Baseline nicht genehmigt, ist aber auf dem verwalteten Knoten installiert. Der Patch wurde möglicherweise manuell installiert, das Paket könnte eine erforderliche Abhängigkeit von einem anderen genehmigten Patch sein, oder der Patch war möglicherweise Teil eines InstallOverrideList Vorgangs. Wenn Sie `Block` nicht als die **Zurückgewiesene Patches**-Aktion angeben, schließt `INSTALLED_OTHER` auch installiert, aber abgelehnte Patches ein.   | Konform | 
|  **`INSTALLED_PENDING_REBOOT`**  |  `INSTALLED_PENDING_REBOOT` kann eines von zwei Dingen bedeuten: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-compliance-states.html) In keinem Fall bedeutet dies, dass ein Patch mit diesem Status einen Neustart *erfordert*, sondern nur, dass der Knoten seit der Installation des Patches nicht neu gestartet wurde.  | Nicht konform | 
|  **`INSTALLED_REJECTED`**  |  Der Patch wird auf dem verwalteten Knoten installiert, jedoch in einer Liste der **Rejected patches** (Abgelehnte Patches) angegeben. Dies bedeutet normalerweise, dass der Patch installiert wurde, bevor er einer Liste der abgelehnten Patches hinzugefügt wurde.  | Nicht konform | 
|  **`MISSING`**  |  Der Patch wurde in der Baseline genehmigt, aber nicht auf dem verwalteten Knoten installiert. Wenn Sie die `AWS-RunPatchBaseline`-Dokumentaufgabe zum Scannen (nicht Installieren) konfigurieren, meldet das System diesen Status bei Patches, die beim Scan gefunden wurden, aber noch nicht installiert sind.  | Nicht konform | 
|  **`FAILED`**  |  Der Patch wurde an der Baseline genehmigt, konnte aber nicht installiert werden. Zum Beheben dieses Problems überprüfen Sie die Befehlsausgabe auf Informationen, die Ihnen helfen, das Problem zu verstehen.  | Nicht konform | 

## Patch-Compliance-Werte für andere Betriebssysteme
<a name="patch-compliance-values"></a>

Für alle Betriebssysteme außer Debian Server und Ubuntu Server werden die Regeln für die Paketklassifizierung in verschiedene Compliance-Zustände in der folgenden Tabelle beschrieben. 


|  Patch-Status | Description | Compliancewert | 
| --- | --- | --- | 
|  **`INSTALLED`**  |  Der Patch wird in der Patch-Baseline aufgeführt und ist auf dem verwalteten Knoten installiert. Er könnte entweder manuell von einer Person oder automatisch von Patch Manager installiert worden sein, als das `AWS-RunPatchBaseline`-Dokument auf dem Knoten ausgeführt wurde.  | Konform | 
|  **`INSTALLED_OTHER`**¹  |  Der Patch befindet sich nicht an der Baseline, ist aber auf dem verwalteten Knoten installiert. Hierfür gibt es zwei mögliche Gründe: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-compliance-states.html)  | Konform | 
|  **`INSTALLED_REJECTED`**  |  Der Patch wird auf dem verwalteten Knoten installiert, jedoch in einer Liste der abgelehnten Patches angegeben. Dies bedeutet normalerweise, dass der Patch installiert wurde, bevor er einer Liste der abgelehnten Patches hinzugefügt wurde.  | Nicht konform | 
|  **`INSTALLED_PENDING_REBOOT`**  |  `INSTALLED_PENDING_REBOOT` kann eines von zwei Dingen bedeuten: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-compliance-states.html) In keinem Fall bedeutet dies, dass ein Patch mit diesem Status einen Neustart *erfordert*, sondern nur, dass der Knoten seit der Installation des Patches nicht neu gestartet wurde.  | Nicht konform | 
|  **`MISSING`**  |  Der Patch wurde in der Baseline genehmigt, aber nicht auf dem verwalteten Knoten installiert. Wenn Sie die `AWS-RunPatchBaseline`-Dokumentaufgabe zum Scannen (nicht Installieren) konfigurieren, meldet das System diesen Status bei Patches, die beim Scan gefunden wurden, aber noch nicht installiert sind.  | Nicht konform | 
|  **`FAILED`**  |  Der Patch wurde an der Baseline genehmigt, konnte aber nicht installiert werden. Zum Beheben dieses Problems überprüfen Sie die Befehlsausgabe auf Informationen, die Ihnen helfen, das Problem zu verstehen.  | Nicht konform | 
|  **`NOT_APPLICABLE`**¹  |  *Dieser Compliance-Status wird nur in Windows Server-Betriebssystemen gemeldet.* Der Patch wurde in der Baseline genehmigt, der Service oder dem Feature, die den Patch verwendet, wurde aber auf dem verwalteten Knoten nicht installiert. Beispielsweise würde ein Patch für einen Webserver-Service wie Internet Information Services (IIS) `NOT_APPLICABLE` anzeigen, wenn er in der Baseline genehmigt wurde, der Webservice jedoch nicht auf dem verwalteten Knoten installiert ist. Ein Patch kann auch als `NOT_APPLICABLE` markiert sein, wenn er durch ein nachfolgendes Update ersetzt wurde. Dies bedeutet, dass das spätere Update installiert ist und das `NOT_APPLICABLE`-Update nicht mehr benötigt wird.  | Nicht zutreffend | 
| AVAILABLE\$1SECURITY\$1UPDATES |  *Dieser Compliance-Status wird nur in Windows Server-Betriebssystemen gemeldet.* Ein verfügbarer Sicherheitsupdate-Patch, der nicht von der Patch-Baseline genehmigt wurde, kann den Konformitätswert `Compliant` oder `Non-Compliant` haben, wie in einer benutzerdefinierten Patch-Baseline definiert. Wenn Sie eine Patch-Baseline erstellen oder aktualisieren, wählen Sie den Status, den Sie Sicherheitspatches zuweisen möchten, die zwar verfügbar, aber nicht genehmigt sind, weil sie die in der Patch-Baseline angegebenen Installationskriterien nicht erfüllen. Beispielsweise können Sicherheitspatches, die Sie möglicherweise installieren möchten, übersprungen werden, wenn Sie eine lange Wartezeit für die Installation nach der Veröffentlichung eines Patches angegeben haben. Wenn während der von Ihnen angegebenen Wartezeit ein Update für den Patch veröffentlicht wird, beginnt die Wartezeit für die Installation des Patches von vorne. Wenn die Wartezeit zu lang ist, können mehrere Versionen des Patches veröffentlicht, aber nie installiert werden. Bei der Anzahl der Patch-Zusammenfassungen gilt: Wenn ein Patch als `AvailableSecurityUpdate` gemeldet wird, ist er immer in `AvailableSecurityUpdateCount` enthalten. Wenn die Baseline so konfiguriert ist, dass diese Patches als `NonCompliant` gemeldet werden, ist sie auch in `SecurityNonCompliantCount` enthalten. Wenn die Baseline so konfiguriert ist, dass diese Patches als `Compliant` gemeldet werden, sind sie nicht in `SecurityNonCompliantCount` enthalten. Diese Patches werden immer mit einem nicht spezifizierten Schweregrad gemeldet und sind niemals in `CriticalNonCompliantCount` enthalten.  |  Konform oder nicht konform, je nachdem, welche Option für verfügbare Sicherheitsupdates ausgewählt wurde.  Wenn Sie die Konsole verwenden, um eine Patch-Baseline zu erstellen oder zu aktualisieren, geben Sie diese Option im Feld **Compliance-Status für verfügbare Sicherheitsupdates** an. Mit dem [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html)Befehl AWS CLI to run the [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html)or geben Sie diese Option im `available-security-updates-compliance-status` Parameter an.   | 

¹ Für Patches mit dem Status `INSTALLED_OTHER` und `NOT_APPLICABLE`, lässt Patch Manager einige Daten aus Abfrageergebnissen aus, die auf dem Befehl [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html) basieren, z. B. die Werte für `Classification` und `Severity`. Dies geschieht, um zu verhindern, dass das Datenlimit für einzelne Knoten in Inventory, einem Tool in AWS Systems Manager, überschritten wird. Um alle Patch-Details anzuzeigen, können Sie den Befehl [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html) nutzen. 

# Patchen nicht konformer verwalteter Knoten
<a name="patch-manager-compliance-remediation"></a>

Viele der AWS Systems Manager Tools und Prozesse, mit denen Sie verwaltete Knoten auf Patch-Konformität überprüfen können, können auch verwendet werden, um Knoten an die Patch-Regeln anzupassen, die derzeit für sie gelten. Um verwaltete Knoten in die Patch-Konformität zu bringen AWS Systems Manager, muss ein Tool einen `Scan and install` Vorgang ausführen. Patch Manager (Wenn es Ihr Ziel ist, nicht konforme verwaltete Knoten nur zu identifizieren und sie nicht zu beheben, führen Sie stattdessen eine `Scan`-Operation aus. Weitere Informationen finden Sie unter [Identifizieren von nicht konformen verwalteten Knoten](patch-manager-find-noncompliant-nodes.md).)

**Installieren von Patches mit Systems Manager**  
Sie können aus mehreren Tools wählen, um eine `Scan and install`-Operation auszuführen:
+ (Empfohlen) Konfigurieren Sie eine Patch-Richtlinie in Quick Setup, einem Tool in Systems Manager, mit dem Sie fehlende Patches nach einem Zeitplan für eine gesamte Organisation, eine Teilmenge von Organisationseinheiten oder ein einzelnes AWS-Konto installieren können. Weitere Informationen finden Sie unter [Das Patchen für Instances in einer Organisation mithilfe einer Patch-Richtlinie für Quick Setup konfigurieren](quick-setup-patch-manager.md).
+ Erstellen Sie ein Wartungsfenster, das das Systems Manager-Dokument (SSM-Dokument) `AWS-RunPatchBaseline` in einem Run Command-Aufgabentyp verwendet. Weitere Informationen finden Sie unter [Tutorial: Erstellen Sie ein Wartungsfenster zum Patchen über die Konsole](maintenance-window-tutorial-patching.md).
+ Führen Sie `AWS-RunPatchBaseline` manuell in einer Run Command-Operation aus. Weitere Informationen finden Sie unter [Ausführen von Befehlen über die Konsole](running-commands-console.md).
+ Installieren Sie Patches bei Bedarf mithilfe der Option **Patch now** (Jetzt patchen). Weitere Informationen finden Sie unter [On-Demand-Patchen von verwalteten Knoten](patch-manager-patch-now-on-demand.md).

# Identifizieren der Ausführung, die Patch-Compliance-Daten erstellt hat
<a name="patch-manager-compliance-data-overwrites"></a>

Die Patch-Compliance-Daten stellen eine point-in-time Momentaufnahme des letzten erfolgreichen Patch-Vorgangs dar. Jeder Konformitätsbericht enthält sowohl eine Ausführungs-ID als auch eine Erfassungszeit, anhand derer Sie feststellen können, welcher Vorgang die Konformitätsdaten erstellt hat und wann sie generiert wurden.

Wenn Sie mehrere Arten von Vorgängen zum Scannen Ihrer Instances auf Patch-Compliance haben, überschreibt jeder Scan die Patch-Compliance-Daten vorheriger Scans. Dies kann zu unerwarteten Ergebnissen in Ihren Patch-Compliance-Daten führen.

Nehmen wir an, Sie erstellen eine Patch-Richtlinie, die jeden Tag um 02:00 Uhr Ortszeit auf Patch-Compliance scannt. Diese Patch-Richtlinie verwendet eine Patch-Baseline, die Patches als Ziel haben, deren Schweregrad mit `Critical`, `Important` und `Moderate` gekennzeichnet ist. Diese Patch-Baseline gibt auch einige speziell abgelehnte Patches an. 

Nehmen Sie außerdem an, dass Sie bereits ein Wartungsfenster eingerichtet haben, um jeden Tag um 04:00 Uhr Ortszeit denselben Satz verwalteter Knoten zu scannen, die Sie nicht löschen oder deaktivieren. Die Aufgabe dieses Wartungsfensters verwendet eine andere Patch-Baseline, eine, die nur Patches mit dem Schweregrad `Critical` als Ziel hat und keine bestimmten Patches ausschließt. 

Wenn dieser zweite Scan vom Wartungsfenster durchgeführt wird, werden die Patch-Compliance-Daten des ersten Scans gelöscht und durch die Patch-Compliance des zweiten Scans ersetzt. 

Daher empfehlen wir dringend, nur eine automatisierte Methode zum Scannen und Installieren in Ihren Patching-Vorgängen zu verwenden. Wenn Sie Patch-Richtlinien einrichten, sollten Sie andere Methoden zum Scannen auf Patch-Compliance löschen oder deaktivieren. Weitere Informationen finden Sie unter den folgenden Themen: 
+ So entfernen Sie eine Patching-Aufgabe aus einem Wartungsfenster – [Aktualisieren oder Abmelden von Wartungsfenster-Aufgaben mithilfe der Konsole](sysman-maintenance-update.md#sysman-maintenance-update-tasks) 
+ So löschen Sie eine State Manager-Zuordnung – [Löschen von Zuordnungen](systems-manager-state-manager-delete-association.md).

Um tägliche Patch-Compliance-Scans in einer Host-Verwaltungskonfiguration zu deaktivieren, gehen Sie in Quick Setup wie folgt vor:

1. Wählen Sie im Navigationsbereich **Quick Setup** aus.

1. Wählen Sie die zu aktualisierende Host-Management-Konfiguration aus.

1. Wählen Sie **Actions, Edit configuration** (Aktionen, Konfiguration bearbeiten) aus.

1. Deaktivieren Sie das Kontrollkästchen **Scan instances for missing patches daily** (Instances täglich auf fehlende Patches scannen).

1. Wählen Sie **Aktualisieren** aus.

**Anmerkung**  
Die Verwendung von **Patch now** (Jetzt patchen) zum Überprüfen eines verwalteten Knotens auf Compliance führt auch zu einem Überschreiben von Patch-Compliance-Daten. 

# On-Demand-Patchen von verwalteten Knoten
<a name="patch-manager-patch-now-on-demand"></a>

Verwenden Sie die Option **Jetzt patchen** in Patch Manager, einem Tool in AWS Systems Manager, um Patching-Vorgänge auf Abruf über die Systems-Manager-Konsole auszuführen. Dies bedeutet, dass Sie keinen Zeitplan erstellen müssen, um den Compliance-Status Ihrer verwalteten Knoten zu aktualisieren oder Patches auf nicht kompatiblen Knoten zu installieren. Sie müssen die Systems Manager Manager-Konsole auch nicht zwischen Patch Manager undMaintenance Windows, einem Tool in AWS Systems Manager, umschalten, um ein geplantes Patch-Fenster einzurichten oder zu ändern.

**Patch now** (Jetzt patchen) ist besonders nützlich, wenn Sie so schnell wie möglich Zero-Day-Updates anwenden oder andere kritische Patches auf Ihren verwalteten Knoten installieren müssen.

**Anmerkung**  
Patching auf Abruf wird jeweils für ein AWS-Konto einzelnes AWS-Region Paar unterstützt. Es kann nicht mit Patching-Vorgängen verwendet werden, die auf *Patch-Richtlinien* basieren. Wir empfehlen die Verwendung von Patch-Richtlinien, um sicherzustellen, dass alle Ihre verwalteten Knoten die Compliance einhalten. Weitere Informationen zur Arbeit mit Patch-Richtlinien finden Sie unter [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md).

**Topics**
+ [So funktioniert „Patch now“ (Jetzt patchen)](#patch-on-demand-how-it-works)
+ [Ausführen von „Patch now“ (Jetzt patchen)](#run-patch-now)

## So funktioniert „Patch now“ (Jetzt patchen)
<a name="patch-on-demand-how-it-works"></a>

Um **Patch now** (Jetzt patchen) auszuführen, müssen Sie nur zwei erforderliche Einstellungen angeben:
+ Ob nur nach fehlenden Patches gescannt werden soll oder ob Patches auf Ihren verwalteten Knoten gescannt *und* installiert werden sollen
+ Auf welchen verwalteten Knoten die Operation ausgeführt werden soll

Wenn die Operation **Patch now** (Jetzt patchen) läuft, bestimmt sie, welche Patch-Baseline auf die gleiche Weise verwendet werden soll, wie eine für andere Patching-Operationen ausgewählt wird. Wenn ein verwalteter Knoten einer Patch-Gruppe zugeordnet ist, wird die für diese Gruppe angegebene Patch-Baseline verwendet. Wenn der verwaltete Knoten nicht einer Patch-Gruppe zugeordnet ist, verwendet die Operation die Patch-Baseline, die derzeit als Standard für den Betriebssystemtyp des verwalteten Knotens festgelegt ist. Dabei kann es sich um eine vordefinierte Baseline oder um die benutzerdefinierte Baseline handeln, die Sie als Standard festgelegt haben. Weitere Informationen zur Patch-Baseline-Auswahl finden Sie unter [Patch-Gruppen](patch-manager-patch-groups.md). 

Zu den Optionen, die Sie für **Patch now** (Jetzt patchen) angeben können, gehört, ob verwaltete Knoten nach dem Patchen neu gestartet werden sollen, indem Sie einen Amazon Simple Storage Service (Amazon S3)-Bucket zum Speichern von Protokolldaten für den Patchvorgang angeben und Systems-Manager-Dokumente (SSM-Dokumente) als Lebenszyklus-Hooks während des Patchings ausführen.

### Parallelitäts- und Fehlerschwellenwerte für „Patch now“ (Jetzt patchen)
<a name="patch-on-demand-concurrency"></a>

Für **Patch now**-Operationen (Jetzt patchen) werden Optionen für Parallelitäts- und Fehlerschwellen von Patch Manager gehandhabt. Sie müssen weder angeben, wie viele verwaltete Knoten gleichzeitig gepatcht werden sollen, noch wie viele Fehler zulässig sind, bevor die Operation fehlschlägt. Patch Manager wendet die Einstellungen für Parallelitäts- und Fehlerschwellenwert an, die in den folgenden Tabellen beschrieben werden, wenn Sie On-Demand-Patches anwenden.

**Wichtig**  
Die folgenden Schwellenwerte gelten für nur für `Scan and install`-Operationen. Für `Scan`-Operationen versucht Patch Manager bis zu 1.000 Knoten gleichzeitig zu scannen und weiter zu scannen, bis bis zu 1.000 Fehler aufgetreten sind.


**Gleichzeitigkeit: Installationsvorgänge**  

| Die Gesamtanzahl von verwalteten Knoten in der Operation **Patch now** (Jetzt patchen) | Anzahl der gleichzeitig gescannten oder gepatchten verwalteten Knoten | 
| --- | --- | 
| Weniger als 25 | 1 | 
| 25–100 | 5 % | 
| 101 bis 1.000 | 8% | 
| Mehr als 1.000 | 10 % | 


**Fehlerschwellenwert: Installationsvorgänge**  

| Die Gesamtanzahl von verwalteten Knoten in der Operation **Patch now** (Jetzt patchen) | Anzahl der zulässigen Fehler, bevor der Vorgang fehlschlägt | 
| --- | --- | 
| Weniger als 25 | 1 | 
| 25–100 | 5 | 
| 101 bis 1.000 | 10 | 
| Mehr als 1.000 | 10 | 

### Verwenden von „Patch now“ (Jetzt patchen)-Lebenszyklus-Hooks
<a name="patch-on-demand-hooks"></a>

**Patch now** (Jetzt patchen) bietet Ihnen die Möglichkeit, SSM Command-Dokumente als Lebenszyklus-Hooks während eines `Install`-Patch-Vorgang auszuführen. Sie können diese Hooks für Aufgaben wie das Herunterfahren von Anwendungen vor dem Patchen oder Ausführen von Zustandsprüfungen für Ihre Anwendungen nach dem Patchen oder nach einem Neustart verwenden. 

Weitere Informationen über das Verwenden von Lebenszyklus-Hooks finden Sie unter [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md).

In der folgenden Tabelle werden die Lebenszyklus-Hooks aufgeführt, die für jede der drei **Patch now**-Neustartoptionen (Jetzt patchen) aufgelistet sowie Beispielanwendungen für jeden Hook.


**Lebenszyklus-Hooks und Beispielanwendungen**  

| Neustartoption | Hook: Vor Installation | Hook: Nach Installation | Hook: Beim Verlassen | Hook: Nach geplantem Neustart | 
| --- | --- | --- | --- | --- | 
| Bei Bedarf neu starten |  Führen Sie ein SSM-Dokument aus, bevor das Patchen beginnt. Anwendungsbeispiel: Fahren Sie Anwendungen sicher herunter, bevor der Patchvorgang beginnt.   |  Führen Sie ein SSM-Dokument am Ende der Patching-Operation und vor dem Neustart des verwalteten Knoten aus. Anwendungsbeispiel: Führen Sie Vorgänge wie die Installation von Drittanbieter-Anwendungen vor einem potenziellen Neustart aus.  |  Führen Sie ein SSM-Dokument aus, nachdem die Patching-Operation abgeschlossen und die Instances neu gestartet wurden. Anwendungsbeispiel: Stellen Sie sicher, dass Anwendungen nach dem Patchen wie erwartet ausgeführt werden.  | Nicht verfügbar | 
| Meine Instances nicht neu starten | Wie oben. |  Führen Sie ein SSM-Dokument am Ende des Patching-Vorgangs aus. Anwendungsbeispiel: Stellen Sie sicher, dass Anwendungen nach dem Patchen wie erwartet ausgeführt werden.  |  *Nicht verfügbar*   |  *Nicht verfügbar*   | 
| Neustartzeit planen | Wie oben. | Dasselbe wie für Meine Instances nicht neu starten. | Nicht verfügbar |  Führen Sie sofort nach Abschluss eines geplanten Neustarts ein SSM-Dokument aus. Anwendungsbeispiel: Stellen Sie sicher, dass Anwendungen nach dem Neustart wie erwartet ausgeführt werden.  | 

## Ausführen von „Patch now“ (Jetzt patchen)
<a name="run-patch-now"></a>

Mit dem folgenden Verfahren können Sie On-Demand-Patches auf Ihre verwalteten Knoten anwenden.

**So führen Sie „Patch now“ (Jetzt patchen) aus**

1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Wählen Sie im Navigationsbereich **Patch Manager** aus.

1. Wählen Sie **Patch now** (Jetzt patchen) aus.

1. Für **Patch-Operation** wählen Sie eine der folgenden Optionen aus:
   + **Scan** (Scannen): Patch Manager findet die Patches, die in Ihren verwalteten Knoten fehlen, installiert sie aber nicht. Sie können die Ergebnisse im **Compliance**-Dashboard oder in anderen Tools, die Sie zum Anzeigen der Patch-Compliance verwenden, anzeigen.
   + **Scan and install** (Scannen und installieren): Patch Manager findet die Patches, die in Ihren verwalteten Knoten fehlen, und installiert sie.

1. Führen Sie diesen Schritt nur aus, wenn Sie im vorherigen Schritt **Scan und Installation** ausgewählt haben. Wählen Sie bei **Neustartoption** eine der folgenden Optionen aus:
   + **Reboot if needed** (Bei Bedarf neu starten): Nach der Installation startet Patch Manager verwaltete Knoten nur dann neu, wenn dies zum Abschluss einer Patch-Installation erforderlich ist.
   + **Don‘t reboot my instances** (Meine Instances nicht neu starten): Nach der Installation startet Patch Manager verwaltete Knoten nicht neu. Sie können verwaltete Knoten manuell neu starten, wenn Sie Neustarts außerhalb von Patch Manager auswählen oder verwalten.
   + **Schedule a reboot time** (Neustartzeit planen): Geben Sie das Datum, die Uhrzeit und die UTC-Zeitzone an, wenn Patch Manager Ihre verwalteten Knoten neu starten sollen. Nachdem Sie den **Patch now** (Jetzt patchen)-Vorgang ausgeführt haben, wird der geplante Neustart als Zuordnung in State Manager mit dem Namen `AWS-PatchRebootAssociation` gelistet.
**Wichtig**  
Wenn Sie den Hauptpatchvorgang abbrechen, nachdem er gestartet wurde, State Manager wird die `AWS-PatchRebootAssociation` Zuordnung NICHT automatisch abgebrochen. Um unerwartete Neustarts zu verhindern, müssen Sie manuell `AWS-PatchRebootAssociation` löschen, State Manager falls der geplante Neustart nicht mehr stattfinden soll. Andernfalls kann es zu ungeplanten Systemneustarts kommen, die sich auf die Produktionsauslastung auswirken können. Sie finden diese Zuordnung in der Systems Manager Manager-Konsole unter **State Manager**> **Verknüpfungen**.

1. Wählen Sie unter **Instances to patch (Zu patchende Instances)** eine der folgenden Optionen aus:
   + **Alle Instanzen patchen**: Patch Manager Führt den angegebenen Vorgang auf allen verwalteten Knoten AWS-Konto in Ihrer aktuellen Version aus AWS-Region.
   + **Patch only the target instances I specify** (Nur die von mir angegebenen Ziel-Instances patchen): Sie geben im nächsten Schritt an, welche verwalteten Knoten anvisiert werden sollen.

1. Führen Sie diesen Schritt nur aus, wenn Sie im vorherigen Schritt **Nur die von mir angegebenen Ziel-Instances patchen** ausgewählt haben. Identifizieren Sie für den Abschnitt **Target selection** (Zielauswahl) die Knoten, auf denen Sie diese Operation ausführen möchten, indem Sie Tags angeben, Knoten manuell auswählen oder eine Ressourcengruppe angeben.
**Anmerkung**  
Wenn ein verwalteter Knoten, den Sie erwarten, nicht aufgeführt ist, finden Sie weitere Informationen unter [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md) Tipps zur Fehlerbehebung.  
Wenn Sie sich für eine Ressourcengruppe entscheiden, beachten Sie, dass Ressourcengruppen, die auf einem AWS CloudFormation Stack basieren, trotzdem mit dem `aws:cloudformation:stack-id` Standard-Tag gekennzeichnet werden müssen. Wenn es entfernt wurde, kann Patch Manager möglicherweise nicht ermitteln, welche verwalteten Knoten zur Ressourcengruppe gehören.

1. (Optional) Für **Patch-Protokollspeicher** wählen Sie, wenn Sie Protokolle aus diesem Patchvorgang erstellen und speichern möchten, den S3-Bucket zum Speichern der Protokolle aus.
**Anmerkung**  
Die S3-Berechtigungen zum Schreiben von Daten in einen S3-Bucket sind diejenigen des Instance-Profils (für EC2-Instances) oder der IAM-Servicerolle (hybrid-aktivierte Maschinen), die der Instance zugewiesen sind, und nicht diejenigen des IAM-Benutzers, der diese Aufgabe ausführt. Weitere Informationen finden Sie unter [Die für Systems Manager erforderlichen Instance-Berechtigungen konfigurieren](setup-instance-permissions.md) oder [Die für Systems Manager erforderliche IAM-Servicerolle in Hybrid- und Multi-Cloud-Umgebungen erstellen](hybrid-multicloud-service-role.md). Wenn sich der angegebene S3-Bucket in einem anderen befindet, stellen Sie außerdem sicher AWS-Konto, dass das Instanzprofil oder die IAM-Dienstrolle, die dem verwalteten Knoten zugeordnet sind, über die erforderlichen Berechtigungen verfügt, um in diesen Bucket zu schreiben.

1. (Optional) Wenn Sie SSM-Dokumente als Lebenszyklus-Hooks an bestimmten Punkten des Patching-Vorgangs ausführen möchten, gehen Sie wie folgt vor:
   + Klicken Sie auf **Verwenden von Lebenszyklus-Hooks**.
   + Wählen Sie für jeden verfügbaren Hook das SSM-Dokument aus, das am angegebenen Punkt des Vorgangs ausgeführt werden soll:
     + Vor Installation
     + Nach Installation
     + Beim Verlassen
     + Nach geplantem Neustart
**Anmerkung**  
Das Standarddokument, `AWS-Noop`, führt keine Vorgänge aus.

1. Wählen Sie **Patch now** (Jetzt patchen) aus.

   Die Seite **Association execution summary (Zusammenfassung der Zuordnungsausführung)** wird geöffnet. (Jetzt patchen verwendet jetzt Zuordnungen in State Manager, einem Tool in AWS Systems Manager, für seine Vorgänge.) Im Bereich **Operation summary** (Operationsübersicht) können Sie den Scan- oder Patch-Status auf den von Ihnen angegebenen verwalteten Knoten überwachen.

# Arbeiten mit Patch-Baselines
<a name="patch-manager-create-a-patch-baseline"></a>

Eine Patch-Baseline in Patch Manager, einem Tool in AWS Systems Manager, definiert, welche Patches für die Installation in Ihren verwalteten Knoten genehmigt sind. Sie können für Patches einzeln angeben, ob sie genehmigt oder abgelehnt werden. Sie können auch automatische Genehmigungsregeln erstellen, um festzulegen, dass bestimmte Arten von Updates (z. B. wichtige Updates), automatisch genehmigt werden. Die Liste mit den Ablehnungen setzt sowohl die Regeln als auch die Liste mit Genehmigungen außer Kraft. Wenn Sie ausschließlich eine Liste mit genehmigten Patches verwenden möchten, um spezifische Pakete zu installieren, entfernen Sie erst alle automatischen Genehmigungsregeln. Wenn Sie explizit einen Patch als abgelehnt kennzeichnen, wird er nicht genehmigt oder installiert, selbst wenn er mit allen Kriterien in einer automatischen Genehmigungsregel übereinstimmt. Außerdem wird ein Patch nur dann auf einem verwalteten Knoten installiert, wenn er für die Software auf dem Knoten geeignet ist, auch wenn der Patch anderweitig für den verwalteten Knoten genehmigt wurde.

**Topics**
+ [AWS Vordefinierte Patch-Baselines anzeigen](patch-manager-view-predefined-patch-baselines.md)
+ [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md)
+ [Festlegen einer vorhandenen Patch-Baseline als Standard](patch-manager-default-patch-baseline.md)

**Weitere Informationen**  
+ [Patch-Baselines](patch-manager-patch-baselines.md)

# AWS Vordefinierte Patch-Baselines anzeigen
<a name="patch-manager-view-predefined-patch-baselines"></a>

Patch Manager, ein Tool in AWS Systems Manager, enthält eine vordefinierte Patch-Baseline für jedes Betriebssystem, das von unterstützt wird. Patch Manager Sie können diese Patch-Baselines verwenden (Sie können sie jedoch nicht anpassen) oder Sie können eine eigene Patch-Baseline erstellen. Nachfolgend wird beschrieben, wie Sie eine vordefinierte Patch-Baseline anzeigen, um sie auf Ihre Anforderungen hin zu überprüfen. Weitere Informationen zu Patch-Baselines finden Sie unter [Vordefinierte und benutzerdefinierte Patch-Baselines](patch-manager-predefined-and-custom-patch-baselines.md).

**So zeigen Sie AWS vordefinierte Patch-Baselines an**

1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)

1. Wählen Sie im Navigationsbereich **Patch Manager** aus.

1. Wählen Sie in der Liste der Patch-Baselines die Baseline-ID einer der vordefinierten Patch-Baselines aus.

   –oder–

   Wenn Sie in der aktuellen AWS-Region zum ersten Mal auf Patch Manager zugreifen, wählen Sie **Mit einer Übersicht beginnen**, wählen Sie die Registerkarte **Patch-Baselines** und wählen Sie dann die Baseline-ID einer der vordefinierten Patch-Baselines.
**Anmerkung**  
Für Windows Server werden drei vordefinierte Patch-Baselines bereitgestellt. Die Patch-Baselines `AWS-DefaultPatchBaseline` und `AWS-WindowsPredefinedPatchBaseline-OS` unterstützen nur Betriebssystemupdates auf dem Windows-Betriebssystem selbst. `AWS-DefaultPatchBaseline` wird als Standard-Patch-Baseline für von Windows Server verwalteten Knoten verwendet, es sei denn, Sie geben eine andere Patch-Baseline an. Die Konfigurationseinstellungen in diesen beiden Patch-Baselines sind identisch. Die neuere der beiden, `AWS-WindowsPredefinedPatchBaseline-OS`, wurde erstellt, um sie von der dritten vordefinierten Patch-Baseline für Windows Server zu unterscheiden. Diese Patch-Baseline, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, kann verwendet werden, um Patches sowohl auf das Windows Server-Betriebssystem als auch auf unterstützte Anwendungen, die von Microsoft veröffentlicht wurden, anzuwenden.  
Weitere Informationen finden Sie unter [Festlegen einer vorhandenen Patch-Baseline als Standard](patch-manager-default-patch-baseline.md).

1. Im Abschnitt **Genehmigungsregel**n überprüfen Sie die Konfiguration der Patch-Baseline-Konfiguration.

1. Wenn die Konfiguration für Ihre verwalteten Knoten geeignet ist, können Sie direkt mit dem Verfahren [Erstellen und Verwalten von Patch-Gruppen](patch-manager-tag-a-patch-group.md) fortfahren. 

   –oder–

   Fahren Sie zum Erstellen einer eigenen Standard-Patch-Baseline mit dem Thema [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md) fort.

# Arbeiten mit benutzerdefinierten Patch-Baselines
<a name="patch-manager-manage-patch-baselines"></a>

Patch Manager, ein Tool in AWS Systems Manager, enthält eine vordefinierte Patch-Baseline für jedes Betriebssystem, das von unterstützt wirdPatch Manager. Sie können diese Patch-Baselines verwenden (Sie können sie jedoch nicht anpassen) oder Sie können eine eigene Patch-Baseline erstellen. 

In den folgenden Verfahren wird beschrieben, wie Sie eigene benutzerdefinierte Patch-Baselines erstellen, aktualisieren und löschen. Weitere Informationen zu Patch-Baselines finden Sie unter [Vordefinierte und benutzerdefinierte Patch-Baselines](patch-manager-predefined-and-custom-patch-baselines.md).

**Topics**
+ [So erstellen Sie eine benutzerdefinierte Patch-Baseline für Linux](patch-manager-create-a-patch-baseline-for-linux.md)
+ [Erstellen einer benutzerdefinierten Patch-Baseline für macOS](patch-manager-create-a-patch-baseline-for-macos.md)
+ [Erstellen einer benutzerdefinierten Patch-Baseline für Windows Server](patch-manager-create-a-patch-baseline-for-windows.md)
+ [Aktualisieren oder Löschen einer benutzerdefinierten Patch-Baseline](patch-manager-update-or-delete-a-patch-baseline.md)

# So erstellen Sie eine benutzerdefinierte Patch-Baseline für Linux
<a name="patch-manager-create-a-patch-baseline-for-linux"></a>

Verwenden Sie das folgende Verfahren, um eine benutzerdefinierte Patch-Baseline für Linux-verwaltete Knoten in Patch Manager, einem Tool in AWS Systems Manager, zu erstellen. 

Informationen zum Erstellen einer Patch-Baseline für macOS-verwaltete Knoten finden Sie unter [Erstellen einer benutzerdefinierten Patch-Baseline für macOS](patch-manager-create-a-patch-baseline-for-macos.md). Informationen zum Erstellen einer Patch-Baseline für Windows-verwaltete Knoten finden Sie unter [Erstellen einer benutzerdefinierten Patch-Baseline für Windows Server](patch-manager-create-a-patch-baseline-for-windows.md).

**So erstellen Sie eine benutzerdefinierte Patch-Baseline für Linux-verwaltete Knoten**

1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Wählen Sie im Navigationsbereich **Patch Manager** aus.

1. Wählen Sie die Registerkarte **Patch-Baselines** und dann **Patch-Baseline erstellen** aus.

   –oder–

   Wenn Sie in der aktuellen AWS-Region zum ersten Mal auf Patch Manager zugreifen, wählen Sie **Mit einer Übersicht beginnen**, wechseln Sie zur Registerkarte **Patch-Baselines** und wählen Sie dann **Patch-Baseline** erstellen.

1. Geben Sie im Feld **Name** einen Namen für die neue Patch-Baseline ein, z. B. `MyRHELPatchBaseline`.

1. (Optional) Geben Sie im Feld **Beschreibung** eine Beschreibung für diese Patch-Baseline ein.

1. Wählen Sie unter **Operating system (Betriebssystem)** ein Betriebssystem aus, z. B. `Red Hat Enterprise Linux`.

1. Wenn Sie diese Patch-Baseline sofort nach der Erstellung als Standard für das ausgewählte Betriebssystem verwenden möchten, aktivieren Sie das Kontrollkästchen neben **Diese Patch-Baseline als Standard-Patch-Baseline für *operating system name* Instances festlegen**.
**Anmerkung**  
Diese Option ist nur verfügbar, wenn Sie vor der Veröffentlichung der [Patch-Richtlinien](patch-manager-policies.md) am 22. Dezember 2022 zum ersten Mal auf Patch Manager zugegriffen haben.  
Weitere Informationen zum Festlegen einer vorhandenen Patch-Baseline als Standard finden Sie unter [Festlegen einer vorhandenen Patch-Baseline als Standard](patch-manager-default-patch-baseline.md).

1. Erstellen Sie im Abschnitt **Genehmigungsregeln für Betriebssysteme** unter Verwendung der Felder ein oder mehrere automatische Genehmigungsregeln.
   + **Produkte**: Die Version der Betriebssysteme, auf die sich die Genehmigungsregel bezieht, z. B. `RedhatEnterpriseLinux7.4`. Die Standardauswahl ist `All`.
   + **Classification (Klassifizierung)**: Der Typ der Patches, auf die sich die Genehmigungsregel bezieht, z. B. `Security` oder `Enhancement`. Die Standardauswahl ist `All`. 
**Tipp**  
Sie können eine Patch-Baseline konfigurieren, um zu steuern, ob Nebenversions-Upgrades für Linux installiert werden, z. B. RHEL 7.8. Nebenversionsupgrades können vom Patch Manager automatisch installiert werden, wenn das Update im entsprechenden Repository verfügbar ist.  
Im Fall von Linux-Betriebssystemen werden Nebenversionsupgrades nicht konsistent klassifiziert. Sie können als Fehlerbehebungen oder Sicherheitsupdates klassifiziert (oder nicht klassifiziert) werden, selbst innerhalb derselben Kernel-Version. Im Folgenden werden einige Optionen aufgelistet, mit denen Sie steuern können, ob sie von einer Patch-Baseline installiert werden.   
**Option 1**: Die umfassendste Genehmigungsregel, die sicherzustellt, dass Nebenversionsupgrades installiert werden, wenn verfügbar, besteht in der Angabe von **Classification (Klassifizierung)** als `All` (\$1) und der Auswahl der Option **Include nonsecurity updates (Auch andere Updates als Sicherheitsupdates einschließen)**.
**Option 2**: Um die Installation von Patches für eine Betriebssystemversion sicherzustellen, können Sie ein Platzhalterzeichen (\$1) verwenden, um das Kernel-Format im Abschnitt **Patch exceptions (Patch-Ausnahmen)** der Baseline anzugeben. Zum Beispiel ist das Kernel-Format für RHEL 7.\$1 `kernel-3.10.0-*.el7.x86_64`.  
Geben Sie `kernel-3.10.0-*.el7.x86_64` in der Liste **Approved patches** (Genehmigte Patches) in Ihrer Patch-Baseline ein, um die Anwendung aller Patches einschließlich Nebenversionsupgrades auf Ihren von RHEL 7.\$1 verwalteten Knoten sicherzustellen. (Wenn Sie den genauen Paketnamen eines Nebenversionspatches kennen, können Sie diesen stattdessen eingeben.)
**Option 3**: Mithilfe des [InstallOverrideList](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)Parameters im `AWS-RunPatchBaseline` Dokument haben Sie die größtmögliche Kontrolle darüber, welche Patches auf Ihre verwalteten Knoten angewendet werden, einschließlich kleinerer Versions-Upgrades. Weitere Informationen finden Sie unter [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
   + **Schweregrad**: Der Schweregradwert von Patches, auf den die Regel anzuwenden ist, z. B. `Critical`. Die Standardauswahl ist `All`. 
   + **Automatische Genehmigung**: Die Methode zum Auswählen von Patches für die automatische Genehmigung.
**Anmerkung**  
Da es nicht möglich ist, die Veröffentlichungsdaten von Updatepaketen für Ubuntu Server zuverlässig zu bestimmen, werden die Optionen für die automatische Genehmigung für dieses Betriebssystem nicht unterstützt.
     + **Approve patches after a specified number of days** (Patches nach einer bestimmten Anzahl von Tagen genehmigen): Die Anzahl der Tage, die der Patch Manager warten muss, nachdem ein Patch veröffentlicht oder zuletzt aktualisiert wurde, bevor ein Patch automatisch genehmigt wird. Sie können jede Ganzzahl von Null (0) bis 360 eingeben. Für die meisten Szenarien empfehlen wir, nicht länger als 100 Tage zu warten.
     + **Patches genehmigen, die bis zu einem bestimmten Datum veröffentlicht wurden**: Das Datum der Patch-Veröffentlichung, an dem der Patch Manager automatisch alle Patches anwendet, die bis zu diesem Datum veröffentlicht oder aktualisiert wurden. Wenn Sie beispielsweise den 7. Juli 2023 angeben, werden Patches, die am oder nach dem 8. Juli 2023 veröffentlicht oder zuletzt aktualisiert wurden, nicht automatisch installiert.
   + (Optional) **Konformitätsbericht **: Der Schweregrad, den Sie Patches zuweisen möchten, die von der Baseline genehmigt wurden (z. B. `Critical` oder `High`).
**Anmerkung**  
Wenn Sie eine Konformitätsberichtsstufe angeben und der Patch-Status eines genehmigten Patches als `Missing` gemeldet wird, dann entspricht der insgesamt gemeldete Konformitätsschweregrad der Patch-Baseline dem von Ihnen angegebenen Schweregrad.
   + **Include non-security updates (Nicht sicherheitsrelevante Updates einbeziehen)**: Aktivieren Sie das Kontrollkästchen zum Installieren von nicht sicherheitsrelevanten Linux-Betriebssystem-Patches, die im Quell-Repository verfügbar gemacht wurden, zusätzlich zu den sicherheitsrelevanten Patches. 

   Weitere Informationen zum Arbeiten mit Genehmigungsregeln in einer benutzerdefinierten Patch-Baseline finden Sie unter [Benutzerdefinierte Baselines](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom).

1. Wenn Sie zusätzlich zu den Patches, die Ihren Genehmigungsregeln entsprechen, alle Patches ausdrücklich genehmigen möchten, gehen Sie im Abschnitt **Patch-Ausnahmen** wie folgt vor:
   + Geben Sie im Feld **Genehmigte Patches** eine durch Komma getrennte Liste der Patches ein, die Sie genehmigen möchten.

     Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
   + (Optional) Weisen Sie in der Liste **Compliance-Stufe genehmigter Patches** den Patches in der Liste eine Compliance-Stufe zu.
   + Wenn genehmigte Patches, die Sie angeben, nicht sicherheitsbezogen sind, wählen Sie das Kästchen **Genehmigte Patches umfassen nicht sicherheitsrelevante Updates** aus, damit diese Patches ebenfalls auf Ihrem Linux-Betriebssystem installiert werden.

1. Wenn Sie Patches ablehnen möchten, die ansonsten Ihren Genehmigungsregeln entsprechen, gehen Sie im Abschnitt **Patch-Ausnahmen** wie folgt vor:
   + Geben Sie im Feld **Abgelehnte Patches** eine durch Komma getrennte Liste der Patches ein, die Sie ablehnen möchten.

     Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
   + Wählen Sie in der Liste **Aktion für abgelehnte Patches** die Aktion aus, die Patch Manager für Patches in der Liste **Abgelehnte Patches** ausführen soll.
     + **Als Abhängigkeit zulassen**: Ein Paket in der Liste **Abgelehnte Patches** wird nur installiert, wenn es sich um eine Abhängigkeit eines anderen Pakets handelt. Es gilt als konform mit der Patch-Baseline und sein Status wird als gemeldet *InstalledOther*. Dies ist die Standardaktion, wenn keine Option ausgewählt ist.
     + **Blockieren**: Pakete in der Liste **Abgelehnte Patches** und Pakete, die diese als Abhängigkeiten enthalten, werden unter keinen Umständen von Patch Manager installiert. Wenn ein Paket installiert wurde, bevor es zur Liste der **abgelehnten Patches** hinzugefügt wurde, oder danach außerhalb von Patch Manager installiert wird, gilt es als nicht konform mit der Patch-Baseline und sein Status wird als *InstalledRejected* gemeldet.
**Anmerkung**  
Patch Manager sucht rekursiv nach Patch-Abhängigkeiten.

1. **(Optional) Wenn Sie alternative Patch-Repositorys für verschiedene Versionen eines Betriebssystems angeben möchten, z. B. *AmazonLinux2016.03 und *AmazonLinux2017.09**, gehen Sie für jedes Produkt im Abschnitt Patch-Quellen wie folgt vor:**
   + Geben Sie in **Name (Name)** einen Namen ein, um Sie bei der Identifizierung der Quellkonfiguration zu unterstützen.
   + Wählen Sie unter **Product (Produkt)** die Version der Betriebssysteme aus, für die das Patch-Quell-Repository bestimmt ist, z. B. `RedhatEnterpriseLinux7.4`.
   + Geben Sie unter **Konfiguration** den Wert der zu verwendenden Repository-Konfiguration im entsprechenden Format ein:

------
#### [  Example for yum repositories  ]

     ```
     [main]
     name=MyCustomRepository
     baseurl=https://my-custom-repository
     enabled=1
     ```

**Tipp**  
Informationen zu anderen Optionen für Ihre Yum-Repository-Konfiguration finden Sie unter [dnf.conf (5)](https://man7.org/linux/man-pages/man5/dnf.conf.5.html).

------
#### [  Examples for Ubuntu Server and Debian Server ]

      `deb http://security.ubuntu.com/ubuntu jammy main` 

      `deb https://site.example.com/debian distribution component1 component2 component3` 

     Repository-Informationen für Ubuntu Server-Repositorys müssen in einer einzigen Zeile angegeben werden. Weitere Beispiele und Informationen finden Sie unter [jammy (5) sources.list.5.gz](https://manpages.ubuntu.com/manpages/jammy/man5/sources.list.5.html) auf der Website *Ubuntu Server Manuals* und unter [sources.list-Format](https://wiki.debian.org/SourcesList#sources.list_format) im *Debian-Wiki*.

------

     Wählen Sie **Add another source** aus, um ein Quell-Repository für jede zusätzliche Betriebssystemversion anzugeben, bis maximal 20.

     Weitere Informationen über alternative Quell-Patch-Repositorys finden Sie unter [So geben Sie ein alternatives Patch-Quell-Repository an (Linux)](patch-manager-alternative-source-repository.md).

1. (Optional) Wenden Sie unter **Tags verwalten** ein oder mehrere name/value Tag-Schlüsselpaare auf die Patch-Baseline an.

   Tags sind optionale Metadaten, die Sie einer Ressource zuweisen. Mithilfe von Tags können Sie eine Ressource unterschiedlich kategorisieren, beispielsweise nach Zweck, Besitzer oder Umgebung. Sie können beispielsweise eine Patch-Baseline kennzeichnen, um den Schweregrad der angegebenen Patches, die Betriebssystemfamilie, auf die sie sich bezieht, und den Umgebungstyp zu identifizieren. In diesem Fall könnten Sie Tags angeben, die den folgenden name/value Schlüsselpaaren ähneln:
   + `Key=PatchSeverity,Value=Critical`
   + `Key=OS,Value=RHEL`
   + `Key=Environment,Value=Production`

1. Wählen Sie die Option **Patch-Baseline erstellen**.

# Erstellen einer benutzerdefinierten Patch-Baseline für macOS
<a name="patch-manager-create-a-patch-baseline-for-macos"></a>

Verwenden Sie das folgende Verfahren, um eine benutzerdefinierte Patch-Baseline für macOS-verwaltete Knoten in Patch Manager zu erstellen, einem Tool in AWS Systems Manager. 

Informationen zum Erstellen einer Patch-Baseline für Windows Server-verwaltete Knoten finden Sie unter [Erstellen einer benutzerdefinierten Patch-Baseline für Windows Server](patch-manager-create-a-patch-baseline-for-windows.md). Informationen zum Erstellen einer Patch-Baseline für Linux-verwaltete Knoten finden Sie unter [So erstellen Sie eine benutzerdefinierte Patch-Baseline für Linux](patch-manager-create-a-patch-baseline-for-linux.md). 

**Anmerkung**  
macOSwird nicht in allen unterstützt AWS-Regionen. Weitere Informationen zur Amazon-EC2-Unterstützung für macOS finden Sie unter [Amazon-EC2-Mac-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html) im *Amazon-EC2-Benutzerhandbuch*.

**So erstellen Sie eine benutzerdefinierte Patch-Baseline für macOS-verwaltete Knoten**

1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Wählen Sie im Navigationsbereich **Patch Manager** aus.

1. Wählen Sie die Registerkarte **Patch-Baselines** und dann **Patch-Baseline erstellen** aus.

   –oder–

   Wenn Sie in der aktuellen AWS-Region zum ersten Mal auf Patch Manager zugreifen, wählen Sie **Mit einer Übersicht beginnen**, wechseln Sie zur Registerkarte **Patch-Baselines** und wählen Sie dann **Patch-Baseline** erstellen.

1. Geben Sie im Feld **Name** einen Namen für die neue Patch-Baseline ein, z. B. `MymacOSPatchBaseline`.

1. (Optional) Geben Sie im Feld **Beschreibung** eine Beschreibung für diese Patch-Baseline ein.

1. Wählen Sie unter **Betriebssystem** die Option macOS aus.

1. Wenn Sie die Patch-Baseline direkt nach dem Erstellen als Standard für macOS verwenden möchten, aktivieren Sie das Kontrollkästchen **Set this patch baseline as the default patch baseline for macOS instances (Diese Patch-Baseline als Standard-Patch-Baseline für macOs-Instances festlegen)**.
**Anmerkung**  
Diese Option ist nur verfügbar, wenn Sie vor der Veröffentlichung der [Patch-Richtlinien](patch-manager-policies.md) am 22. Dezember 2022 zum ersten Mal auf Patch Manager zugegriffen haben.  
Weitere Informationen zum Festlegen einer vorhandenen Patch-Baseline als Standard finden Sie unter [Festlegen einer vorhandenen Patch-Baseline als Standard](patch-manager-default-patch-baseline.md).

1. Erstellen Sie im Abschnitt **Genehmigungsregeln für Betriebssysteme** unter Verwendung der Felder ein oder mehrere automatische Genehmigungsregeln.
   + **Produkte**: Die Version der Betriebssysteme, auf die sich die Genehmigungsregel bezieht, z. B. `BigSur11.3.1` oder `Ventura13.7`. Die Standardauswahl ist `All`.
   + **Klassifizierung**: Der oder die Paketmanager, auf den/die während des Patchvorgangs Pakete angewendet werden sollen. Sie können aus den folgenden Optionen auswählen:
     + softwareupdate
     + installer
     + brew
     + brew cask

     Die Standardauswahl ist `All`. 
   + (Optional) **Konformitätsbericht **: Der Schweregrad, den Sie Patches zuweisen möchten, die von der Baseline genehmigt wurden (z. B. `Critical` oder `High`).
**Anmerkung**  
Wenn Sie eine Konformitätsberichtsstufe angeben und der Patch-Status eines genehmigten Patches als `Missing` gemeldet wird, dann entspricht der insgesamt gemeldete Konformitätsschweregrad der Patch-Baseline dem von Ihnen angegebenen Schweregrad.

   Weitere Informationen zum Arbeiten mit Genehmigungsregeln in einer benutzerdefinierten Patch-Baseline finden Sie unter [Benutzerdefinierte Baselines](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom).

1. Wenn Sie zusätzlich zu den Patches, die Ihren Genehmigungsregeln entsprechen, alle Patches ausdrücklich genehmigen möchten, gehen Sie im Abschnitt **Patch-Ausnahmen** wie folgt vor:
   + Geben Sie im Feld **Genehmigte Patches** eine durch Komma getrennte Liste der Patches ein, die Sie genehmigen möchten.

     Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
   + (Optional) Weisen Sie in der Liste **Compliance-Stufe genehmigter Patches** den Patches in der Liste eine Compliance-Stufe zu.

1. Wenn Sie Patches ablehnen möchten, die ansonsten Ihren Genehmigungsregeln entsprechen, gehen Sie im Abschnitt **Patch-Ausnahmen** wie folgt vor:
   + Geben Sie im Feld **Abgelehnte Patches** eine durch Komma getrennte Liste der Patches ein, die Sie ablehnen möchten.

     Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
   + Wählen Sie in der Liste **Aktion für abgelehnte Patches** die Aktion aus, die Patch Manager für Patches in der Liste **Abgelehnte Patches** ausführen soll.
     + **Als Abhängigkeit zulassen**: Ein Paket in der Liste **Abgelehnte Patches** wird nur installiert, wenn es sich um eine Abhängigkeit eines anderen Pakets handelt. Es gilt als konform mit der Patch-Baseline und sein Status wird als gemeldet *InstalledOther*. Dies ist die Standardaktion, wenn keine Option ausgewählt ist.
     + **Blockieren**: Pakete in der Liste **Abgelehnte Patches** und Pakete, die diese als Abhängigkeiten enthalten, werden unter keinen Umständen von Patch Manager installiert. Wenn ein Paket installiert wurde, bevor es zur Liste der **abgelehnten Patches** hinzugefügt wurde, oder danach außerhalb von Patch Manager installiert wird, gilt es als nicht konform mit der Patch-Baseline und sein Status wird als *InstalledRejected* gemeldet.

1. (Optional) Wenden **Sie unter Tags verwalten** ein oder mehrere name/value Tag-Schlüsselpaare auf die Patch-Baseline an.

   Tags sind optionale Metadaten, die Sie einer Ressource zuweisen. Mithilfe von Tags können Sie eine Ressource unterschiedlich kategorisieren, beispielsweise nach Zweck, Besitzer oder Umgebung. Sie können beispielsweise eine Patch-Baseline kennzeichnen, um den Schweregrad der angegebenen Patches, den Paketmanager, auf den sie sich bezieht, und den Umgebungstyp zu identifizieren. In diesem Fall könnten Sie Tags angeben, die den folgenden name/value Schlüsselpaaren ähneln:
   + `Key=PatchSeverity,Value=Critical`
   + `Key=PackageManager,Value=softwareupdate`
   + `Key=Environment,Value=Production`

1. Wählen Sie die Option **Patch-Baseline erstellen**.

# Erstellen einer benutzerdefinierten Patch-Baseline für Windows Server
<a name="patch-manager-create-a-patch-baseline-for-windows"></a>

Verwenden Sie das folgende Verfahren, um eine benutzerdefinierte Patch-Baseline für Windows-verwaltete Knoten in Patch Manager zu erstellen, einem Tool in AWS Systems Manager. 

Informationen zum Erstellen einer Patch-Baseline für Linux-verwaltete Knoten finden Sie unter [So erstellen Sie eine benutzerdefinierte Patch-Baseline für Linux](patch-manager-create-a-patch-baseline-for-linux.md). Informationen zum Erstellen einer Patch-Baseline für macOS-verwaltete Knoten finden Sie unter [Erstellen einer benutzerdefinierten Patch-Baseline für macOS](patch-manager-create-a-patch-baseline-for-macos.md).

Ein Beispiel für das Erstellen einer Patch-Baseline, die auf die Installation von Windows Service Packs eingeschränkt ist, finden Sie unter [So erstellen Sie eine Patch-Baseline für die Installation von Windows Service Packs mithilfe der Konsole](patch-manager-windows-service-pack-patch-baseline-tutorial.md).

**So erstellen Sie eine benutzerdefinierte Patch-Baseline (Windows)**

1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Wählen Sie im Navigationsbereich **Patch Manager** aus.

1. Wählen Sie die Registerkarte **Patch-Baselines** und dann **Patch-Baseline erstellen** aus. 

   –oder–

   Wenn Sie in der aktuellen AWS-Region zum ersten Mal auf Patch Manager zugreifen, wählen Sie **Mit einer Übersicht beginnen**, wechseln Sie zur Registerkarte **Patch-Baselines** und wählen Sie dann **Patch-Baseline** erstellen.

1. Geben Sie im Feld **Name** einen Namen für die neue Patch-Baseline ein, z. B. `MyWindowsPatchBaseline`.

1. (Optional) Geben Sie im Feld **Beschreibung** eine Beschreibung für diese Patch-Baseline ein.

1. Wählen Sie unter **Betriebssystem** die Option `Windows` aus.

1. Wählen Sie unter **Compliance-Status für verfügbare Sicherheitsupdates** den Status aus, den Sie Sicherheitspatches zuweisen möchten, die zwar verfügbar, aber nicht genehmigt sind, weil sie die in der Patch-Baseline angegebenen Installationskriterien (**Nicht konform** oder **Konform**) nicht erfüllen.

   Beispielszenario: Sicherheitspatches, die Sie möglicherweise installieren möchten, können übersprungen werden, wenn Sie eine lange Wartezeit für die Installation nach der Veröffentlichung eines Patches angegeben haben. Wenn während der von Ihnen angegebenen Wartezeit ein Update für den Patch veröffentlicht wird, beginnt die Wartezeit für die Installation des Patches von vorne. Wenn die Wartezeit zu lang ist, können mehrere Versionen des Patches veröffentlicht, aber nie installiert werden.

1. Wenn Sie diese Patch-Baseline direkt nach dem Erstellen als Standard für Windows verwenden möchten, wählen Sie **Set this patch baseline as the default patch baseline for Windows Server instances (Diese Patch-Baseline als Standard-Patch-Baseline für Windows Server-Instances festlegen)** aus.
**Anmerkung**  
Diese Option ist nur verfügbar, wenn Sie vor der Veröffentlichung der [Patch-Richtlinien](patch-manager-policies.md) am 22. Dezember 2022 zum ersten Mal auf Patch Manager zugegriffen haben.  
Weitere Informationen zum Festlegen einer vorhandenen Patch-Baseline als Standard finden Sie unter [Festlegen einer vorhandenen Patch-Baseline als Standard](patch-manager-default-patch-baseline.md).

1. Erstellen Sie im Abschnitt **Approval Rules for operating-systems (Genehmigungsregeln für Betriebssysteme)** unter Verwendung der Felder ein oder mehrere automatische Genehmigungsregeln.
   + **Produkte**: Die Version der Betriebssysteme, auf die sich die Genehmigungsregel bezieht, z. B. `WindowsServer2012`. Die Standardauswahl ist `All`.
   + **Classification (Klassifizierung)**: Der Typ der Patches, auf die sich die Genehmigungsregel bezieht, z. B. `CriticalUpdates`, `Drivers` und `Tools`. Die Standardauswahl ist `All`. 
**Tipp**  
Sie können Windows Service Pack-Installationen in die Genehmigungsregeln einschließen, indem Sie die `ServicePacks` einschließen oder `All` in der Liste **Classification (Klassifizierung)** auswählen. Ein Beispiel finden Sie unter [So erstellen Sie eine Patch-Baseline für die Installation von Windows Service Packs mithilfe der Konsole](patch-manager-windows-service-pack-patch-baseline-tutorial.md).
   + **Schweregrad**: Der Schweregradwert von Patches, auf den die Regel anzuwenden ist, z. B. `Critical`. Die Standardauswahl ist `All`. 
   + **Automatische Genehmigung**: Die Methode zum Auswählen von Patches für die automatische Genehmigung.
     + **Patches nach einer bestimmten Anzahl von Tagen genehmigen**: Die Anzahl der Tage, die der Patch Manager warten muss, nachdem ein Patch veröffentlicht oder aktualisiert wurde, bevor ein Patch automatisch genehmigt wird. Sie können jede Ganzzahl von Null (0) bis 360 eingeben. Für die meisten Szenarien empfehlen wir, nicht länger als 100 Tage zu warten.
     + **Patches genehmigen, die bis zu einem bestimmten Datum veröffentlicht wurden**: Das Datum der Patch-Veröffentlichung, an dem der Patch Manager automatisch alle Patches anwendet, die bis zu diesem Datum veröffentlicht oder aktualisiert wurden. Wenn Sie beispielsweise den 07. Juli 2023 angeben, werden Patches, die am oder nach dem 08. Juli 2023 veröffentlicht oder zuletzt aktualisiert wurden, nicht automatisch installiert.
   + (Optional) **Compliance-Bericht **: Der Schweregrad, den Sie Patches zuweisen möchten, die von der Baseline genehmigt wurden (z. B. `High`).
**Anmerkung**  
Wenn Sie eine Konformitätsberichtsstufe angeben und der Patch-Status eines genehmigten Patches als `Missing` gemeldet wird, dann entspricht der insgesamt gemeldete Konformitätsschweregrad der Patch-Baseline dem von Ihnen angegebenen Schweregrad.

1. (Optional) Erstellen Sie im Abschnitt **Approval Rules for applications (Genehmigungsregeln für Anwendungen)** unter Verwendung der Felder ein oder mehrere automatische Genehmigungsregeln.
**Anmerkung**  
Anstatt Genehmigungsregeln anzugeben, können Sie Listen genehmigter und abgelehnter Patches als Patch-Ausnahmen angeben. Siehe Schritte 10 und 11. 
   + **Product family (Produktfamilie)**: Die allgemeine Microsoft-Produktfamilie, für die Sie eine Regel festlegen möchten, z. B. `Office` oder `Exchange Server`.
   + **Produkte**: Die Version der Anwendung, auf die sich die Genehmigungsregel bezieht, z. B. `Office 2016` oder `Active Directory Rights Management Services Client 2.0 2016`. Die Standardauswahl ist `All`.
   + **Classification (Klassifikation)**: Der Typ der Patches, auf die sich die Genehmigungsregel bezieht, z. B. `CriticalUpdates`. Die Standardauswahl ist `All`. 
   + **Severity (Schweregrad)**: Der Schweregradwert von Patches, auf den die Regel anzuwenden ist, z. B. `Critical`. Die Standardauswahl ist `All`. 
   + **Automatische Genehmigung**: Die Methode zum Auswählen von Patches für die automatische Genehmigung.
     + **Patches nach einer bestimmten Anzahl von Tagen genehmigen**: Die Anzahl der Tage, die der Patch Manager warten muss, nachdem ein Patch veröffentlicht oder aktualisiert wurde, bevor ein Patch automatisch genehmigt wird. Sie können jede Ganzzahl von Null (0) bis 360 eingeben. Für die meisten Szenarien empfehlen wir, nicht länger als 100 Tage zu warten.
     + **Patches genehmigen, die bis zu einem bestimmten Datum veröffentlicht wurden**: Das Datum der Patch-Veröffentlichung, an dem der Patch Manager automatisch alle Patches anwendet, die bis zu diesem Datum veröffentlicht oder aktualisiert wurden. Wenn Sie beispielsweise den 7. Juli 2023 angeben, werden Patches, die am oder nach dem 8. Juli 2023 veröffentlicht oder zuletzt aktualisiert wurden, nicht automatisch installiert.
   + (Optional) **Konformitätsbericht **: Der Schweregrad, den Sie Patches zuweisen möchten, die von der Baseline genehmigt wurden (z. B. `Critical` oder `High`).
**Anmerkung**  
Wenn Sie eine Konformitätsberichtsstufe angeben und der Patch-Status eines genehmigten Patches als `Missing` gemeldet wird, dann entspricht der insgesamt gemeldete Konformitätsschweregrad der Patch-Baseline dem von Ihnen angegebenen Schweregrad.

1. (Optional) Wenn Sie Patches explizit genehmigen möchten, anstatt Patches gemäß Genehmigungsregeln auszuwählen, gehen Sie im Abschnitt **Patch-Ausnahmen** folgendermaßen vor:
   + Geben Sie im Feld **Genehmigte Patches** eine durch Komma getrennte Liste der Patches ein, die Sie genehmigen möchten.

     Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
   + (Optional) Weisen Sie in der Liste **Compliance-Stufe genehmigter Patches** den Patches in der Liste eine Compliance-Stufe zu.

1. Wenn Sie Patches ablehnen möchten, die ansonsten Ihren Genehmigungsregeln entsprechen, gehen Sie im Abschnitt **Patch-Ausnahmen** wie folgt vor:
   + Geben Sie im Feld **Abgelehnte Patches** eine durch Komma getrennte Liste der Patches ein, die Sie ablehnen möchten.

     Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
   + Wählen Sie in der Liste **Aktion für abgelehnte Patches** die Aktion aus, die Patch Manager für Patches in der Liste **Abgelehnte Patches** ausführen soll.
     + **Als Abhängigkeit zulassen**: unterstützt das Konzept der Paketabhängigkeiten Windows Server nicht. Wenn ein Paket in der Liste der **abgelehnten Patches** enthalten ist und bereits auf dem Knoten installiert ist, wird sein Status als `INSTALLED_OTHER` gemeldet. Jedes Paket, das noch nicht auf dem Knoten installiert ist, wird übersprungen. 
     + **Blockieren**: Pakete in der Liste der **abgelehnten Patches** werden von Patch Manager unter keinen Umständen installiert. Wenn ein Paket installiert wurde, bevor es zur Liste der **abgelehnten Patches** hinzugefügt wurde, oder danach außerhalb von Patch Manager installiert wird, gilt es als nicht konform mit der Patch-Baseline und sein Status wird als `INSTALLED_REJECTED` gemeldet.

     Weitere Informationen zu Aktionen für abgelehnte Pakete finden Sie unter [Optionen für die Liste abgelehnter Patches in benutzerdefinierten Patch-Baselines](patch-manager-windows-and-linux-differences.md#rejected-patches-diff). 

1. (Optional) Wenden **Sie unter Tags verwalten** ein oder mehrere name/value Tag-Schlüsselpaare auf die Patch-Baseline an.

   Tags sind optionale Metadaten, die Sie einer Ressource zuweisen. Mithilfe von Tags können Sie eine Ressource unterschiedlich kategorisieren, beispielsweise nach Zweck, Besitzer oder Umgebung. Sie können beispielsweise eine Patch-Baseline kennzeichnen, um den Schweregrad der angegebenen Patches, die Betriebssystemfamilie, auf die sie sich bezieht, und den Umgebungstyp zu identifizieren. In diesem Fall könnten Sie Tags angeben, die den folgenden name/value Schlüsselpaaren ähneln:
   + `Key=PatchSeverity,Value=Critical`
   + `Key=OS,Value=RHEL`
   + `Key=Environment,Value=Production`

1. Wählen Sie die Option **Patch-Baseline erstellen**.

# Aktualisieren oder Löschen einer benutzerdefinierten Patch-Baseline
<a name="patch-manager-update-or-delete-a-patch-baseline"></a>

Sie können eine benutzerdefinierte Patch-Baseline, die Sie erstellt haben, in Patch Manager, einem Tool in AWS Systems Manager, aktualisieren oder löschen. Wenn Sie eine Patch-Baseline aktualisieren, können Sie deren Namen oder Beschreibung, die Genehmigungsregeln sowie die Ausnahmen für genehmigte und abgelehnte Patches ändern. Sie können auch die Tags aktualisieren, die auf die Patch-Baseline angewendet werden. Sie können den Betriebssystemtyp, für den eine Patch-Baseline erstellt wurde, nicht ändern, und Sie können keine Änderungen an einer vordefinierten Patch-Baseline vornehmen, die von bereitgestellt wird AWS.

## Aktualisieren oder Löschen einer Patch-Baseline
<a name="sysman-maintenance-update-mw"></a>

Gehen Sie wie folgt vor, um eine Patch-Baseline zu aktualisieren oder zu löschen.

**Wichtig**  
 Gehen Sie vorsichtig vor, wenn Sie eine benutzerdefinierte Patch-Baseline löschen, die möglicherweise von einer Patch-Richtlinienkonfiguration in Quick Setup verwendet wird.  
Wenn Sie eine [Patch-Richtlinienkonfiguration](patch-manager-policies.md) in Quick Setup verwenden, werden Aktualisierungen, die Sie an benutzerdefinierten Patch-Baselines vornehmen, einmal pro Stunde mit Quick Setup synchronisiert.   
Wenn eine benutzerdefinierte Patch-Baseline gelöscht wird, auf die in einer Patch-Richtlinie verwiesen wurde, wird auf der Seite mit den Quick Setup-**Konfigurationsdetails** ein Banner für Ihre Patch-Richtlinie angezeigt. Das Banner informiert Sie darüber, dass die Patch-Richtlinie auf eine nicht mehr vorhandene Patch-Baseline verweist und nachfolgende Patching-Vorgänge fehlschlagen werden. Kehren Sie in diesem Fall zur Seite Quick Setup-**Konfigurationen** zurück, wählen Sie die Patch Manager-Konfiguration aus und wählen Sie **Aktionen**, **Konfiguration bearbeiten**. Der Name der gelöschten Patch-Baseline wird hervorgehoben, und Sie müssen eine neue Patch-Baseline für das betroffene Betriebssystem auswählen.

**So aktualisieren oder löschen Sie eine Patch-Baseline**

1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Wählen Sie im Navigationsbereich **Patch Manager** aus.

1. Wählen Sie die Patch-Baseline aus, die Sie aktualisieren oder löschen möchten, und führen Sie dann einen der folgenden Schritte aus:
   + Um die Patch-Baseline aus Ihrem zu entfernen AWS-Konto, wählen Sie **Löschen**. Sie werden aufgefordert, Ihre Aktionen zu bestätigen. 
   + Wenn Sie den Namen oder die Beschreibung, die Genehmigungsregeln oder Patch-Ausnahmen der Patch-Baseline ändern möchten, wählen Sie **Edit (Bearbeiten)** aus. Nehmen Sie auf der Seite **Edit patch baseline (Patch-Baseline bearbeiten)** die gewünschten Änderungen vor und klicken Sie dann auf **Save changes (Änderungen speichern)**. 
   + Wenn Sie auf die Patch-Baseline angewendete Tags hinzufügen, ändern oder löschen möchten, klicken Sie auf die Registerkarte **Tags (Tags)** und dann auf **Edit tags (Tags bearbeiten)**. Nehmen Sie auf der Seite **Edit patch baseline tags (Patch-Baseline-Tags bearbeiten)** die gewünschten Änderungen vor und klicken Sie dann auf **Save changes (Änderungen speichern)**. 

   Weitere Informationen zu den Konfigurationsoptionen, die Sie ausführen können, finden Sie unter [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md).

# Festlegen einer vorhandenen Patch-Baseline als Standard
<a name="patch-manager-default-patch-baseline"></a>

**Wichtig**  
Alle hier getroffenen Standardauswahlen für die Patch-Baseline gelten nicht für Patching-Vorgänge, die auf einer Patch-Richtlinie basieren. Patch-Richtlinien verwenden ihre eigenen Patch-Baseline-Spezifikationen. Weitere Informationen zu Patch-Richtlinien finden Sie unter [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md).

Bereits beim Erstellen einer benutzerdefinierten Patch-Baseline in Patch Manager, einem Tool in AWS Systems Manager, können Sie die Baseline als Standard für den zugehörigen Betriebssystemtyp festlegen. Weitere Informationen finden Sie unter [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md).

Sie können auch eine vorhandene Patch-Baseline als Standard für einen Betriebssystemtyp festlegen.

**Anmerkung**  
Welche Schritte Sie ausführen, hängt davon ab, ob Sie vor oder nach der Veröffentlichung der Patch-Richtlinien am 22. Dezember 2022 auf Patch Manager zugegriffen haben. Wenn Sie Patch Manager vor diesem Datum verwendet haben, können Sie das Konsolenverfahren verwenden. Verwenden Sie andernfalls das AWS CLI Verfahren. Das Menü **Aktionen**, auf das im Konsolenverfahren verwiesen wird, wird in Regionen, in denen Patch Manager vor der Veröffentlichung der Patch-Richtlinien nicht verwendet wurde, nicht angezeigt.

**So legen Sie eine Patch-Baseline als Standard fest**

1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Wählen Sie im Navigationsbereich **Patch Manager** aus.

1. Wählen Sie die Registerkarte **Patch-Baselines** aus.

1. Wählen Sie in der Liste der Patch-Baselines die Schaltfläche einer Patch-Baseline aus, die derzeit nicht als Standard für ein Betriebssystem festgelegt ist.

   Die Spalte **Default baseline (Standard-Baseline)** gibt an, welche Baselines derzeit als Standardwerte festgelegt sind.

1. Wählen Sie im Menü **Actions (Aktionen)** die Option **Set default patch baseline (Standard-Patch-Baseline festlegen)** aus.
**Wichtig**  
Das **Aktionsmenü** ist nicht verfügbar, wenn Sie nicht vor dem 22. Dezember 2022 mit Patch Manager in der aktuellen Version AWS-Konto und in der Region gearbeitet haben. Weitere Informationen finden Sie in der **Anmerkung** weiter oben in diesem Thema.

1. Wählen Sie im Bestätigungsdialogfeld **Set default (Als Standard festlegen)** aus.

**So legen Sie eine Patch-Baseline als Standard fest (AWS CLI)**

1. Führen Sie den [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html)Befehl aus, um eine Liste der verfügbaren Patch-Baselines IDs und ihrer Amazon-Ressourcennamen () ARNs anzuzeigen.

   ```
   aws ssm describe-patch-baselines
   ```

1. Führen Sie den Befehl [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html) aus, um eine Baseline als Standard für das Betriebssystem festzulegen, mit dem sie verknüpft ist. *baseline-id-or-ARN*Ersetzen Sie ihn durch die ID der benutzerdefinierten Patch-Baseline oder der vordefinierten Baseline, die verwendet werden soll. 

------
#### [ Linux & macOS ]

   ```
   aws ssm register-default-patch-baseline \
       --baseline-id baseline-id-or-ARN
   ```

   Im Folgenden finden Sie ein Beispiel für die Festlegung einer benutzerdefinierten Baseline als Standard.

   ```
   aws ssm register-default-patch-baseline \
       --baseline-id pb-abc123cf9bEXAMPLE
   ```

   Im Folgenden finden Sie ein Beispiel für die Einstellung einer vordefinierten Baseline, die AWS standardmäßig verwaltet wird.

   ```
   aws ssm register-default-patch-baseline \
       --baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-0574b43a65ea646e
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-default-patch-baseline ^
       --baseline-id baseline-id-or-ARN
   ```

   Im Folgenden finden Sie ein Beispiel für die Festlegung einer benutzerdefinierten Baseline als Standard.

   ```
   aws ssm register-default-patch-baseline ^
       --baseline-id pb-abc123cf9bEXAMPLE
   ```

   Im Folgenden finden Sie ein Beispiel für die Einstellung einer vordefinierten Baseline, die AWS standardmäßig verwaltet wird.

   ```
   aws ssm register-default-patch-baseline ^
       --baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-071da192df1226b63
   ```

------

# Anzeigen verfügbarer Patches
<a name="patch-manager-view-available-patches"></a>

MitPatch Manager, einem Tool in AWS Systems Manager, können Sie alle verfügbaren Patches für ein bestimmtes Betriebssystem und optional eine bestimmte Betriebssystemversion anzeigen.

**Tipp**  
Um eine Liste verfügbarer Patches zu generieren und diese in einer Datei zu speichern, können Sie den Befehl [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html) verwenden und Ihre bevorzugte [Ausgabe](https://docs.aws.amazon.com/cli/latest/reference/ssm/cli-usage-output.html) angeben.

**Anzeigen verfügbarer Patches**

1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Wählen Sie im Navigationsbereich **Patch Manager** aus.

1. Wählen Sie die Registerkarte **Patches** aus.

   –oder–

   Wenn Sie in der aktuellen AWS-Region zum ersten Mal auf Patch Manager zugreifen, wählen Sie **Mit einer Übersicht beginnen** und dann die Registerkarte **Patches** aus.
**Anmerkung**  
Für Windows Server zeigt die Registerkarte **Patches** Updates an, die vom Windows Server Update Service (WSUS) verfügbar sind.

1. Für **Betriebssystem** wählen Sie das Betriebssystem aus, für das Sie verfügbare Patches anzeigen möchten, z. B. `Windows` oder `Amazon Linux`.

1. (Optional) Für **Product (Produkt)** wählen Sie eine Betriebssystemversion aus, z. B. `WindowsServer2019` oder `AmazonLinux2018.03`.

1. (Optional) Um Informationsspalten für Ihre Ergebnisse hinzuzufügen oder zu entfernen, wählen Sie die Konfigurationsschaltfläche (![\[The icon to view configuration settings.\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/configure-button.png)) oben rechts in der Liste **Patches** aus. (Standardmäßig zeigt die Registerkarte **Patches** nur Spalten für einige der verfügbaren Patch-Metadaten an.)

   Informationen zu den Arten von Metadaten, die Sie Ihrer Ansicht hinzufügen können, finden Sie unter [Patch](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_Patch.html) in der *AWS Systems Manager -API-Referenz*.

# Erstellen und Verwalten von Patch-Gruppen
<a name="patch-manager-tag-a-patch-group"></a>

Wenn Sie in Ihrem Betrieb *keine* Patching-Richtlinien verwenden, können Sie Ihre Patching-Aufgaben organisieren, indem Sie verwaltete Knoten mithilfe von Tags zu Patch-Gruppen hinzufügen.

**Anmerkung**  
Patch-Gruppen werden nicht in Patch-Vorgängen verwendet, die auf *Patch-Richtlinien* basieren. Weitere Informationen zur Arbeit mit Patch-Richtlinien finden Sie unter [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md).  
Die Patchgruppenfunktion wird in der Konsole für Konto-Regionen-Paare nicht unterstützt, die vor der Veröffentlichung der Patch-Richtlinienunterstützung am 22. Dezember 2022 noch keine Patchgruppen verwendet haben. Die Patchgruppenfunktion ist weiterhin für Konto-Regionen-Paare verfügbar, die vor diesem Datum mit der Verwendung von Patchgruppen begonnen haben.

Um Tags bei Patching-Operationen zu verwenden, müssen Sie den Tag-Schlüssel `Patch Group` oder `PatchGroup` auf Ihre verwalteten Knoten anwenden. Sie müssen auch den Namen, den Sie der Patch-Gruppe geben möchten, als Wert des Tags angeben. Sie können einen beliebigen Tag-Wert angeben, aber der Tag-Schlüssel muss `Patch Group` oder `PatchGroup` lauten.

`PatchGroup` (ohne Leerzeichen) ist erforderlich, wenn Sie [Tags in EC2-Instance-Metadaten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS) zugelassen haben. 

Nachdem Sie Ihre verwalteten Knoten mithilfe von Tags gruppiert haben, fügen Sie den Patch-Gruppenwert einer Patch-Baseline hinzu. Mit der Registrierung der Patch-Gruppe für eine Patch-Baseline können Sie sicherstellen, dass beim Einspielen von Patches die richtigen Patches installiert werden. Weitere Informationen zu Patch-Gruppen finden Sie unter [Patch-Gruppen](patch-manager-patch-groups.md).

Führen Sie die Aufgaben in diesem Thema aus, um Ihre verwalteten Knoten für das Patching vorzubereiten, indem Sie Tags mit Ihren Knoten und der Patch-Baseline verwenden. Aufgabe 1 ist nur erforderlich, wenn Sie Amazon-EC2-Instances patchen. Aufgabe 2 ist nur erforderlich, wenn Sie Nicht-EC2-Instances in einer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) patchen. Aufgabe 3 ist für alle verwalteten Knoten erforderlich.

**Tipp**  
Sie können verwalteten Knoten auch Tags hinzufügen, indem Sie den AWS CLI Befehl `[https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html)` oder den Systems Manager API-Vorgang ssm-agent-minimum-s `[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html)` 3-permissions-required verwenden.

**Topics**
+ [Aufgabe 1: Hinzufügen von EC2-Instances zu einer Patch-Gruppe mithilfe von Tags](#sysman-patch-group-tagging-ec2)
+ [Aufgabe 2: Hinzufügen von verwalteten Knoten zu einer Patch-Gruppe mithilfe von Tags](#sysman-patch-group-tagging-managed)
+ [Aufgabe 3: Hinzufügen einer Patch-Gruppe zu einer Patch-Baseline](#sysman-patch-group-patchbaseline)

## Aufgabe 1: Hinzufügen von EC2-Instances zu einer Patch-Gruppe mithilfe von Tags
<a name="sysman-patch-group-tagging-ec2"></a>

Sie können EC2-Instances über die Systems-Manager-Konsole oder die Amazon-EC2-Konsole Tags hinzufügen. Diese Aufgabe ist nur erforderlich, wenn Sie Amazon-EC2-Instances patchen.

**Wichtig**  
Sie können das `Patch Group`-Tag (mit einem Leerzeichen) nicht auf eine Amazon-EC2-Instance anwenden, wenn die Option **Allow tags in instance metadata** (Tags in Instance-Metadaten zulassen) auf der Instance aktiviert ist. Durch das Zulassen von Tags in Instance-Metadaten wird verhindert, dass Tag-Schlüsselnamen Leerzeichen enthalten. Wenn Sie [Tags in EC2-Instance-Metadaten zugelassen haben](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), müssen Sie den Tag-Schlüssel `PatchGroup` (ohne Leerzeichen) verwenden.

**Option 1: So fügen Sie EC2-Instances zu einer Patch-Gruppe hinzu (Systems-Manager-Konsole)**

1. Öffnen Sie die Konsole unter. AWS Systems Manager [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)

1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.

1. Wählen Sie in der Liste **Verwaltete Knoten** die ID einer verwalteten EC2-Instance, die Sie für das Patching konfigurieren möchten. Knoten-IDs für EC2-Instances beginnen mit `i-`.
**Anmerkung**  
Wenn Sie die Amazon EC2 EC2-Konsole und verwenden AWS CLI, ist es möglich, `Key = PatchGroup` Or-Tags auf Instances anzuwenden`Key = Patch Group`, die noch nicht für die Verwendung mit Systems Manager konfiguriert sind.  
Wenn ein verwalteter Knoten, den Sie erwarten, nicht aufgeführt ist, finden Sie weitere Informationen unter [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md) Tipps zur Fehlerbehebung.

1. Wählen Sie die Registerkarte **Tags** und dann **Bearbeiten** aus.

1. Geben Sie in der linken Spalte **Patch Group** oder **PatchGroup** ein. Wenn Sie [Tags in EC2-Instance-Metadaten zugelassen haben](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), müssen Sie `PatchGroup` (ohne Leerzeichen) verwenden.

1. Geben Sie in der rechten Spalte einen Tag-Wert ein, der als Name für die Patch-Gruppe dienen soll.

1. Wählen Sie **Speichern**.

1. Wiederholen Sie dieses Verfahren, um andere EC2-Instances zur selben Patch-Gruppe hinzuzufügen.

**Option 2: So fügen Sie EC2-Instances einer Patch-Gruppe hinzu (Amazon EC2-Konsole)**

1. Öffnen Sie im Navigationsbereich die [Amazon EC2-Konsole](https://console.aws.amazon.com/ec2/) und wählen Sie die Option **Instances** aus. 

1. Wählen Sie in der Liste der Instances eine Instance aus, die Sie für das Einspielen von Patches konfigurieren möchten.

1. Wählen Sie im Menü **Aktionen** die Option **Instance-Einstellungen**, **Tags verwalten** aus.

1. Wählen Sie **Neues Tag hinzufügen** aus.

1. Geben Sie für **Key** (Schlüssel) **Patch Group** oder **PatchGroup** ein. Wenn Sie [Tags in EC2-Instance-Metadaten zugelassen haben](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), müssen Sie `PatchGroup` (ohne Leerzeichen) verwenden.

1. Geben Sie für **Wert** einen Wert ein, der als Name für die Patch-Gruppe dienen soll.

1. Wählen Sie **Speichern**.

1. Wiederholen Sie dieses Verfahren, um andere Instances zur selben Patch-Gruppe hinzuzufügen.

## Aufgabe 2: Hinzufügen von verwalteten Knoten zu einer Patch-Gruppe mithilfe von Tags
<a name="sysman-patch-group-tagging-managed"></a>

Folgen Sie den Schritten in diesem Thema, um Tags zu AWS IoT Greengrass Kerngeräten und verwalteten Knoten (mi-\$1) ohne EC2-Hybrid-Aktivierung hinzuzufügen. Diese Aufgabe ist nur erforderlich, wenn Sie Nicht-EC2 Instances in einer Hybrid- und Multi-Cloud-Umgebung patchen.

**Anmerkung**  
Sie können über die Amazon-EC2-Konsole keine Tags für Nicht-EC2-verwaltete Knoten hinzufügen.

**So fügen Sie Nicht-EC2-verwaltete Knoten einer Patch-Gruppe hinzu (Systems-Manager-Konsole)**

1. Öffnen Sie die Konsole unter. AWS Systems Manager [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)

1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.

1. Wählen Sie in der Liste der **verwalteten Knoten** einen verwalteten Knoten, für den Sie das Patching konfigurieren möchten.
**Anmerkung**  
Wenn ein verwalteter Knoten, den Sie erwarten, nicht aufgeführt ist, finden Sie weitere Informationen unter [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md) Tipps zur Fehlerbehebung.

1. Wählen Sie die Registerkarte **Tags** und dann **Bearbeiten** aus.

1. Geben Sie in der linken Spalte **Patch Group** oder **PatchGroup** ein. Wenn Sie [Tags in EC2-Instance-Metadaten zugelassen haben](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), müssen Sie `PatchGroup` (ohne Leerzeichen) verwenden.

1. Geben Sie in der rechten Spalte einen Tag-Wert ein, der als Name für die Patch-Gruppe dienen soll.

1. Wählen Sie **Speichern**.

1. Wiederholen Sie dieses Verfahren, um andere verwaltete Knoten zur selben Patch-Gruppe hinzuzufügen.

## Aufgabe 3: Hinzufügen einer Patch-Gruppe zu einer Patch-Baseline
<a name="sysman-patch-group-patchbaseline"></a>

Um Ihren verwalteten Knoten eine bestimmte Patch-Baseline zuzuordnen, müssen Sie den Patch-Gruppenwert der Patch-Baseline hinzufügen. Mit der Registrierung der Patch-Gruppe für eine Patch-Baseline können Sie sicherstellen, dass beim Einspielen von Patches die richtigen Patches installiert werden. Diese Aufgabe ist unabhängig davon erforderlich, ob Sie EC2-Instances, verwaltete Nicht-EC2-Knoten oder beides patchen.

Weitere Informationen zu Patch-Gruppen finden Sie unter [Patch-Gruppen](patch-manager-patch-groups.md).

**Anmerkung**  
Welche Schritte Sie ausführen, hängt davon ab, ob Sie vor oder nach der Veröffentlichung der [Patch-Richtlinien](patch-manager-policies.md) am 22. Dezember 2022 zum ersten Mal auf Patch Manager zugegriffen haben.

**So fügen Sie eine Patch-Gruppe einer Patch-Baseline hinzu (Systems-Manager-Konsole)**

1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Wählen Sie im Navigationsbereich **Patch Manager** aus.

1. Wenn Sie auf Patch Manager zum ersten Mal in der aktuellen AWS-Region zugreifen und sich die Patch Manager-Startseite öffnet, wählen Sie **Mit einer Übersicht beginnen**.

1. Wählen Sie die Registerkarte **Patch-Baselines** und wählen Sie dann in der Liste **Patch-Baselines** den Namen der Patch-Baseline, die Sie für Ihre Patch-Gruppe konfigurieren möchten.

   Wenn Sie erst nach der Veröffentlichung der Patch-Richtlinien auf Patch Manager zugegriffen haben, müssen Sie eine von Ihnen erstellte benutzerdefinierte Baseline wählen.

1. Wenn die Detailseite der **Baseline-ID** ein Menü **Aktionen** enthält, gehen Sie wie folgt vor: 
   + Wählen Sie **Actions (Aktionen)** und dann **Modify patch groups (Patch-Gruppen modifizieren)** aus.
   + Geben Sie den *Tag-Wert*, den Sie Ihren verwalteten Knoten in [Aufgabe 2: Hinzufügen von verwalteten Knoten zu einer Patch-Gruppe mithilfe von Tags](#sysman-patch-group-tagging-managed) hinzugefügt haben, und wählen Sie dann **Hinzufügen**.

   Wenn die Detailseite der **Baseline-ID** *kein* Menü **Aktionen** enthält, können Patch-Gruppen in der Konsole nicht konfiguriert werden. Sie können stattdessen eine der folgenden Aktionen ausführen:
   + (Empfohlen) Richten Sie eine Patch-Richtlinie in Quick Setup, einem Tool in AWS Systems Manager, ein, um eine Patch-Baseline einer oder mehreren EC2-Instances zuzuordnen.

     Weitere Informationen finden Sie unter [Verwenden von Quick Setup-Patch-Richtlinien](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-policies.html) und [Automatisieren des unternehmensweiten Patchen mithilfe einer Quick Setup-Patch-Richtlinie](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html).
   + Verwenden Sie den [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html)Befehl in AWS Command Line Interface (AWS CLI), um eine Patchgruppe zu konfigurieren.

# Integrieren Patch Manager mit AWS Security Hub CSPM
<a name="patch-manager-security-hub-integration"></a>

[AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)bietet Ihnen einen umfassenden Überblick über Ihren Sicherheitsstatus in. AWS Security Hub CSPM sammelt Sicherheitsdaten von allen AWS-Konten und unterstützten Produkten von Drittanbietern. AWS-Services Mit Security Hub CSPM können Sie Ihre Umgebung anhand von Branchenstandards und Best Practices überprüfen. Security Hub CSPM hilft Ihnen dabei, Ihre Sicherheitstrends zu analysieren und Sicherheitsprobleme mit der höchsten Priorität zu identifizieren.

Mithilfe der Integration zwischenPatch Manager, einem Tool in AWS Systems Manager und Security Hub CSPM können Sie Erkenntnisse über nicht konforme Knoten von Patch Manager an Security Hub CSPM senden. Ein Ergebnis ist der beobachtbare Datensatz einer Sicherheitsprüfung oder sicherheitsrelevanten Erkennung. Security Hub CSPM kann diese patch-bezogenen Ergebnisse dann in die Analyse Ihres Sicherheitsstatus einbeziehen.

Die Informationen in den folgenden Themen gelten unabhängig davon, welche Methode oder Art der Konfiguration Sie für Ihre Patching-Vorgänge verwenden:
+ Eine in Quick Setup konfigurierte Patch-Richtlinie
+ Eine in Quick Setup konfigurierte Host-Management-Option
+ Ein Wartungsfenster zum Ausführen eines Patch-`Scan` oder einer `Install`-Aufgabe
+ Ein On-Demand-**Jetzt patchen**-Vorgang

**Contents**
+ [So sendet Patch Manager Erkenntnisse an Security Hub CSPM](#securityhub-integration-sending-findings)
  + [Arten von Erkenntnissen, die Patch Manager sendet](#securityhub-integration-finding-types)
  + [Latenz für das Senden von Erkenntnissen](#securityhub-integration-finding-latency)
  + [Wiederholung, wenn Security Hub CSPM nicht verfügbar ist](#securityhub-integration-retry-send)
  + [Ergebnisse in Security Hub CSPM anzeigen](#securityhub-integration-view-findings)
+ [Typische Erkenntnis von Patch Manager](#securityhub-integration-finding-example)
+ [Aktivieren und Konfigurieren der Integration](#securityhub-integration-enable)
+ [So beenden Sie das Senden von Ergebnissen](#securityhub-integration-disable)

## So sendet Patch Manager Erkenntnisse an Security Hub CSPM
<a name="securityhub-integration-sending-findings"></a>

In Security Hub CSPM werden Sicherheitsprobleme als Erkenntnisse verfolgt. Einige Ergebnisse stammen aus Problemen, die von anderen AWS-Services oder von Drittanbietern entdeckt wurden. Security Hub CSPM verfügt außerdem über eine Reihe von Regeln, anhand derer Sicherheitsprobleme erkannt und Ergebnisse generiert werden.

 Patch Managerist eines der Systems Manager Manager-Tools, das Ergebnisse an Security Hub CSPM sendet. Nachdem Sie einen Patchvorgang durchgeführt haben, indem Sie ein SSM-Dokument (`AWS-RunPatchBaseline`,, oder`AWS-RunPatchBaselineWithHooks`) ausführen`AWS-RunPatchBaselineAssociation`, werden die Patching-Informationen an Inventory oder Compliance, Tools in oder an beide gesendet. AWS Systems Manager Nachdem Inventory, Compliance oder beide die Daten erhalten haben, erhält Patch Manager eine Benachrichtigung. Dann wertet Patch Manager die Daten auf Genauigkeit, Formatierung und Compliance aus. Wenn alle Bedingungen erfüllt sind, werden die Daten an Security Hub CSPM Patch Manager weitergeleitet.

Security Hub CSPM bietet Tools zur Verwaltung von Erkenntnissen aus all diesen Quellen. Sie können Listen mit Erkenntnissen anzeigen und filtern und Details zu einer Erkenntnis anzeigen. Weitere Informationen finden Sie unter [Anzeigen der Erkenntnisse](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-viewing.html) im *AWS Security Hub -Benutzerhandbuch*. Sie können auch den Status einer Untersuchung zu einer Erkenntnis nachverfolgen. Weitere Informationen finden Sie unter [Ergreifen von Maßnahmen zu Erkenntnissen](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-taking-action.html) im *AWS Security Hub -Benutzerhandbuch*.

Alle Ergebnisse in Security Hub CSPM verwenden ein standardmäßiges JSON-Format, das AWS Security Finding Format (ASFF). Das ASFF enthält Details über die Ursache des Problems, die betroffenen Ressourcen und den aktuellen Status der Erkenntnis. Weitere Informationen finden Sie unter [AWS -Security Finding-Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.htm) im *AWS Security Hub -Benutzerhandbuch*.

### Arten von Erkenntnissen, die Patch Manager sendet
<a name="securityhub-integration-finding-types"></a>

Patch Managersendet die Ergebnisse mithilfe des Security [Finding Formats (ASFF) an AWS Security](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html) Hub CSPM. In ASFF gibt das `Types`-Feld die Art der Erkenntnis an. Die Ergebnisse von Patch Manager können den folgenden Wert für `Types` haben:
+ Software- und Konfigurationsmanagement Checks/Patch 

 Patch Manager sendet ein Ergebnis pro nicht konformen verwalteten Knoten. Das Ergebnis wird mit dem Ressourcentyp gemeldet, [https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance](https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance)sodass die Ergebnisse mit anderen Security Hub CSPM-Integrationen, die Ressourcentypen melden, korreliert werden können. `AwsEc2Instance` Patch Managerleitet ein Ergebnis nur dann an Security Hub CSPM weiter, wenn bei dem Vorgang festgestellt wurde, dass der verwaltete Knoten nicht konform ist. Das Ergebnis enthält die Ergebnisse der Patch-Zusammenfassung. 

**Anmerkung**  
Nach der Meldung eines nicht konformen Knotens an Security Hub CSPM. Patch Managersendet kein Update an Security Hub CSPM, nachdem der Knoten konform gemacht wurde. Sie können die Ergebnisse in Security Hub CSPM manuell beheben, nachdem die erforderlichen Patches auf den verwalteten Knoten angewendet wurden.

Weitere Informationen zu Compliance-Definitionen finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md). Weitere Informationen zu `PatchSummary` finden Sie [PatchSummary](https://docs.aws.amazon.com//securityhub/1.0/APIReference/API_PatchSummary.html)in der *AWS Security Hub API-Referenz*.

### Latenz für das Senden von Erkenntnissen
<a name="securityhub-integration-finding-latency"></a>

Wenn ein neues Ergebnis Patch Manager erstellt wird, wird es normalerweise innerhalb weniger Sekunden bis 2 Stunden an Security Hub CSPM gesendet. Die Geschwindigkeit hängt vom Verkehr zu diesem Zeitpunkt in der AWS-Region verarbeiteten Verkehr ab.

### Wiederholung, wenn Security Hub CSPM nicht verfügbar ist
<a name="securityhub-integration-retry-send"></a>

Bei einem Dienstausfall wird eine AWS Lambda Funktion ausgeführt, mit der die Nachrichten wieder in die Hauptwarteschlange verschoben werden, nachdem der Dienst wieder ausgeführt wird. Nachdem sich die Nachrichten in der Hauptwarteschlange befinden, erfolgt die Wiederholung automatisch.

Wenn Security Hub CSPM nicht verfügbar ist, Patch Manager versucht es erneut, die Ergebnisse zu senden, bis sie empfangen werden.

### Ergebnisse in Security Hub CSPM anzeigen
<a name="securityhub-integration-view-findings"></a>

In diesem Verfahren wird beschrieben, wie Sie in Security Hub CSPM Ergebnisse zu verwalteten Knoten in Ihrer Flotte einsehen können, die nicht mehr patch-konform sind.

**Um die CSPM-Ergebnisse von Security Hub auf Patch-Konformität zu überprüfen**

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS Security Hub CSPM Konsole unter. [https://console.aws.amazon.com/securityhub/](https://console.aws.amazon.com/securityhub/)

1. Wählen Sie im Navigationsbereich **Findings** aus.

1. Wählen Sie das Feld **Filter hinzufügen** (![\[The Search icon\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/search-icon.png)).

1. Wählen Sie im Menü unter **Filter** die Option **Produktname** aus.

1. Wählen Sie in dem sich öffnenden Dialogfeld im ersten Feld die Option **ist** und geben Sie dann **Systems Manager Patch Manager** im zweiten Feld ein.

1. Wählen Sie **Anwenden** aus.

1. Fügen Sie weitere Filter hinzu, um Ihre Ergebnisse einzugrenzen.

1. Wählen Sie in der Ergebnisliste den Titel eines Erkenntnisses aus, zu dem Sie weitere Informationen wünschen.

   Auf der rechten Seite des Bildschirms wird ein Bereich mit weiteren Informationen zur Ressource, dem erkannten Problem und einer empfohlenen Lösung geöffnet.
**Wichtig**  
Derzeit meldet Security Hub CSPM den Ressourcentyp aller verwalteten Knoten als. `EC2 Instance` Dazu gehören lokale Server und virtuelle Maschinen (VMs), die Sie für die Verwendung mit Systems Manager registriert haben.

**Schweregradklassifizierungen**  
Die Liste der Erkenntnisse für **Systems Manager Patch Manager** enthält einen Bericht über den Schweregrad des Befundes. Zu den **Schweregraden** gehören die folgenden, vom niedrigsten zum höchsten:
+ **INFORMATIV** – Es wurde kein Problem gefunden.
+ **NIEDRIG** — Das Problem muss nicht behoben werden.
+ **MITTEL** – Das Problem muss angegangen werden, aber ist nicht dringend.
+ **HOCH** – Das Problem muss vorrangig behandelt werden.
+ **KRITISCH** – Das Problem muss sofort behoben werden, um eine Eskalation zu vermeiden.

Der Schweregrad wird durch das schwerwiegendste nicht konforme Paket auf einer Instance bestimmt. Da Sie mehrere Patch-Baselines mit verschiedenen Schweregraden haben können, wird der höchste Schweregrad von allen nicht konformen Paketen gemeldet. Nehmen wir zum Beispiel an, Sie haben zwei nicht konforme Pakete, wobei der Schweregrad von Paket A „Kritisch“ und der von Paket B „Gering“ ist. „Kritisch“ wird als Schweregrad angegeben werden.

Beachten Sie, dass das Schweregradfeld direkt mit dem Feld Patch Manager `Compliance` korreliert. Dies ist ein Feld, das Sie einzelnen Patches zuweisen, die der Regel entsprechen. Da dieses `Compliance`-Feld einzelnen Patches zugewiesen ist, wird es nicht auf der Ebene der Patch-Zusammenfassung wiedergegeben.

**Verwandter Inhalt**
+ [Erkenntnisse](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings.html) im *AWS Security Hub -Benutzerhandbuch*
+ [Multi-Account Patch-Compliance mit Patch Manager und Security Hub](https://aws.amazon.com/blogs/mt/multi-account-patch-compliance-with-patch-manager-and-security-hub/) im *AWS -Management & Governance Blog*

## Typische Erkenntnis von Patch Manager
<a name="securityhub-integration-finding-example"></a>

Patch Managersendet Ergebnisse mithilfe des Security [Finding Formats (ASFF) an AWS Security](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html) Hub CSPM.

Hier ist ein Beispiel für ein typisches Ergebnis von Patch Manager.

```
{
  "SchemaVersion": "2018-10-08",
  "Id": "arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
  "ProductArn": "arn:aws:securityhub:us-east-1::product/aws/ssm-patch-manager",
  "GeneratorId": "d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
  "AwsAccountId": "111122223333",
  "Types": [
    "Software & Configuration Checks/Patch Management/Compliance"
  ],
  "CreatedAt": "2021-11-11T22:05:25Z",
  "UpdatedAt": "2021-11-11T22:05:25Z",
  "Severity": {
    "Label": "INFORMATIONAL",
    "Normalized": 0
  },
  "Title": "Systems Manager Patch Summary - Managed Instance Non-Compliant",
  "Description": "This AWS control checks whether each instance that is managed by AWS Systems Manager is in compliance with the rules of the patch baseline that applies to that instance when a compliance Scan runs.",
  "Remediation": {
    "Recommendation": {
      "Text": "For information about bringing instances into patch compliance, see 'Remediating out-of-compliance instances (Patch Manager)'.",
      "Url": "https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-compliance-remediation.html"
    }
  },
  "SourceUrl": "https://us-east-2.console.aws.amazon.com/systems-manager/fleet-manager/i-02573cafcfEXAMPLE/patch?region=us-east-2",
  "ProductFields": {
    "aws/securityhub/FindingId": "arn:aws:securityhub:us-east-2::product/aws/ssm-patch-manager/arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
    "aws/securityhub/ProductName": "Systems Manager Patch Manager",
    "aws/securityhub/CompanyName": "AWS"
  },
  "Resources": [
    {
      "Type": "AwsEc2Instance",
      "Id": "i-02573cafcfEXAMPLE",
      "Partition": "aws",
      "Region": "us-east-2"
    }
  ],
  "WorkflowState": "NEW",
  "Workflow": {
    "Status": "NEW"
  },
  "RecordState": "ACTIVE",
  "PatchSummary": {
    "Id": "pb-0c10e65780EXAMPLE",
    "InstalledCount": 45,
    "MissingCount": 2,
    "FailedCount": 0,
    "InstalledOtherCount": 396,
    "InstalledRejectedCount": 0,
    "InstalledPendingReboot": 0,
    "OperationStartTime": "2021-11-11T22:05:06Z",
    "OperationEndTime": "2021-11-11T22:05:25Z",
    "RebootOption": "NoReboot",
    "Operation": "SCAN"
  }
}
```

## Aktivieren und Konfigurieren der Integration
<a name="securityhub-integration-enable"></a>

Um die Patch Manager Integration mit Security Hub CSPM zu verwenden, müssen Sie Security Hub CSPM aktivieren. *Informationen zum Aktivieren von Security Hub CSPM finden Sie unter [Security Hub CSPM einrichten im Benutzerhandbuch](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html).AWS Security Hub *

Das folgende Verfahren beschreibt, wie Security Hub CSPM integriert Patch Manager wird, wenn Security Hub CSPM bereits aktiv, aber die Patch Manager Integration ausgeschaltet ist. Sie müssen diesen Vorgang nur abschließen, wenn die Integration manuell deaktiviert wurde.

**Um die CSPM-Integration Patch Manager zur Security Hub hinzuzufügen**

1. Wählen Sie im Navigationsbereich **Patch Manager** aus.

1. Wählen Sie die Registerkarte **Einstellungen**.

   –oder–

   Wenn Sie in der aktuellen AWS-Region zum ersten Mal auf Patch Manager zugreifen, wählen Sie **Mit einer Übersicht beginnen** und dann die Registerkarte **Einstellungen** aus.

1. **Wählen Sie im Abschnitt **Export to Security Hub CSPM** rechts neben Die **Ergebnisse der Patch-Konformität werden nicht nach Security Hub exportiert die** Option Aktivieren aus.**

## So beenden Sie das Senden von Ergebnissen
<a name="securityhub-integration-disable"></a>

Um anzugeben, dass keine Erkenntnisse mehr an Security Hub CSPM gesendet werden, können Sie entweder die Konsole von Security Hub CSPM oder die API verwenden.

Weitere Informationen finden Sie in folgenden Themen im *AWS Security Hub -Benutzerhandbuch*:
+ [Deaktivieren und Aktivieren des Flows von Ergebnissen aus einer Integration (Konsole)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-console)
+ [Deaktivierung des Flusses von Erkenntnissen aus einer Integration (Security Hub CSPM API,) AWS CLI](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-disable-api)

# Arbeiten mit Patch Manager-Ressourcen unter Verwendung der AWS CLI
<a name="patch-manager-cli-commands"></a>

Der Abschnitt enthält Beispiele für AWS Command Line Interface (AWS CLI) -Befehle, mit denen Sie Konfigurationsaufgaben für Patch Manager ein Tool in ausführen können AWS Systems Manager.

Eine Veranschaulichung der Verwendung von AWS CLI zum Patchen einer Serverumgebung mithilfe einer benutzerdefinierten Patch-Baseline finden Sie unter[Tutorial: Patchen Sie eine Serverumgebung mit dem AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md).

Weitere Informationen zur Verwendung von AWS CLI for AWS Systems Manager Tasks finden Sie im [AWS Systems Manager Abschnitt der AWS CLI Befehlsreferenz](https://docs.aws.amazon.com/cli/latest/reference/ssm/index.html).

**Topics**
+ [AWS CLI Befehle für Patch-Baselines](#patch-baseline-cli-commands)
+ [AWS CLI Befehle für Patchgruppen](#patch-group-cli-commands)
+ [AWS CLI Befehle zum Anzeigen von Patch-Zusammenfassungen und Details](#patch-details-cli-commands)
+ [AWS CLI Befehle zum Scannen und Patchen verwalteter Knoten](#patch-operations-cli-commands)

## AWS CLI Befehle für Patch-Baselines
<a name="patch-baseline-cli-commands"></a>

**Topics**
+ [Erstellen einer Patch-Baseline](#patch-manager-cli-commands-create-patch-baseline)
+ [Erstellen einer Patch-Baseline mit benutzerdefinierten Repositorys für verschiedene Betriebssystemversionen](#patch-manager-cli-commands-create-patch-baseline-mult-sources)
+ [Aktualisieren einer Patch-Baseline](#patch-manager-cli-commands-update-patch-baseline)
+ [Umbenennen einer Patch-Baseline](#patch-manager-cli-commands-rename-patch-baseline)
+ [Löschen einer Patch-Baseline](#patch-manager-cli-commands-delete-patch-baseline)
+ [Auflisten aller Patch-Baselines](#patch-manager-cli-commands-describe-patch-baselines)
+ [Listet alle von AWS-bereitgestellten Patch-Baselines auf](#patch-manager-cli-commands-describe-patch-baselines-aws)
+ [Auflisten der eigenen Patch-Baselines](#patch-manager-cli-commands-describe-patch-baselines-custom)
+ [Anzeigen einer Patch-Baseline](#patch-manager-cli-commands-get-patch-baseline)
+ [Abrufen einer Standard-Patch-Baseline](#patch-manager-cli-commands-get-default-patch-baseline)
+ [Eine benutzerdefinierte Patch-Baseline als Standard festlegen](#patch-manager-cli-commands-register-default-patch-baseline)
+ [Setzen Sie eine AWS Patch-Baseline als Standard zurück](#patch-manager-cli-commands-register-aws-patch-baseline)
+ [Markieren einer Patch-Baseline](#patch-manager-cli-commands-add-tags-to-resource)
+ [Auflisten aller Tags für eine Patch-Baseline](#patch-manager-cli-commands-list-tags-for-resource)
+ [Entfernen eines Tags aus einer Patch-Baseline](#patch-manager-cli-commands-remove-tags-from-resource)

### Erstellen einer Patch-Baseline
<a name="patch-manager-cli-commands-create-patch-baseline"></a>

Der folgende Befehl erstellt eine Patch-Baseline, die alle kritischen und wichtigen Sicherheitsaktualisierungen für Windows Server 2012 R2 fünf Tage nach ihrer Veröffentlichung genehmigt. Patches wurden auch für die Listen „Genehmigt“ und „Zurückgewiesen“ angegeben. Darüber hinaus wurde die Patch-Baseline mit Tags versehen, um sie für die Produktionsumgebung freizugeben.

------
#### [ Linux & macOS ]

```
aws ssm create-patch-baseline \
    --name "Windows-Server-2012R2" \
    --tags "Key=Environment,Value=Production" \
    --description "Windows Server 2012 R2, Important and Critical security updates" \
    --approved-patches "KB2032276,MS10-048" \
    --rejected-patches "KB2124261" \
    --rejected-patches-action "ALLOW_AS_DEPENDENCY" \
    --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```

------
#### [ Windows Server ]

```
aws ssm create-patch-baseline ^
    --name "Windows-Server-2012R2" ^
    --tags "Key=Environment,Value=Production" ^
    --description "Windows Server 2012 R2, Important and Critical security updates" ^
    --approved-patches "KB2032276,MS10-048" ^
    --rejected-patches "KB2124261" ^
    --rejected-patches-action "ALLOW_AS_DEPENDENCY" ^
    --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE"
}
```

### Erstellen einer Patch-Baseline mit benutzerdefinierten Repositorys für verschiedene Betriebssystemversionen
<a name="patch-manager-cli-commands-create-patch-baseline-mult-sources"></a>

Gilt nur für Linux-verwaltete Knoten. Der folgende Befehl zeigt, wie das Patch-Repository für eine bestimmte Version des Amazon Linux-Betriebssystems anzugeben ist. Dieses Beispiel verwendet ein standardmäßig aktiviertes Quell-Repository auf Amazon Linux 2017.09, könnte aber auf ein anderes Quell-Repository angepasst werden, das Sie für einen verwalteten Knoten konfiguriert haben.

**Anmerkung**  
Um diesen komplexeren Befehl besser zu erklären, wird die Option `--cli-input-json` mit zusätzlichen, in einer externen JSON-Datei gespeicherten Optionen verwendet.

1. Erstellen Sie eine JSON-Datei mit einem Namen wie `my-patch-repository.json` und fügen Sie den folgenden Inhalt hinzu.

   ```
   {
       "Description": "My patch repository for Amazon Linux 2",
       "Name": "Amazon-Linux-2",
       "OperatingSystem": "AMAZON_LINUX_2",
       "ApprovalRules": {
           "PatchRules": [
               {
                   "ApproveAfterDays": 7,
                   "EnableNonSecurity": true,
                   "PatchFilterGroup": {
                       "PatchFilters": [
                           {
                               "Key": "SEVERITY",
                               "Values": [
                                   "Important",
                                   "Critical"
                               ]
                           },
                           {
                               "Key": "CLASSIFICATION",
                               "Values": [
                                   "Security",
                                   "Bugfix"
                               ]
                           },
                           {
                               "Key": "PRODUCT",
                               "Values": [
                                   "AmazonLinux2"
                               ]
                           }
                       ]
                   }
               }
           ]
       },
       "Sources": [
           {
               "Name": "My-AL2",
               "Products": [
                   "AmazonLinux2"
               ],
               "Configuration": "[amzn-main] \nname=amzn-main-Base\nmirrorlist=http://repo./$awsregion./$awsdomain//$releasever/main/mirror.list //nmirrorlist_expire=300//nmetadata_expire=300 \npriority=10 \nfailovermethod=priority \nfastestmirror_enabled=0 \ngpgcheck=1 \ngpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-ga \nenabled=1 \nretries=3 \ntimeout=5\nreport_instanceid=yes"
           }
       ]
   }
   ```

1. Führen Sie im Verzeichnis, in dem Sie die Datei gespeichert haben, den folgenden Befehl aus.

   ```
   aws ssm create-patch-baseline --cli-input-json file://my-patch-repository.json
   ```

   Das System gibt unter anderem folgende Informationen zurück

   ```
   {
       "BaselineId": "pb-0c10e65780EXAMPLE"
   }
   ```

### Aktualisieren einer Patch-Baseline
<a name="patch-manager-cli-commands-update-patch-baseline"></a>

Mit dem folgenden Befehl werden zwei Patches abgelehnt und ein weiterer Patch für eine vorhandenen Patch-Baseline genehmigt.

Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).

------
#### [ Linux & macOS ]

```
aws ssm update-patch-baseline \
    --baseline-id pb-0c10e65780EXAMPLE \
    --rejected-patches "KB2032276" "MS10-048" \
    --approved-patches "KB2124261"
```

------
#### [ Windows Server ]

```
aws ssm update-patch-baseline ^
    --baseline-id pb-0c10e65780EXAMPLE ^
    --rejected-patches "KB2032276" "MS10-048" ^
    --approved-patches "KB2124261"
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE",
   "Name":"Windows-Server-2012R2",
   "RejectedPatches":[
      "KB2032276",
      "MS10-048"
   ],
   "GlobalFilters":{
      "PatchFilters":[

      ]
   },
   "ApprovalRules":{
      "PatchRules":[
         {
            "PatchFilterGroup":{
               "PatchFilters":[
                  {
                     "Values":[
                        "Important",
                        "Critical"
                     ],
                     "Key":"MSRC_SEVERITY"
                  },
                  {
                     "Values":[
                        "SecurityUpdates"
                     ],
                     "Key":"CLASSIFICATION"
                  },
                  {
                     "Values":[
                        "WindowsServer2012R2"
                     ],
                     "Key":"PRODUCT"
                  }
               ]
            },
            "ApproveAfterDays":5
         }
      ]
   },
   "ModifiedDate":1481001494.035,
   "CreatedDate":1480997823.81,
   "ApprovedPatches":[
      "KB2124261"
   ],
   "Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```

### Umbenennen einer Patch-Baseline
<a name="patch-manager-cli-commands-rename-patch-baseline"></a>

------
#### [ Linux & macOS ]

```
aws ssm update-patch-baseline \
    --baseline-id pb-0c10e65780EXAMPLE \
    --name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```

------
#### [ Windows Server ]

```
aws ssm update-patch-baseline ^
    --baseline-id pb-0c10e65780EXAMPLE ^
    --name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE",
   "Name":"Windows-Server-2012-R2-Important-and-Critical-Security-Updates",
   "RejectedPatches":[
      "KB2032276",
      "MS10-048"
   ],
   "GlobalFilters":{
      "PatchFilters":[

      ]
   },
   "ApprovalRules":{
      "PatchRules":[
         {
            "PatchFilterGroup":{
               "PatchFilters":[
                  {
                     "Values":[
                        "Important",
                        "Critical"
                     ],
                     "Key":"MSRC_SEVERITY"
                  },
                  {
                     "Values":[
                        "SecurityUpdates"
                     ],
                     "Key":"CLASSIFICATION"
                  },
                  {
                     "Values":[
                        "WindowsServer2012R2"
                     ],
                     "Key":"PRODUCT"
                  }
               ]
            },
            "ApproveAfterDays":5
         }
      ]
   },
   "ModifiedDate":1481001795.287,
   "CreatedDate":1480997823.81,
   "ApprovedPatches":[
      "KB2124261"
   ],
   "Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```

### Löschen einer Patch-Baseline
<a name="patch-manager-cli-commands-delete-patch-baseline"></a>

```
aws ssm delete-patch-baseline --baseline-id "pb-0c10e65780EXAMPLE"
```

Das System gibt unter anderem folgende Informationen zurück

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE"
}
```

### Auflisten aller Patch-Baselines
<a name="patch-manager-cli-commands-describe-patch-baselines"></a>

```
aws ssm describe-patch-baselines
```

Das System gibt unter anderem folgende Informationen zurück

```
{
   "BaselineIdentities":[
      {
         "BaselineName":"AWS-DefaultPatchBaseline",
         "DefaultBaseline":true,
         "BaselineDescription":"Default Patch Baseline Provided by AWS.",
         "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
      },
      {
         "BaselineName":"Windows-Server-2012R2",
         "DefaultBaseline":false,
         "BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
         "BaselineId":"pb-0c10e65780EXAMPLE"
      }
   ]
}
```

Nachstehend finden Sie einen weiteren Befehl zur Auflistung aller Patch-Baselines in einer AWS-Region.

------
#### [ Linux & macOS ]

```
aws ssm describe-patch-baselines \
    --region us-east-2 \
    --filters "Key=OWNER,Values=[All]"
```

------
#### [ Windows Server ]

```
aws ssm describe-patch-baselines ^
    --region us-east-2 ^
    --filters "Key=OWNER,Values=[All]"
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
   "BaselineIdentities":[
      {
         "BaselineName":"AWS-DefaultPatchBaseline",
         "DefaultBaseline":true,
         "BaselineDescription":"Default Patch Baseline Provided by AWS.",
         "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
      },
      {
         "BaselineName":"Windows-Server-2012R2",
         "DefaultBaseline":false,
         "BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
         "BaselineId":"pb-0c10e65780EXAMPLE"
      }
   ]
}
```

### Listet alle von AWS-bereitgestellten Patch-Baselines auf
<a name="patch-manager-cli-commands-describe-patch-baselines-aws"></a>

------
#### [ Linux & macOS ]

```
aws ssm describe-patch-baselines \
    --region us-east-2 \
    --filters "Key=OWNER,Values=[AWS]"
```

------
#### [ Windows Server ]

```
aws ssm describe-patch-baselines ^
    --region us-east-2 ^
    --filters "Key=OWNER,Values=[AWS]"
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
   "BaselineIdentities":[
      {
         "BaselineName":"AWS-DefaultPatchBaseline",
         "DefaultBaseline":true,
         "BaselineDescription":"Default Patch Baseline Provided by AWS.",
         "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
      }
   ]
}
```

### Auflisten der eigenen Patch-Baselines
<a name="patch-manager-cli-commands-describe-patch-baselines-custom"></a>

------
#### [ Linux & macOS ]

```
aws ssm describe-patch-baselines \
    --region us-east-2 \
    --filters "Key=OWNER,Values=[Self]"
```

------
#### [ Windows Server ]

```
aws ssm describe-patch-baselines ^
    --region us-east-2 ^
    --filters "Key=OWNER,Values=[Self]"
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
   "BaselineIdentities":[
      {
         "BaselineName":"Windows-Server-2012R2",
         "DefaultBaseline":false,
         "BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
         "BaselineId":"pb-0c10e65780EXAMPLE"
      }
   ]
}
```

### Anzeigen einer Patch-Baseline
<a name="patch-manager-cli-commands-get-patch-baseline"></a>

```
aws ssm get-patch-baseline --baseline-id pb-0c10e65780EXAMPLE
```

**Anmerkung**  
Bei benutzerdefinierten Patch-Baselines können Sie entweder die Patch-Baseline-ID oder den vollständigen Amazon-Ressourcennamen (ARN) angeben. Für eine von AWS-bereitgestellte Patch-Baseline müssen Sie den vollständigen ARN angeben. Beispiel, `arn:aws:ssm:us-east-2:075727635805:patchbaseline/pb-0c10e65780EXAMPLE`.

Das System gibt unter anderem folgende Informationen zurück

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE",
   "Name":"Windows-Server-2012R2",
   "PatchGroups":[
      "Web Servers"
   ],
   "RejectedPatches":[

   ],
   "GlobalFilters":{
      "PatchFilters":[

      ]
   },
   "ApprovalRules":{
      "PatchRules":[
         {
            "PatchFilterGroup":{
               "PatchFilters":[
                  {
                     "Values":[
                        "Important",
                        "Critical"
                     ],
                     "Key":"MSRC_SEVERITY"
                  },
                  {
                     "Values":[
                        "SecurityUpdates"
                     ],
                     "Key":"CLASSIFICATION"
                  },
                  {
                     "Values":[
                        "WindowsServer2012R2"
                     ],
                     "Key":"PRODUCT"
                  }
               ]
            },
            "ApproveAfterDays":5
         }
      ]
   },
   "ModifiedDate":1480997823.81,
   "CreatedDate":1480997823.81,
   "ApprovedPatches":[

   ],
   "Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```

### Abrufen einer Standard-Patch-Baseline
<a name="patch-manager-cli-commands-get-default-patch-baseline"></a>

```
aws ssm get-default-patch-baseline --region us-east-2
```

Das System gibt unter anderem folgende Informationen zurück

```
{
   "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```

### Eine benutzerdefinierte Patch-Baseline als Standard festlegen
<a name="patch-manager-cli-commands-register-default-patch-baseline"></a>

------
#### [ Linux & macOS ]

```
aws ssm register-default-patch-baseline \
    --region us-east-2 \
    --baseline-id "pb-0c10e65780EXAMPLE"
```

------
#### [ Windows Server ]

```
aws ssm register-default-patch-baseline ^
    --region us-east-2 ^
    --baseline-id "pb-0c10e65780EXAMPLE"
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE"
}
```

### Setzen Sie eine AWS Patch-Baseline als Standard zurück
<a name="patch-manager-cli-commands-register-aws-patch-baseline"></a>

------
#### [ Linux & macOS ]

```
aws ssm register-default-patch-baseline \
    --region us-east-2 \
    --baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```

------
#### [ Windows Server ]

```
aws ssm register-default-patch-baseline ^
    --region us-east-2 ^
    --baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE"
}
```

### Markieren einer Patch-Baseline
<a name="patch-manager-cli-commands-add-tags-to-resource"></a>

------
#### [ Linux & macOS ]

```
aws ssm add-tags-to-resource \
    --resource-type "PatchBaseline" \
    --resource-id "pb-0c10e65780EXAMPLE" \
    --tags "Key=Project,Value=Testing"
```

------
#### [ Windows Server ]

```
aws ssm add-tags-to-resource ^
    --resource-type "PatchBaseline" ^
    --resource-id "pb-0c10e65780EXAMPLE" ^
    --tags "Key=Project,Value=Testing"
```

------

### Auflisten aller Tags für eine Patch-Baseline
<a name="patch-manager-cli-commands-list-tags-for-resource"></a>

------
#### [ Linux & macOS ]

```
aws ssm list-tags-for-resource \
    --resource-type "PatchBaseline" \
    --resource-id "pb-0c10e65780EXAMPLE"
```

------
#### [ Windows Server ]

```
aws ssm list-tags-for-resource ^
    --resource-type "PatchBaseline" ^
    --resource-id "pb-0c10e65780EXAMPLE"
```

------

### Entfernen eines Tags aus einer Patch-Baseline
<a name="patch-manager-cli-commands-remove-tags-from-resource"></a>

------
#### [ Linux & macOS ]

```
aws ssm remove-tags-from-resource \
    --resource-type "PatchBaseline" \
    --resource-id "pb-0c10e65780EXAMPLE" \
    --tag-keys "Project"
```

------
#### [ Windows Server ]

```
aws ssm remove-tags-from-resource ^
    --resource-type "PatchBaseline" ^
    --resource-id "pb-0c10e65780EXAMPLE" ^
    --tag-keys "Project"
```

------

## AWS CLI Befehle für Patchgruppen
<a name="patch-group-cli-commands"></a>

**Topics**
+ [Erstellen einer Patch-Gruppe](#patch-manager-cli-commands-create-patch-group)
+ [Registrieren einer Patch-Gruppe „Webserver“ für eine Patch-Baseline](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-web-servers)
+ [Registrieren Sie eine Patch-Gruppe „Backend“ mit der bereitgestellten AWS Patch-Baseline](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-backend)
+ [Anzeigen der Registrierungen für Patch-Gruppen](#patch-manager-cli-commands-describe-patch-groups)
+ [Aufheben der Registrierung einer Patch-Gruppe für eine Patch-Baseline](#patch-manager-cli-commands-deregister-patch-baseline-for-patch-group)

### Erstellen einer Patch-Gruppe
<a name="patch-manager-cli-commands-create-patch-group"></a>

**Anmerkung**  
Patch-Gruppen werden nicht in Patch-Vorgängen verwendet, die auf *Patch-Richtlinien* basieren. Weitere Informationen zur Arbeit mit Patch-Richtlinien finden Sie unter [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md).

Um das Organisieren Ihrer Patching-Aufgaben zu erleichtern, empfehlen wir, dass Sie verwaltete Knoten mithilfe von Tags zu Patch-Gruppen hinzufügen. Patch-Gruppen erfordern die Nutzung des Tag-Schlüssels `Patch Group` oder `PatchGroup`. Wenn Sie [Tags in EC2-Instance-Metadaten zugelassen haben](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), müssen Sie `PatchGroup` (ohne Leerzeichen) verwenden. Sie können einen beliebigen Tag-Wert angeben, aber der Tag-Schlüssel muss `Patch Group` oder `PatchGroup` lauten. Weitere Informationen zu Patch-Gruppen finden Sie unter [Patch-Gruppen](patch-manager-patch-groups.md).

Nachdem Sie Ihre verwalteten Knoten mithilfe von Tags gruppiert haben, fügen Sie den Patch-Gruppenwert einer Patch-Baseline hinzu. Mit der Registrierung der Patch-Gruppe für eine Patch-Baseline können Sie sicherstellen, dass beim Einspielen von Patches die richtigen Patches installiert werden.

#### Aufgabe 1: Hinzufügen von EC2-Instances zu einer Patch-Gruppe mithilfe von Tags
<a name="create-patch-group-cli-1"></a>

**Anmerkung**  
Wenn Sie die Amazon Elastic Compute Cloud (Amazon EC2) -Konsole und verwenden AWS CLI, ist es möglich, `Key = PatchGroup` Or-Tags auf Instances anzuwenden`Key = Patch Group`, die noch nicht für die Verwendung mit Systems Manager konfiguriert sind. Wenn eine EC2-Instance, die Sie in Patch Manager erwarten, nach dem Anwenden des `Patch Group`-oder `Key = PatchGroup`-Tag nicht aufgeführt ist, finden Sie Tipps zur Fehlerbehebung unter [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md).

Führen Sie den folgenden Befehl aus, um das Tag `PatchGroup` einer EC2-Instance hinzuzufügen.

```
aws ec2 create-tags --resources "i-1234567890abcdef0" --tags "Key=PatchGroup,Value=GroupValue"
```

#### Aufgabe 2: Hinzufügen von verwalteten Knoten zu einer Patch-Gruppe mithilfe von Tags
<a name="create-patch-group-cli-2"></a>

Führen Sie den folgenden Befehl aus, um das Tag `PatchGroup` einem verwalteten Knoten hinzuzufügen.

------
#### [ Linux & macOS ]

```
aws ssm add-tags-to-resource \
    --resource-type "ManagedInstance" \
    --resource-id "mi-0123456789abcdefg" \
    --tags "Key=PatchGroup,Value=GroupValue"
```

------
#### [ Windows Server ]

```
aws ssm add-tags-to-resource ^
    --resource-type "ManagedInstance" ^
    --resource-id "mi-0123456789abcdefg" ^
    --tags "Key=PatchGroup,Value=GroupValue"
```

------

#### Aufgabe 3: Hinzufügen einer Patch-Gruppe zu einer Patch-Baseline
<a name="create-patch-group-cli-3"></a>

Führen Sie den folgenden Befehl aus, um der angegebenen Patch-Baseline einen `PatchGroup`-Tag-Wert zuzuordnen.

------
#### [ Linux & macOS ]

```
aws ssm register-patch-baseline-for-patch-group \
    --baseline-id "pb-0c10e65780EXAMPLE" \
    --patch-group "Development"
```

------
#### [ Windows Server ]

```
aws ssm register-patch-baseline-for-patch-group ^
    --baseline-id "pb-0c10e65780EXAMPLE" ^
    --patch-group "Development"
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
  "PatchGroup": "Development",
  "BaselineId": "pb-0c10e65780EXAMPLE"
}
```

### Registrieren einer Patch-Gruppe „Webserver“ für eine Patch-Baseline
<a name="patch-manager-cli-commands-register-patch-baseline-for-patch-group-web-servers"></a>

------
#### [ Linux & macOS ]

```
aws ssm register-patch-baseline-for-patch-group \
    --baseline-id "pb-0c10e65780EXAMPLE" \
    --patch-group "Web Servers"
```

------
#### [ Windows Server ]

```
aws ssm register-patch-baseline-for-patch-group ^
    --baseline-id "pb-0c10e65780EXAMPLE" ^
    --patch-group "Web Servers"
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
   "PatchGroup":"Web Servers",
   "BaselineId":"pb-0c10e65780EXAMPLE"
}
```

### Registrieren Sie eine Patch-Gruppe „Backend“ mit der bereitgestellten AWS Patch-Baseline
<a name="patch-manager-cli-commands-register-patch-baseline-for-patch-group-backend"></a>

------
#### [ Linux & macOS ]

```
aws ssm register-patch-baseline-for-patch-group \
    --region us-east-2 \
    --baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" \
    --patch-group "Backend"
```

------
#### [ Windows Server ]

```
aws ssm register-patch-baseline-for-patch-group ^
    --region us-east-2 ^
    --baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" ^
    --patch-group "Backend"
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
   "PatchGroup":"Backend",
   "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```

### Anzeigen der Registrierungen für Patch-Gruppen
<a name="patch-manager-cli-commands-describe-patch-groups"></a>

```
aws ssm describe-patch-groups --region us-east-2
```

Das System gibt unter anderem folgende Informationen zurück

```
{
   "PatchGroupPatchBaselineMappings":[
      {
         "PatchGroup":"Backend",
         "BaselineIdentity":{
            "BaselineName":"AWS-DefaultPatchBaseline",
            "DefaultBaseline":false,
            "BaselineDescription":"Default Patch Baseline Provided by AWS.",
            "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
         }
      },
      {
         "PatchGroup":"Web Servers",
         "BaselineIdentity":{
            "BaselineName":"Windows-Server-2012R2",
            "DefaultBaseline":true,
            "BaselineDescription":"Windows Server 2012 R2, Important and Critical updates",
            "BaselineId":"pb-0c10e65780EXAMPLE"
         }
      }
   ]
}
```

### Aufheben der Registrierung einer Patch-Gruppe für eine Patch-Baseline
<a name="patch-manager-cli-commands-deregister-patch-baseline-for-patch-group"></a>

------
#### [ Linux & macOS ]

```
aws ssm deregister-patch-baseline-for-patch-group \
    --region us-east-2 \
    --patch-group "Production" \
    --baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```

------
#### [ Windows Server ]

```
aws ssm deregister-patch-baseline-for-patch-group ^
    --region us-east-2 ^
    --patch-group "Production" ^
    --baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
   "PatchGroup":"Production",
   "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```

## AWS CLI Befehle zum Anzeigen von Patch-Zusammenfassungen und Details
<a name="patch-details-cli-commands"></a>

**Topics**
+ [Abrufen aller Patches, die in einer bestimmten Patch-Baseline definiert sind](#patch-manager-cli-commands-describe-effective-patches-for-patch-baseline)
+ [Holen Sie sich alle Patches für AmazonLinux 2018.03 mit einer Klassifizierung `SECURITY` und einem Schweregrad von `Critical`](#patch-manager-cli-commands-describe-available-patches-linux)
+ [Abrufen aller Patches für Windows Server 2012 mit einem MSRC-Schweregrad von `Critical`](#patch-manager-cli-commands-describe-available-patches)
+ [Abrufen aller verfügbaren Patches](#patch-manager-cli-commands-describe-available-patches)
+ [Abrufen der zusammengefassten Patch-Zustände pro verwalteten Knoten](#patch-manager-cli-commands-describe-instance-patch-states)
+ [Abrufen der Patch-Compliance-Details für einen verwalteten Knoten](#patch-manager-cli-commands-describe-instance-patches)
+ [Anzeigen der Patch-Compliance-Ergebnisse (AWS CLI)](#viewing-patch-compliance-results-cli)

### Abrufen aller Patches, die in einer bestimmten Patch-Baseline definiert sind
<a name="patch-manager-cli-commands-describe-effective-patches-for-patch-baseline"></a>

**Anmerkung**  
Dieser Befehl wird nur für Windows Server-Patch-Baselines unterstützt.

------
#### [ Linux & macOS ]

```
aws ssm describe-effective-patches-for-patch-baseline \
    --region us-east-2 \
    --baseline-id "pb-0c10e65780EXAMPLE"
```

------
#### [ Windows Server ]

```
aws ssm describe-effective-patches-for-patch-baseline ^
    --region us-east-2 ^
    --baseline-id "pb-0c10e65780EXAMPLE"
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
   "NextToken":"--token string truncated--",
   "EffectivePatches":[
      {
         "PatchStatus":{
            "ApprovalDate":1384711200.0,
            "DeploymentStatus":"APPROVED"
         },
         "Patch":{
            "ContentUrl":"https://support.microsoft.com/en-us/kb/2876331",
            "ProductFamily":"Windows",
            "Product":"WindowsServer2012R2",
            "Vendor":"Microsoft",
            "Description":"A security issue has been identified in a Microsoft software 
               product that could affect your system. You can help protect your system 
               by installing this update from Microsoft. For a complete listing of the 
               issues that are included in this update, see the associated Microsoft 
               Knowledge Base article. After you install this update, you may have to 
               restart your system.",
            "Classification":"SecurityUpdates",
            "Title":"Security Update for Windows Server 2012 R2 Preview (KB2876331)",
            "ReleaseDate":1384279200.0,
            "MsrcClassification":"Critical",
            "Language":"All",
            "KbNumber":"KB2876331",
            "MsrcNumber":"MS13-089",
            "Id":"e74ccc76-85f0-4881-a738-59e9fc9a336d"
         }
      },
      {
         "PatchStatus":{
            "ApprovalDate":1428858000.0,
            "DeploymentStatus":"APPROVED"
         },
         "Patch":{
            "ContentUrl":"https://support.microsoft.com/en-us/kb/2919355",
            "ProductFamily":"Windows",
            "Product":"WindowsServer2012R2",
            "Vendor":"Microsoft",
            "Description":"Windows Server 2012 R2 Update is a cumulative 
               set of security updates, critical updates and updates. You 
               must install Windows Server 2012 R2 Update to ensure that 
               your computer can continue to receive future Windows Updates, 
               including security updates. For a complete listing of the 
               issues that are included in this update, see the associated 
               Microsoft Knowledge Base article for more information. After 
               you install this item, you may have to restart your computer.",
            "Classification":"SecurityUpdates",
            "Title":"Windows Server 2012 R2 Update (KB2919355)",
            "ReleaseDate":1428426000.0,
            "MsrcClassification":"Critical",
            "Language":"All",
            "KbNumber":"KB2919355",
            "MsrcNumber":"MS14-018",
            "Id":"8452bac0-bf53-4fbd-915d-499de08c338b"
         }
      }
     ---output truncated---
```

### Holen Sie sich alle Patches für AmazonLinux 2018.03 mit einer Klassifizierung `SECURITY` und einem Schweregrad von `Critical`
<a name="patch-manager-cli-commands-describe-available-patches-linux"></a>

------
#### [ Linux & macOS ]

```
aws ssm describe-available-patches \
    --region us-east-2 \
    --filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```

------
#### [ Windows Server ]

```
aws ssm describe-available-patches ^
    --region us-east-2 ^
    --filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
    "Patches": [
        {
            "AdvisoryIds": ["ALAS-2011-1"],
            "BugzillaIds": [ "1234567" ],
            "Classification": "SECURITY",
            "CVEIds": [ "CVE-2011-3192"],
            "Name": "zziplib",
            "Epoch": "0",
            "Version": "2.71",
            "Release": "1.3.amzn1",
            "Arch": "i686",
            "Product": "AmazonLinux2018.03",
            "ReleaseDate": 1590519815,
            "Severity": "CRITICAL"
        }
    ]
}     
---output truncated---
```

### Abrufen aller Patches für Windows Server 2012 mit einem MSRC-Schweregrad von `Critical`
<a name="patch-manager-cli-commands-describe-available-patches"></a>

------
#### [ Linux & macOS ]

```
aws ssm describe-available-patches \
    --region us-east-2 \
    --filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```

------
#### [ Windows Server ]

```
aws ssm describe-available-patches ^
    --region us-east-2 ^
    --filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
   "Patches":[
      {
         "ContentUrl":"https://support.microsoft.com/en-us/kb/2727528",
         "ProductFamily":"Windows",
         "Product":"WindowsServer2012",
         "Vendor":"Microsoft",
         "Description":"A security issue has been identified that could 
           allow an unauthenticated remote attacker to compromise your 
           system and gain control over it. You can help protect your 
           system by installing this update from Microsoft. After you 
           install this update, you may have to restart your system.",
         "Classification":"SecurityUpdates",
         "Title":"Security Update for Windows Server 2012 (KB2727528)",
         "ReleaseDate":1352829600.0,
         "MsrcClassification":"Critical",
         "Language":"All",
         "KbNumber":"KB2727528",
         "MsrcNumber":"MS12-072",
         "Id":"1eb507be-2040-4eeb-803d-abc55700b715"
      },
      {
         "ContentUrl":"https://support.microsoft.com/en-us/kb/2729462",
         "ProductFamily":"Windows",
         "Product":"WindowsServer2012",
         "Vendor":"Microsoft",
         "Description":"A security issue has been identified that could 
           allow an unauthenticated remote attacker to compromise your 
           system and gain control over it. You can help protect your 
           system by installing this update from Microsoft. After you 
           install this update, you may have to restart your system.",
         "Classification":"SecurityUpdates",
         "Title":"Security Update for Microsoft .NET Framework 3.5 on 
           Windows 8 and Windows Server 2012 for x64-based Systems (KB2729462)",
         "ReleaseDate":1352829600.0,
         "MsrcClassification":"Critical",
         "Language":"All",
         "KbNumber":"KB2729462",
         "MsrcNumber":"MS12-074",
         "Id":"af873760-c97c-4088-ab7e-5219e120eab4"
      }
     
---output truncated---
```

### Abrufen aller verfügbaren Patches
<a name="patch-manager-cli-commands-describe-available-patches"></a>

```
aws ssm describe-available-patches --region us-east-2
```

Das System gibt unter anderem folgende Informationen zurück

```
{
   "NextToken":"--token string truncated--",
   "Patches":[
      {
            "Classification": "SecurityUpdates",
            "ContentUrl": "https://support.microsoft.com/en-us/kb/4074588",
            "Description": "A security issue has been identified in a Microsoft software 
            product that could affect your system. You can help protect your system by 
            installing this update from Microsoft. For a complete listing of the issues 
            that are included in this update, see the associated Microsoft Knowledge Base 
            article. After you install this update, you may have to restart your system.",
            "Id": "11adea10-0701-430e-954f-9471595ae246",
            "KbNumber": "KB4074588",
            "Language": "All",
            "MsrcNumber": "",
            "MsrcSeverity": "Critical",
            "Product": "WindowsServer2016",
            "ProductFamily": "Windows",
            "ReleaseDate": 1518548400,
            "Title": "2018-02 Cumulative Update for Windows Server 2016 (1709) for x64-based 
            Systems (KB4074588)",
            "Vendor": "Microsoft"
        },
        {
            "Classification": "SecurityUpdates",
            "ContentUrl": "https://support.microsoft.com/en-us/kb/4074590",
            "Description": "A security issue has been identified in a Microsoft software 
            product that could affect your system. You can help protect your system by 
            installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.",
            "Id": "f5f58231-ac5d-4640-ab1b-9dc8d857c265",
            "KbNumber": "KB4074590",
            "Language": "All",
            "MsrcNumber": "",
            "MsrcSeverity": "Critical",
            "Product": "WindowsServer2016",
            "ProductFamily": "Windows",
            "ReleaseDate": 1518544805,
            "Title": "2018-02 Cumulative Update for Windows Server 2016 for x64-based 
            Systems (KB4074590)",
            "Vendor": "Microsoft"
        }
      ---output truncated---
```

### Abrufen der zusammengefassten Patch-Zustände pro verwalteten Knoten
<a name="patch-manager-cli-commands-describe-instance-patch-states"></a>

Die Zusammenfassung pro verwaltetem Knoten gibt Ihnen die Anzahl der Patches in den folgenden Zuständen pro Knoten an: "NotApplicable„, „Fehlend“, „Fehlgeschlagen“, "InstalledOther" und „Installiert“. 

------
#### [ Linux & macOS ]

```
aws ssm describe-instance-patch-states \
    --instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```

------
#### [ Windows Server ]

```
aws ssm describe-instance-patch-states ^
    --instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
   "InstancePatchStates":[
      {
            "InstanceId": "i-08ee91c0b17045407",
            "PatchGroup": "",
            "BaselineId": "pb-0c10e65780EXAMPLE",
            "SnapshotId": "6d03d6c5-f79d-41d0-8d0e-00a9aEXAMPLE",
            "InstalledCount": 50,
            "InstalledOtherCount": 353,
            "InstalledPendingRebootCount": 0,
            "InstalledRejectedCount": 0,
            "MissingCount": 0,
            "FailedCount": 0,
            "UnreportedNotApplicableCount": -1,
            "NotApplicableCount": 671,
            "OperationStartTime": "2020-01-24T12:37:56-08:00",
            "OperationEndTime": "2020-01-24T12:37:59-08:00",
            "Operation": "Scan",
            "RebootOption": "NoReboot"
        },
        {
            "InstanceId": "i-09a618aec652973a9",
            "PatchGroup": "",
            "BaselineId": "pb-0c10e65780EXAMPLE",
            "SnapshotId": "c7e0441b-1eae-411b-8aa7-973e6EXAMPLE",
            "InstalledCount": 36,
            "InstalledOtherCount": 396,
            "InstalledPendingRebootCount": 0,
            "InstalledRejectedCount": 0,
            "MissingCount": 3,
            "FailedCount": 0,
            "UnreportedNotApplicableCount": -1,
            "NotApplicableCount": 420,
            "OperationStartTime": "2020-01-24T12:37:34-08:00",
            "OperationEndTime": "2020-01-24T12:37:37-08:00",
            "Operation": "Scan",
            "RebootOption": "NoReboot"
        }
     ---output truncated---
```

### Abrufen der Patch-Compliance-Details für einen verwalteten Knoten
<a name="patch-manager-cli-commands-describe-instance-patches"></a>

```
aws ssm describe-instance-patches --instance-id i-08ee91c0b17045407
```

Das System gibt unter anderem folgende Informationen zurück

```
{
   "NextToken":"--token string truncated--",
   "Patches":[
      {
            "Title": "bind-libs.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
            "KBId": "bind-libs.x86_64",
            "Classification": "Security",
            "Severity": "Important",
            "State": "Installed",
            "InstalledTime": "2019-08-26T11:05:24-07:00"
        },
        {
            "Title": "bind-utils.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
            "KBId": "bind-utils.x86_64",
            "Classification": "Security",
            "Severity": "Important",
            "State": "Installed",
            "InstalledTime": "2019-08-26T11:05:32-07:00"
        },
        {
            "Title": "dhclient.x86_64:12:4.1.1-53.P1.28.amzn1",
            "KBId": "dhclient.x86_64",
            "Classification": "Security",
            "Severity": "Important",
            "State": "Installed",
            "InstalledTime": "2019-08-26T11:05:31-07:00"
        },
    ---output truncated---
```

### Anzeigen der Patch-Compliance-Ergebnisse (AWS CLI)
<a name="viewing-patch-compliance-results-cli"></a>

**Anzeigen von Patch-Compliance-Ergebnissen für einen einzelnen verwalteten Knoten**

Führen Sie den folgenden Befehl in AWS Command Line Interface (AWS CLI) aus, um die Ergebnisse der Patch-Konformität für einen einzelnen verwalteten Knoten anzuzeigen.

```
aws ssm describe-instance-patch-states --instance-id instance-id
```

*instance-id*Ersetzen Sie ihn durch die ID des verwalteten Knotens, für den Sie Ergebnisse anzeigen möchten, im Format `i-02573cafcfEXAMPLE` oder`mi-0282f7c436EXAMPLE`.

Das System gibt unter anderem folgende Informationen zurück.

```
{
    "InstancePatchStates": [
        {
            "InstanceId": "i-02573cafcfEXAMPLE",
            "PatchGroup": "mypatchgroup",
            "BaselineId": "pb-0c10e65780EXAMPLE",            
            "SnapshotId": "a3f5ff34-9bc4-4d2c-a665-4d1c1EXAMPLE",
            "CriticalNonCompliantCount": 2,
            "SecurityNonCompliantCount": 2,
            "OtherNonCompliantCount": 1,
            "InstalledCount": 123,
            "InstalledOtherCount": 334,
            "InstalledPendingRebootCount": 0,
            "InstalledRejectedCount": 0,
            "MissingCount": 1,
            "FailedCount": 2,
            "UnreportedNotApplicableCount": 11,
            "NotApplicableCount": 2063,
            "OperationStartTime": "2021-05-03T11:00:56-07:00",
            "OperationEndTime": "2021-05-03T11:01:09-07:00",
            "Operation": "Scan",
            "LastNoRebootInstallOperationTime": "2020-06-14T12:17:41-07:00",
            "RebootOption": "RebootIfNeeded"
        }
    ]
}
```

**So zeigen Sie eine Patch-Anzahl-Zusammenfassung für alle EC2-Instances in einer Region an**

Der `describe-instance-patch-states` unterstützt das Abrufen von Ergebnissen für jeweils eine verwaltete Instance. Wenn Sie jedoch ein benutzerdefiniertes Skript mit dem `describe-instance-patch-states`-Befehl verwenden, können Sie einen detaillierteren Bericht erstellen.

Wenn zum Beispiel das [jq filter tool](https://stedolan.github.io/jq/download/) auf Ihrem lokalen Computer installiert ist, können Sie den folgenden Befehl ausführen, um zu ermitteln, welche Ihrer EC2-Instances in einer bestimmten AWS-Region einen Status von `InstalledPendingReboot` haben.

```
aws ssm describe-instance-patch-states \
    --instance-ids $(aws ec2 describe-instances --region region | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
    --output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```

*region*stellt den Bezeichner für eine Region dar AWS Systems Manager, die von AWS-Region unterstützt wird, z. B. `us-east-2` für die Region USA Ost (Ohio). Eine Liste der unterstützten *region* Werte finden Sie in der Spalte **Region** der [Systems Manager Manager-Dienstendpunkte](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) in der *Allgemeine Amazon Web Services-Referenz*.

Beispiel:

```
aws ssm describe-instance-patch-states \
    --instance-ids $(aws ec2 describe-instances --region us-east-2 | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
    --output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```

Das System gibt unter anderem folgende Informationen zurück

```
1       i-02573cafcfEXAMPLE
0       i-0471e04240EXAMPLE
3       i-07782c72faEXAMPLE
6       i-083b678d37EXAMPLE
0       i-03a530a2d4EXAMPLE
1       i-01f68df0d0EXAMPLE
0       i-0a39c0f214EXAMPLE
7       i-0903a5101eEXAMPLE
7       i-03823c2fedEXAMPLE
```

Zusätzlich zu `InstalledPendingRebootCount` können Sie nach den folgenden Anzahltypen suchen:
+ `CriticalNonCompliantCount`
+ `SecurityNonCompliantCount`
+ `OtherNonCompliantCount`
+ `UnreportedNotApplicableCount `
+ `InstalledPendingRebootCount`
+ `FailedCount`
+ `NotApplicableCount`
+ `InstalledRejectedCount`
+ `InstalledOtherCount`
+ `MissingCount`
+ `InstalledCount`

## AWS CLI Befehle zum Scannen und Patchen verwalteter Knoten
<a name="patch-operations-cli-commands"></a>

Nachdem Sie die folgenden Befehle ausgeführt haben, um nach Patch-Compliance zu scannen oder Patches zu installieren, können Sie mit Befehlen im [AWS CLI Befehle zum Anzeigen von Patch-Zusammenfassungen und Details](#patch-details-cli-commands)-Abschnitt Informationen zu Patch-Status und -Compliance anzeigen.

**Topics**
+ [Verwaltete Knoten auf Patch-Compliance scannen (AWS CLI)](#patch-operations-scan)
+ [Installieren von Patches auf verwalteten Knoten (AWS CLI)](#patch-operations-install-cli)

### Verwaltete Knoten auf Patch-Compliance scannen (AWS CLI)
<a name="patch-operations-scan"></a>

**So scannen Sie spezifische verwaltete Knoten auf Patch-Compliance**

Führen Sie den folgenden Befehl aus.

------
#### [ Linux & macOS ]

```
aws ssm send-command \
    --document-name 'AWS-RunPatchBaseline' \
    --targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
    --parameters 'Operation=Scan' \
    --timeout-seconds 600
```

------
#### [ Windows Server ]

```
aws ssm send-command ^
    --document-name "AWS-RunPatchBaseline" ^
    --targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
    --parameters "Operation=Scan" ^
    --timeout-seconds 600
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
    "Command": {
        "CommandId": "a04ed06c-8545-40f4-87c2-a0babEXAMPLE",
        "DocumentName": "AWS-RunPatchBaseline",
        "DocumentVersion": "$DEFAULT",
        "Comment": "",
        "ExpiresAfter": 1621974475.267,
        "Parameters": {
            "Operation": [
                "Scan"
            ]
        },
        "InstanceIds": [],
        "Targets": [
            {
                "Key": "InstanceIds",
                "Values": [
                    "i-02573cafcfEXAMPLE,
                     i-0471e04240EXAMPLE"
                ]
            }
        ],
        "RequestedDateTime": 1621952275.267,
        "Status": "Pending",
        "StatusDetails": "Pending",
        "TimeoutSeconds": 600,

    ---output truncated---

    }
}
```

**So scannen Sie verwaltete Knoten nach Patch-Gruppentag auf Patch-Compliance**

Führen Sie den folgenden Befehl aus.

------
#### [ Linux & macOS ]

```
aws ssm send-command \
    --document-name 'AWS-RunPatchBaseline' \
    --targets Key='tag:PatchGroup',Values='Web servers' \
    --parameters 'Operation=Scan' \
    --timeout-seconds 600
```

------
#### [ Windows Server ]

```
aws ssm send-command ^
    --document-name "AWS-RunPatchBaseline" ^
    --targets Key="tag:PatchGroup",Values="Web servers" ^
    --parameters "Operation=Scan" ^
    --timeout-seconds 600
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
    "Command": {
        "CommandId": "87a448ee-8adc-44e0-b4d1-6b429EXAMPLE",
        "DocumentName": "AWS-RunPatchBaseline",
        "DocumentVersion": "$DEFAULT",
        "Comment": "",
        "ExpiresAfter": 1621974983.128,
        "Parameters": {
            "Operation": [
                "Scan"
            ]
        },
        "InstanceIds": [],
        "Targets": [
            {
                "Key": "tag:PatchGroup",
                "Values": [
                    "Web servers"
                ]
            }
        ],
        "RequestedDateTime": 1621952783.128,
        "Status": "Pending",
        "StatusDetails": "Pending",
        "TimeoutSeconds": 600,

    ---output truncated---

    }
}
```

### Installieren von Patches auf verwalteten Knoten (AWS CLI)
<a name="patch-operations-install-cli"></a>

**So installieren Sie Patches auf spezifischen verwalteten Knoten**

Führen Sie den folgenden Befehl aus. 

**Anmerkung**  
Die anvisierten verwalteten Knoten werden nach Bedarf neu gestartet, um die Patch-Installation abzuschließen. Weitere Informationen finden Sie unter [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).

------
#### [ Linux & macOS ]

```
aws ssm send-command \
    --document-name 'AWS-RunPatchBaseline' \
    --targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
    --parameters 'Operation=Install' \
    --timeout-seconds 600
```

------
#### [ Windows Server ]

```
aws ssm send-command ^
    --document-name "AWS-RunPatchBaseline" ^
    --targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
    --parameters "Operation=Install" ^
    --timeout-seconds 600
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
    "Command": {
        "CommandId": "5f403234-38c4-439f-a570-93623EXAMPLE",
        "DocumentName": "AWS-RunPatchBaseline",
        "DocumentVersion": "$DEFAULT",
        "Comment": "",
        "ExpiresAfter": 1621975301.791,
        "Parameters": {
            "Operation": [
                "Install"
            ]
        },
        "InstanceIds": [],
        "Targets": [
            {
                "Key": "InstanceIds",
                "Values": [
                    "i-02573cafcfEXAMPLE,
                     i-0471e04240EXAMPLE"
                ]
            }
        ],
        "RequestedDateTime": 1621953101.791,
        "Status": "Pending",
        "StatusDetails": "Pending",
        "TimeoutSeconds": 600,

    ---output truncated---

    }
}
```

**So installieren Sie Patches auf verwalteten Knoten in einer spezifischen Patch-Gruppe**

Führen Sie den folgenden Befehl aus.

------
#### [ Linux & macOS ]

```
aws ssm send-command \
    --document-name 'AWS-RunPatchBaseline' \
    --targets Key='tag:PatchGroup',Values='Web servers' \
    -parameters 'Operation=Install' \
    --timeout-seconds 600
```

------
#### [ Windows Server ]

```
aws ssm send-command ^
    --document-name "AWS-RunPatchBaseline" ^
    --targets Key="tag:PatchGroup",Values="Web servers" ^
    --parameters "Operation=Install" ^
    --timeout-seconds 600
```

------

Das System gibt unter anderem folgende Informationen zurück

```
{
    "Command": {
        "CommandId": "fa44b086-7d36-4ad5-ac8d-627ecEXAMPLE",
        "DocumentName": "AWS-RunPatchBaseline",
        "DocumentVersion": "$DEFAULT",
        "Comment": "",
        "ExpiresAfter": 1621975407.865,
        "Parameters": {
            "Operation": [
                "Install"
            ]
        },
        "InstanceIds": [],
        "Targets": [
            {
                "Key": "tag:PatchGroup",
                "Values": [
                    "Web servers"
                ]
            }
        ],
        "RequestedDateTime": 1621953207.865,
        "Status": "Pending",
        "StatusDetails": "Pending",
        "TimeoutSeconds": 600,

    ---output truncated---

    }
}
```

# AWS Systems Manager Patch Manager Tutorials
<a name="patch-manager-tutorials"></a>

Die Tutorials in diesem Abschnitt zeigenPatch Manager, wie Sie ein Tool in AWS Systems Manager verschiedenen Patch-Szenarien verwenden können.

**Topics**
+ [Tutorial: Einen Server in einer IPv6 einzigen Umgebung patchen](patch-manager-server-patching-iPv6-tutorial.md)
+ [So erstellen Sie eine Patch-Baseline für die Installation von Windows Service Packs mithilfe der Konsole](patch-manager-windows-service-pack-patch-baseline-tutorial.md)
+ [Tutorial: Aktualisieren von Anwendungsabhängigkeiten, Patchen eines verwalteten Knotens und Durchführen einer anwendungsspezifischen Zustandsprüfung mithilfe der Konsole](aws-runpatchbaselinewithhooks-tutorial.md)
+ [Tutorial: Patchen Sie eine Serverumgebung mit dem AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md)

# Tutorial: Einen Server in einer IPv6 einzigen Umgebung patchen
<a name="patch-manager-server-patching-iPv6-tutorial"></a>

Patch Managerunterstützt das Patchen von Knoten in Umgebungen, in denen nur IPv6 Durch die Aktualisierung der SSM Agent Konfiguration können Patch-Vorgänge so konfiguriert werden, dass nur Aufrufe an IPv6 Dienstendpunkte getätigt werden.

**Um einen Server in einer IPv6 reinen Umgebung zu patchen**

1. Stellen Sie sicher, dass SSM Agent Version 3.3270.0 oder höher auf dem verwalteten Knoten installiert ist.

1. Navigieren Sie auf dem verwalteten Knoten zur Konfigurationsdatei. SSM Agent Sie finden die `amazon-ssm-agent.json` Datei in den folgenden Verzeichnissen:
   + Linux: `/etc/amazon/ssm/`
   + macOS: `/opt/aws/ssm/`
   + Windows Server: `C:\Program Files\Amazon\SSM`

   Falls sie noch nicht `amazon-ssm-agent.json` existiert, kopieren Sie den Inhalt von `amazon-ssm-agent.json.template` unter demselben Verzeichnis nach`amazon-ssm-agent.json`.

1. Aktualisieren Sie den folgenden Eintrag, um die richtige Region festzulegen, und stellen Sie ihn `UseDualStackEndpoint` auf ein`true`:

   ```
   {
    --------
       "Agent": {
           "Region": "region",
           "UseDualStackEndpoint": true
       },
   --------
   }
   ```

1. Starten Sie den SSM Agent Dienst mit dem entsprechenden Befehl für Ihr Betriebssystem neu:
   + Linux: `sudo systemctl restart amazon-ssm-agent`
   + Ubuntu Servermit Snap: `sudo snap restart amazon-ssm-agent`
   + macOS: `sudo launchctl stop com.amazon.aws.ssm` gefolgt von `sudo launchctl start com.amazon.aws.ssm`
   + Windows Server: `Stop-Service AmazonSSMAgent` gefolgt von `Start-Service AmazonSSMAgent`

   Die vollständige Liste der Befehle pro Betriebssystem finden Sie unter[Prüfen des SSM Agent-Status und Starten des Agenten](ssm-agent-status-and-restart.md).

1. Führen Sie einen beliebigen Patchvorgang aus, um sicherzustellen, dass die Patchvorgänge in Ihrer reinen Umgebung erfolgreich sind IPv6. Stellen Sie sicher, dass die Knoten, für die gepatcht wird, eine Verbindung zur Patch-Quelle haben. Sie können die Run Command Ausgabe der Patching-Ausführung überprüfen, um nach Warnungen zu unzugänglichen Repositorys zu suchen. Achten Sie beim Patchen eines Knotens, der in einer IPv6 reinen Umgebung läuft, darauf, dass der Knoten mit der Patch-Quelle verbunden ist. Sie können die Run Command Ausgabe der Patching-Ausführung überprüfen, um nach Warnungen zu unzugänglichen Repositorys zu suchen. Für DNF-basierte Betriebssysteme ist es möglich, nicht verfügbare Repositorys so zu konfigurieren, dass sie beim Patchen übersprungen werden, wenn die Option auf unter gesetzt ist. `skip_if_unavailable` `True` `/etc/dnf/dnf.conf` Zu den DNF-basierten Betriebssystemen gehören Amazon Linux 2023, Red Hat Enterprise Linux 8 und spätere Versionen, Oracle Linux Rocky Linux AlmaLinux, und CentOS 8 und spätere Versionen. Unter Amazon Linux 2023 ist die `skip_if_unavailable` Option `True` standardmäßig auf eingestellt.
**Anmerkung**  
 Wenn Sie die Funktionen Install Override List oder Baseline Override verwenden, stellen Sie sicher, dass die angegebene URL vom Knoten aus erreichbar ist. Wenn die SSM Agent Konfigurationsoption auf gesetzt `UseDualStackEndpoint` ist`true`, wird ein Dual-Stack-S3-Client verwendet, wenn eine S3-URL bereitgestellt wird.

# So erstellen Sie eine Patch-Baseline für die Installation von Windows Service Packs mithilfe der Konsole
<a name="patch-manager-windows-service-pack-patch-baseline-tutorial"></a>

Wenn Sie eine benutzerdefinierte Patch-Baseline erstellen, können Sie angeben, ob alle, einige oder nur ein einziger unterstützter Patch-Typ installiert wird.

In den Patch-Baselines für Windows können Sie `ServicePacks` als einzige **Klassifizierungsoption** auswählen, um Patching-Updates auf Service Packs einzuschränken. Service Packs können automatisch mit Patch Manager einem Tool in installiert werden AWS Systems Manager, sofern das Update in Windows Update oder Windows Server Update Services (WSUS) verfügbar ist.

Sie können eine Patch-Baseline konfigurieren, um festzulegen, ob Service Packs für alle Windows-Versionen oder nur für bestimmte Windows-Versionen installiert werden, z. B. Windows 7 oder Windows Server 2016. 

Gehen Sie wie folgt vor, um eine benutzerdefinierte Patch-Baseline zu erstellen, die ausschließlich für die Installation aller Service Packs auf Ihren Windows-verwalteten Knoten verwendet wird. 

**So erstellen Sie eine Patch-Baseline für die Installation von Windows Service Packs (Konsole)**

1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)

1. Wählen Sie im Navigationsbereich **Patch Manager** aus.

1. Wählen Sie die Registerkarte **Patch-Baselines** und dann **Patch-Baseline erstellen** aus. 

1. Geben Sie im Feld **Name** einen Namen für die neue Patch-Baseline ein, z. B. `MyWindowsServicePackPatchBaseline`.

1. (Optional) Geben Sie im Feld **Beschreibung** eine Beschreibung für diese Patch-Baseline ein.

1. Wählen Sie unter **Betriebssystem** die Option `Windows` aus.

1. Wenn Sie diese Patch-Baseline direkt nach dem Erstellen als Standard für Windows verwenden möchten, wählen Sie **Set this patch baseline as the default patch baseline for Windows Server instances (Diese Patch-Baseline als Standard-Patch-Baseline für Windows Server-Instances festlegen)** aus.
**Anmerkung**  
Diese Option ist nur verfügbar, wenn Sie vor der Veröffentlichung der [Patch-Richtlinien](patch-manager-policies.md) am 22. Dezember 2022 zum ersten Mal auf Patch Manager zugegriffen haben.  
Weitere Informationen zum Festlegen einer vorhandenen Patch-Baseline als Standard finden Sie unter [Festlegen einer vorhandenen Patch-Baseline als Standard](patch-manager-default-patch-baseline.md).

1. Erstellen Sie im Abschnitt **Approval Rules for operating-systems (Genehmigungsregeln für Betriebssysteme)** unter Verwendung der Felder ein oder mehrere automatische Genehmigungsregeln.
   + **Produkte**: Die Betriebssystemversionen, auf die sich die Genehmigungsregel bezieht, z. B. `WindowsServer2012`. Sie können eine, mehr als eine oder alle unterstützten Windows-Versionen auswählen. Die Standardauswahl ist `All`.
   + **Classification (Klassifizierung)**: Wählen Sie `ServicePacks` aus. 
   + **Severity (Schweregrad)**: Der Schweregradwert der Patches, auf die die Regel angewendet werden soll. Um sicherzustellen, dass alle Service Packs von der Regel eingeschlossen werden, wählen Sie `All` aus. 
   + **Automatische Genehmigung**: Die Methode zum Auswählen von Patches für die automatische Genehmigung.
     + **Patches nach einer bestimmten Anzahl von Tagen genehmigen**: Die Anzahl der Tage, die der Patch Manager warten muss, nachdem ein Patch veröffentlicht oder aktualisiert wurde, bevor ein Patch automatisch genehmigt wird. Sie können jede Ganzzahl von Null (0) bis 360 eingeben. Für die meisten Szenarien empfehlen wir, nicht länger als 100 Tage zu warten.
     + **Patches genehmigen, die bis zu einem bestimmten Datum veröffentlicht wurden**: Das Datum der Patch-Veröffentlichung, an dem der Patch Manager automatisch alle Patches anwendet, die bis zu diesem Datum veröffentlicht oder aktualisiert wurden. Wenn Sie beispielsweise den 07. Juli 2023 angeben, werden Patches, die am oder nach dem 08. Juli 2023 veröffentlicht oder zuletzt aktualisiert wurden, nicht automatisch installiert.
   + (Optional) **Compliance reporting (Compliance-Berichte)**: Der Schweregrad, den Sie Service Packs zuweisen möchten, die von der Baseline genehmigt wurden, z. B. `High`.
**Anmerkung**  
Wenn Sie eine Konformitätsberichtsstufe angeben und der Patch-Status eines genehmigten Service-Packs als `Missing` gemeldet wird, dann entspricht der insgesamt gemeldete Konformitätsschweregrad der Patch-Baseline dem von Ihnen angegebenen Schweregrad.

1. (Optional) Wenden **Sie unter Tags verwalten** ein oder mehrere name/value Tag-Schlüsselpaare auf die Patch-Baseline an.

   Tags sind optionale Metadaten, die Sie einer Ressource zuweisen. Mithilfe von Tags können Sie eine Ressource unterschiedlich kategorisieren, beispielsweise nach Zweck, Besitzer oder Umgebung. Für diese Patch-Baseline, die der Aktualisierung von Service Packs gewidmet ist, könnten Sie Schlüssel-Wert-Paare angeben, z. B.:
   + `Key=OS,Value=Windows`
   + `Key=Classification,Value=ServicePacks`

1. Wählen Sie die Option **Patch-Baseline erstellen**.

# Tutorial: Aktualisieren von Anwendungsabhängigkeiten, Patchen eines verwalteten Knotens und Durchführen einer anwendungsspezifischen Zustandsprüfung mithilfe der Konsole
<a name="aws-runpatchbaselinewithhooks-tutorial"></a>

In vielen Fällen muss ein verwalteter Knoten neu gestartet werden, nachdem er mit dem neuesten Softwareupdate gepatcht wurde. Ein Neustart eines verwalteten Knotens in der Produktion ohne vorhandene Sicherheitsvorkehrungen kann jedoch mehrere Probleme verursachen, z. B. das Aufrufen von Alarmen, das Aufzeichnen falscher Metrikdaten und das Unterbrechen von Datensynchronisationen.

Diese Anleitung zeigt, wie Sie Probleme wie diese vermeiden können, indem Sie das AWS Systems Manager -Dokument (SSM-Dokument) `AWS-RunPatchBaselineWithHooks` verwenden, um einen komplexen, mehrstufigen Patchvorgang zu erreichen, der Folgendes ausführt:

1. Verhindern neuer Verbindungen mit der Anwendung

1. Installieren von Betriebssystem-Updates

1. Aktualisieren der Paketabhängigkeiten der Anwendung

1. Neustart des Systems

1. Durchführen einer anwendungsspezifischen Zustandsprüfung

Für dieses Beispiel haben wir unsere Infrastruktur auf diese Weise eingerichtet:
+ Die anvisierten virtuellen Maschinen werden als verwaltete Knoten mit Systems Manager registriert.
+ `Iptables` wird als lokale Firewall verwendet.
+ Die auf den verwalteten Knoten gehostete Anwendung wird auf Port 443 ausgeführt.
+ Die Anwendung, die auf den verwalteten Knoten gehostet wird, ist eine `nodeJS`-Anwendung.
+ Die auf den verwalteten Knoten gehostete Anwendung wird vom pm2-Prozessmanager verwaltet.
+ Die Anwendung verfügt bereits über einen angegebenen Zustandsprüfungs-Endpunkt.
+ Der Endpunkt der Zustandsprüfung der Anwendung erfordert keine Endbenutzerauthentifizierung. Der Endpunkt ermöglicht eine Zustandsprüfung, die die Anforderungen der Organisation beim Festlegen der Verfügbarkeit erfüllt. (In Ihrer Umgebung reicht es möglicherweise aus, sicherzustellen, dass die `nodeJS`-Anwendung ausgeführt wird und in der Lage ist, auf Anfragen zu warten. In anderen Fällen möchten Sie möglicherweise überprüfen, ob bereits eine Verbindung zur Caching-Ebene oder zur Datenbankebene hergestellt wurde).

Die Beispiele in dieser Anleitung dienen nur zu Demonstrationszwecken und sind nicht dafür gedacht, in Produktionsumgebungen implementiert zu werden. Beachten Sie auch, dass das Lebenszyklus-Hook-Feature von Patch Manager, einem Tool in Systems Manager, mit dem `AWS-RunPatchBaselineWithHooks`-Dokument zahlreiche andere Szenarien unterstützen kann. Im Folgenden finden Sie einige Beispiele.
+ Stoppen Sie einen Metriken meldenden Agenten, bevor Sie ihn patchen und neu starten, nachdem der verwaltete Knoten neu gestartet wurde.
+ Trennen Sie den verwalteten Knoten vor dem Patchen von einem CRM- oder PCS-Cluster und fügen Sie sie nach dem Neustart des Knoten erneut an.
+ Aktualisieren Sie Software von Drittanbietern (z. B. Java, Tomcat, Adobe-Anwendungen usw.) auf Windows Server-Maschinen nach dem Anwenden von Betriebssystem-Updates, jedoch vor dem Neustart des verwalteten Knoten.

**So aktualisieren Sie Anwendungsabhängigkeite, patchen einen verwalteten Knoten und führen eine anwendungsspezifische Zustandsprüfung durch**

1. Erstellen Sie ein SSM-Dokument für Ihr Vorinstallations-Skript mit dem folgenden Inhalt und geben Sie ihm den Namen `NodeJSAppPrePatch`. Ersetzen Sie *your\$1application* mit dem Namen Ihrer Anwendung.

   Dieses Skript blockiert sofort neue eingehende Anforderungen und lässt fünf Sekunden, damit bereits aktive Anforderungen abgeschlossen werden können, bevor der Patchvorgang gestartet wird. Für die `sleep`-Option geben Sie einen Wert in Sekunden an, der größer ist als die Dauer, bis eingehende Anforderungen normalerweise abgeschlossen werden.

   ```
   # exit on error
   set -e
   # set up rule to block incoming traffic
   iptables -I INPUT -j DROP -p tcp --syn --destination-port 443 || exit 1
   # wait for current connections to end. Set timeout appropriate to your application's latency
   sleep 5 
   # Stop your application
   pm2 stop your_application
   ```

   Informationen zum Erstellen von SSM-Dokumenten finden Sie unter [Erstellen von SSM-Dokumentinhalten](documents-creating-content.md).

1. Erstellen Sie ein weiteres SSM-Dokument mit folgendem Inhalt für Ihr Postinstall-Skript, um Ihre Anwendungsabhängigkeiten zu aktualisieren, und nennen Sie es `NodeJSAppPostPatch`. Ersetzen Sie es */your/application/path* durch den Pfad zu Ihrer Anwendung.

   ```
   cd /your/application/path
   npm update 
   # you can use npm-check-updates if you want to upgrade major versions
   ```

1. Erstellen Sie ein weiteres SSM-Dokument mit folgendem Inhalt für Ihr `onExit`-Skript, um Ihre Anwendung zu sichern und eine Zustandsprüfung durchzuführen. Nennen Sie dieses SSM-Dokument `NodeJSAppOnExitPatch`. Ersetzen Sie *your\$1application* mit dem Namen Ihrer Anwendung.

   ```
   # exit on error
   set -e
   # restart nodeJs application
   pm2 start your_application
   # sleep while your application starts and to allow for a crash
   sleep 10
   # check with pm2 to see if your application is running
   pm2 pid your_application
   # re-enable incoming connections
   iptables -D INPUT -j DROP -p tcp --syn --destination-port 
   # perform health check
   /usr/bin/curl -m 10 -vk -A "" http://localhost:443/health-check || exit 1
   ```

1. Erstellen Sie eine Zuordnung in State Manager, einem Tool in AWS Systems Manager, um mithilfe der folgenden Schritte den Vorgang auszuführen:

   1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

   1. Wählen Sie im Navigationsbereich **State Manager** und anschließend **Zuordnung erstellen** aus.

   1. Für **Name** geben Sie einen Namen ein, um den Zweck der Zuordnung zu identifizieren.

   1. Wählen Sie in der Liste **Dokument** die Option `AWS-RunPatchBaselineWithHooks` aus.

   1. Wählen Sie für **Operation** die Option **Install (Installieren)** aus.

   1. (Optional) Für **Snapshot-ID**, stellen Sie eine GUID bereit, die Sie generieren, um den Vorgang zu beschleunigen und Konsistenz zu gewährleisten. Der GUID-Wert kann so einfach sein wie `00000000-0000-0000-0000-111122223333`.

   1. Für **Pre Install Hook Doc Name** geben Sie `NodeJSAppPrePatch` ein. 

   1. Für **Post Install Hook Doc Name** geben Sie `NodeJSAppPostPatch` ein. 

   1. Geben **Sie für On ExitHook Doc-Name** den Wert ein`NodeJSAppOnExitPatch`. 

1. Für **Targets** (Ziele), identifizieren Sie Ihre verwalteten Knoten, indem Sie Tags angeben, Knoten manuell auswählen, eine Ressourcengruppe auswählen oder alle verwaltete Knoten auswählen.

1. Für **Specify schedule (Zeitplan angeben)** geben Sie an, wie oft die Zuordnung ausgeführt werden soll. Für einen verwalteten Knoten ist das Patchen einmal pro Woche beispielsweise eine übliche Kadenz.

1. Wählen Sie im Abschnitt **Rate control** (Ratensteuerung) Optionen für die Ausführung der Zuordnung auf mehreren verwalteten Knoten aus. Stellen Sie sicher, dass nur ein Teil der verwalteten Knoten gleichzeitig aktualisiert wird. Andernfalls könnte die gesamte oder die meisten Ihrer Flotte gleichzeitig offline geschaltet werden. Weitere Informationen zu Ratensteuerungen finden Sie unter [Verstehen von Zielen und Ratensteuerungen in State Manager Zuordnungen](systems-manager-state-manager-targets-and-rate-controls.md).

1. (Optional) Wenn Sie im Abschnitt **Ausgabeoptionen** die Befehlsausgabe in einer Datei speichern möchten, aktivieren Sie das Kontrollkästchen **Schreiben der Ausgabe in S3 aktivieren**. Geben Sie die Namen für den Bucket und das Präfix (Ordner) in die Textfelder ein.
**Anmerkung**  
Die S3-Berechtigungen zum Schreiben von Daten in einen S3-Bucket sind die Berechtigungen des dem verwalteten Knoten zugewiesenen Instance-Profils und nicht diejenigen des IAM-Benutzers, der diese Aufgabe ausführt. Weitere Informationen finden Sie unter [Instance-Berechtigungen für Systems Manager konfigurieren](setup-instance-permissions.md) oder [Eine IAM-Servicerolle für eine Hybrid-Umgebung erstellen](hybrid-multicloud-service-role.md). Wenn sich der angegebene S3-Bucket in einem anderen AWS-Konto befindet, stellen Sie außerdem sicher, dass das Instance-Profil oder die IAM-Servicerolle, die dem verwalteten Knoten zugeordnet ist, über die erforderlichen Berechtigungen zum Schreiben in diesen Bucket verfügt.

1. Wählen Sie **Zuordnung erstellen**.

# Tutorial: Patchen Sie eine Serverumgebung mit dem AWS CLI
<a name="patch-manager-patch-servers-using-the-aws-cli"></a>

In der folgenden Prozedur wird beschrieben, wie Sie eine Serverumgebung mithilfe einer angepassten Patch-Baseline, Patch-Gruppen und einem Wartungsfenster patchen.

**Bevor Sie beginnen**
+ Installieren oder Aktualisieren des SSM Agent auf Ihren verwalteten Knoten. Um von Linux verwaltete Knoten zu patchen, müssen Ihre Knoten SSM Agent der Version 2.0.834.0 oder höher ausführen. Weitere Informationen finden Sie unter [Aktualisierung von SSM Agent mithilfe von Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
+ Konfigurieren Sie Rollen und Berechtigungen für Maintenance Windows ein Tool in AWS Systems Manager. Weitere Informationen finden Sie unter [Einrichten von Maintenance Windows](setting-up-maintenance-windows.md).
+ Installieren und konfigurieren Sie AWS Command Line Interface (AWS CLI), falls Sie dies noch nicht getan haben.

  Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).

**So konfigurieren Sie Patch Manager und spielen Patches für verwaltete Knoten ein (Befehlszeile)**

1. Führen Sie den folgenden Befehl aus, um eine Patch-Baseline für Windows mit dem Namen `Production-Baseline` zu erstellen. Diese Patch-Baseline genehmigt Patches für eine Produktionsumgebung sieben Tage nach ihrer Veröffentlichung oder letzten Aktualisierung. Darüber hinaus wurde die Patch-Baseline markiert, um anzuzeigen, dass sie für eine Produktionsumgebung bestimmt ist.
**Anmerkung**  
Der `OperatingSystem`-Parameter und `PatchFilters` variieren je nach Betriebssystem der anvisierten verwalteten Knoten, für die die Patch-Baseline gilt. Weitere Informationen erhalten Sie unter [OperatingSystem](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-OperatingSystem) und [PatchFilter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html).

------
#### [ Linux & macOS ]

   ```
   aws ssm create-patch-baseline \
       --name "Production-Baseline" \
       --operating-system "WINDOWS" \
       --tags "Key=Environment,Value=Production" \
       --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" \
       --description "Baseline containing all updates approved for production systems"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm create-patch-baseline ^
       --name "Production-Baseline" ^
       --operating-system "WINDOWS" ^
       --tags "Key=Environment,Value=Production" ^
       --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" ^
       --description "Baseline containing all updates approved for production systems"
   ```

------

   Das System gibt unter anderem folgende Informationen zurück

   ```
   {
      "BaselineId":"pb-0c10e65780EXAMPLE"
   }
   ```

1. Führen Sie die folgenden Befehle aus, um die Patch-Baseline „Production-Baseline“ für zwei Patchgruppen zu registrieren. Die Gruppen heißen „Datenbankserver“ und „Front-End-Server“.

------
#### [ Linux & macOS ]

   ```
   aws ssm register-patch-baseline-for-patch-group \
       --baseline-id pb-0c10e65780EXAMPLE \
       --patch-group "Database Servers"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-patch-baseline-for-patch-group ^
       --baseline-id pb-0c10e65780EXAMPLE ^
       --patch-group "Database Servers"
   ```

------

   Das System gibt unter anderem folgende Informationen zurück

   ```
   {
      "PatchGroup":"Database Servers",
      "BaselineId":"pb-0c10e65780EXAMPLE"
   }
   ```

------
#### [ Linux & macOS ]

   ```
   aws ssm register-patch-baseline-for-patch-group \
       --baseline-id pb-0c10e65780EXAMPLE \
       --patch-group "Front-End Servers"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-patch-baseline-for-patch-group ^
       --baseline-id pb-0c10e65780EXAMPLE ^
       --patch-group "Front-End Servers"
   ```

------

   Das System gibt unter anderem folgende Informationen zurück

   ```
   {
      "PatchGroup":"Front-End Servers",
      "BaselineId":"pb-0c10e65780EXAMPLE"
   }
   ```

1. Führen Sie die folgenden Befehle aus, um zwei Wartungsfenster für die Produktionsserver zu erstellen. Das erste Zeitfenster beginnt jeden Dienstag um 22:00 Uhr. Das zweite Zeitfenster beginnt jeden Samstag um 22:00 Uhr. Darüber hinaus wird das Wartungsfenster mit Tags versehen, um anzugeben, das es für eine Produktionsumgebung vorgesehen ist.

------
#### [ Linux & macOS ]

   ```
   aws ssm create-maintenance-window \
       --name "Production-Tuesdays" \
       --tags "Key=Environment,Value=Production" \
       --schedule "cron(0 0 22 ? * TUE *)" \
       --duration 1 \
       --cutoff 0 \
       --no-allow-unassociated-targets
   ```

------
#### [ Windows Server ]

   ```
   aws ssm create-maintenance-window ^
       --name "Production-Tuesdays" ^
       --tags "Key=Environment,Value=Production" ^
       --schedule "cron(0 0 22 ? * TUE *)" ^
       --duration 1 ^
       --cutoff 0 ^
       --no-allow-unassociated-targets
   ```

------

   Das System gibt unter anderem folgende Informationen zurück

   ```
   {
      "WindowId":"mw-0c50858d01EXAMPLE"
   }
   ```

------
#### [ Linux & macOS ]

   ```
   aws ssm create-maintenance-window \
       --name "Production-Saturdays" \
       --tags "Key=Environment,Value=Production" \
       --schedule "cron(0 0 22 ? * SAT *)" \
       --duration 2 \
       --cutoff 0 \
       --no-allow-unassociated-targets
   ```

------
#### [ Windows Server ]

   ```
   aws ssm create-maintenance-window ^
       --name "Production-Saturdays" ^
       --tags "Key=Environment,Value=Production" ^
       --schedule "cron(0 0 22 ? * SAT *)" ^
       --duration 2 ^
       --cutoff 0 ^
       --no-allow-unassociated-targets
   ```

------

   Das System gibt unter anderem folgende Informationen zurück

   ```
   {
      "WindowId":"mw-9a8b7c6d5eEXAMPLE"
   }
   ```

1. Führen Sie die folgenden Befehle aus, um die Server-Patch-Gruppen `Database` und `Front-End` mit ihren jeweiligen Wartungsfenstern zu registrieren.

------
#### [ Linux & macOS ]

   ```
   aws ssm register-target-with-maintenance-window \
       --window-id mw-0c50858d01EXAMPLE \
       --targets "Key=tag:PatchGroup,Values=Database Servers" \
       --owner-information "Database Servers" \
       --resource-type "INSTANCE"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-target-with-maintenance-window ^
       --window-id mw-0c50858d01EXAMPLE ^
       --targets "Key=tag:PatchGroup,Values=Database Servers" ^
       --owner-information "Database Servers" ^
       --resource-type "INSTANCE"
   ```

------

   Das System gibt unter anderem folgende Informationen zurück

   ```
   {
      "WindowTargetId":"e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE"
   }
   ```

------
#### [ Linux & macOS ]

   ```
   aws ssm register-target-with-maintenance-window \
   --window-id mw-9a8b7c6d5eEXAMPLE \
   --targets "Key=tag:PatchGroup,Values=Front-End Servers" \
   --owner-information "Front-End Servers" \
   --resource-type "INSTANCE"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-target-with-maintenance-window ^
       --window-id mw-9a8b7c6d5eEXAMPLE ^
       --targets "Key=tag:PatchGroup,Values=Front-End Servers" ^
       --owner-information "Front-End Servers" ^
       --resource-type "INSTANCE"
   ```

------

   Das System gibt unter anderem folgende Informationen zurück

   ```
   {
      "WindowTargetId":"faa01c41-1d57-496c-ba77-ff9caEXAMPLE"
   }
   ```

1. Führen Sie die folgenden Befehle aus, um eine Patch-Aufgabe zu registrieren, die während der entsprechenden Wartungsfenster fehlende Updates auf den Servern `Database` und `Front-End` installiert.

------
#### [ Linux & macOS ]

   ```
   aws ssm register-task-with-maintenance-window \
       --window-id mw-0c50858d01EXAMPLE \
       --targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" \
       --task-arn "AWS-RunPatchBaseline" \
       --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
       --task-type "RUN_COMMAND" \
       --max-concurrency 2 \
       --max-errors 1 \
       --priority 1 \
       --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-task-with-maintenance-window ^
       --window-id mw-0c50858d01EXAMPLE ^
       --targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" ^
       --task-arn "AWS-RunPatchBaseline" ^
       --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
       --task-type "RUN_COMMAND" ^
       --max-concurrency 2 ^
       --max-errors 1 ^
       --priority 1 ^
       --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
   ```

------

   Das System gibt unter anderem folgende Informationen zurück

   ```
   {
      "WindowTaskId":"4f7ca192-7e9a-40fe-9192-5cb15EXAMPLE"
   }
   ```

------
#### [ Linux & macOS ]

   ```
   aws ssm register-task-with-maintenance-window \
       --window-id mw-9a8b7c6d5eEXAMPLE \
       --targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" \
       --task-arn "AWS-RunPatchBaseline" \
       --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
       --task-type "RUN_COMMAND" \
       --max-concurrency 2 \
       --max-errors 1 \
       --priority 1 \
       --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-task-with-maintenance-window ^
       --window-id mw-9a8b7c6d5eEXAMPLE ^
       --targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" ^
       --task-arn "AWS-RunPatchBaseline" ^
       --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
       --task-type "RUN_COMMAND" ^
       --max-concurrency 2 ^
       --max-errors 1 ^
       --priority 1 ^
       --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
   ```

------

   Das System gibt unter anderem folgende Informationen zurück

   ```
   {
      "WindowTaskId":"8a5c4629-31b0-4edd-8aea-33698EXAMPLE"
   }
   ```

1. Führen Sie den folgenden Befehl aus, um für eine Patch-Gruppe eine allgemeine Zusammenfassung zur Patch-Compliance abzurufen. Die allgemeine Zusammenfassung der Patch-Compliance enthält die Anzahl der verwalteten Knoten mit Patches in den jeweiligen Patch-Zuständen.
**Anmerkung**  
Es werden Nullen für die Anzahl der verwalteten Knoten in der Zusammenfassung erwartet, bis die Patch-Aufgabe während des ersten Wartungsfensters ausgeführt wird.

------
#### [ Linux & macOS ]

   ```
   aws ssm describe-patch-group-state \
       --patch-group "Database Servers"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm describe-patch-group-state ^
       --patch-group "Database Servers"
   ```

------

   Das System gibt unter anderem folgende Informationen zurück

   ```
   {
      "Instances": number,
      "InstancesWithFailedPatches": number,
      "InstancesWithInstalledOtherPatches": number,
      "InstancesWithInstalledPatches": number,
      "InstancesWithInstalledPendingRebootPatches": number,
      "InstancesWithInstalledRejectedPatches": number,
      "InstancesWithMissingPatches": number,
      "InstancesWithNotApplicablePatches": number,
      "InstancesWithUnreportedNotApplicablePatches": number
   }
   ```

1. Führen Sie den folgenden Befehl aus, um für eine Patch-Gruppe eine Übersicht über den Patch-Zustand auf der Ebene einzelner verwalteter Knoten abzurufen. Die Zusammenfassung pro verwalteter Knoten enthält eine Anzahl von Patches in den jeweiligen Patch-Zuständen pro verwalteten Knoten für eine Patch-Gruppe.

------
#### [ Linux & macOS ]

   ```
   aws ssm describe-instance-patch-states-for-patch-group \
       --patch-group "Database Servers"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm describe-instance-patch-states-for-patch-group ^
       --patch-group "Database Servers"
   ```

------

   Das System gibt unter anderem folgende Informationen zurück

   ```
   {
      "InstancePatchStates": [ 
         { 
            "BaselineId": "string",
            "FailedCount": number,
            "InstalledCount": number,
            "InstalledOtherCount": number,
            "InstalledPendingRebootCount": number,
            "InstalledRejectedCount": number,
            "InstallOverrideList": "string",
            "InstanceId": "string",
            "LastNoRebootInstallOperationTime": number,
            "MissingCount": number,
            "NotApplicableCount": number,
            "Operation": "string",
            "OperationEndTime": number,
            "OperationStartTime": number,
            "OwnerInformation": "string",
            "PatchGroup": "string",
            "RebootOption": "string",
            "SnapshotId": "string",
            "UnreportedNotApplicableCount": number
         }
      ]
   }
   ```

Beispiele für andere AWS CLI Befehle, die Sie für Ihre Patch Manager Konfigurationsaufgaben verwenden können, finden Sie unter[Arbeiten mit Patch Manager-Ressourcen unter Verwendung der AWS CLI](patch-manager-cli-commands.md).

# Fehlerbehebung für Patch Manager
<a name="patch-manager-troubleshooting"></a>

Im Folgenden finden Sie Informationen zur Behandlung von Problemen mit Patch Manager, einem Tool in AWS Systems Manager.

**Topics**
+ [Problem: Fehler „Invoke-PatchBaselineOperation : Zugriff verweigert“ oder Fehler „Datei kann nicht von S3 heruntergeladen werden“ für `baseline_overrides.json`](#patch-manager-troubleshooting-patch-policy-baseline-overrides)
+ [Problem: Das Patchen schlägt fehl, ohne dass eine offensichtliche Ursache oder Fehlermeldung vorliegt](#race-condition-conflict)
+ [Problem: Unerwartete Patch-Compliance-Ergebnisse](#patch-manager-troubleshooting-compliance)
+ [Fehler beim Ausführen von `AWS-RunPatchBaseline` unter Linux](#patch-manager-troubleshooting-linux)
+ [Fehler beim Ausführen von `AWS-RunPatchBaseline` unter Windows Server](#patch-manager-troubleshooting-windows)
+ [Fehler bei der Ausführung `AWS-RunPatchBaseline` auf macOS](#patch-manager-troubleshooting-macos)
+ [Verwenden von Automation-Runbooks AWS Support](#patch-manager-troubleshooting-using-support-runbooks)
+ [Kontaktaufnahme AWS Support](#patch-manager-troubleshooting-contact-support)

## Problem: Fehler „Invoke-PatchBaselineOperation : Zugriff verweigert“ oder Fehler „Datei kann nicht von S3 heruntergeladen werden“ für `baseline_overrides.json`
<a name="patch-manager-troubleshooting-patch-policy-baseline-overrides"></a>

**Problem**: Wenn die von Ihrer Patch-Richtlinie festgelegten Patching-Vorgänge ausgeführt werden, erhalten Sie eine Fehlermeldung ähnlich dem folgenden Beispiel. 

------
#### [ Example error on Windows Server ]

```
----------ERROR-------
Invoke-PatchBaselineOperation : Access Denied
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestr
ation\792dd5bd-2ad3-4f1e-931d-abEXAMPLE\PatchWindows\_script.ps1:219 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOpera
tion:InstallWindowsUpdateOperation) [Invoke-PatchBaselineOperation], Amazo
nS3Exception
+ FullyQualifiedErrorId : PatchBaselineOperations,Amazon.Patch.Baseline.Op
erations.PowerShellCmdlets.InvokePatchBaselineOperation
failed to run commands: exit status 0xffffffff
```

------
#### [ Example error on Linux ]

```
[INFO]: Downloading Baseline Override from s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json
[ERROR]: Unable to download file from S3: s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json.
[ERROR]: Error loading entrance module.
```

------

**Ursache**: Sie haben eine Patch-Richtlinie in Quick Setup erstellt, und einige Ihrer verwalteten Knoten waren bereits mit einem Instance-Profil (für EC2-Instances) oder einer Servicerolle (für Nicht-EC2-Maschinen) versehen. 

Sie haben jedoch das Kontrollkästchen **Erforderliche IAM-Richtlinien zu vorhandenen Instance-Profilen hinzufügen, die an Ihre Instances angehängt** sind, nicht aktiviert, wie in der folgenden Abbildung dargestellt.

![\[\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/QS-instance-profile-option.png)


Wenn Sie eine Patch-Richtlinie erstellen, wird auch ein Amazon-S3-Bucket erstellt, in dem die `baseline_overrides.json` Konfigurationsdatei der Richtlinie gespeichert wird. Wenn Sie bei der Erstellung der Richtlinie das Kontrollkästchen **Erforderliche IAM-Richtlinien zu bestehenden Instance-Profilen hinzufügen, die mit Ihren Instances verbunden sind**, nicht aktivieren, werden die IAM-Richtlinien und Ressourcen-Tags, die für den Zugriff auf `baseline_overrides.json` im S3-Bucket erforderlich sind, nicht automatisch zu Ihren bestehenden IAM-Instance-Profilen und Servicerollen hinzugefügt.

**Lösung 1**: Löschen Sie die bestehende Patch-Richtlinienkonfiguration und erstellen Sie dann eine neue. Aktivieren Sie dabei das Kontrollkästchen **Erforderliche IAM-Richtlinien zu bestehenden Instance-Profilen hinzufügen, die mit Ihren Instances verbunden** sind. Diese Auswahl wendet die mit dieser Quick Setup-Konfiguration erstellten IAM-Richtlinien auf Knoten an, denen bereits ein Instance-Profil oder eine Servicerolle zugewiesen ist. (Quick Setup fügt standardmäßig die erforderlichen Richtlinien zu Instances und Knoten hinzu, die *noch nicht* über Instance-Profile oder Servicerollen verfügen.) Weitere Informationen finden Sie unter [Automatisieren von unternehmensweitem Patching mithilfe einer Quick Setup-Patch-Richtlinie](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html). 

**Lösung 2**: Fügen Sie die erforderlichen Berechtigungen und Tags manuell zu jedem IAM-Instance-Profil und jeder IAM-Servicerolle hinzu, die Sie mit Quick Setup verwenden. Detaillierte Anweisungen finden Sie unter [Berechtigungen für den S3-Bucket mit der Patch-Richtlinie](quick-setup-patch-manager.md#patch-policy-s3-bucket-permissions).

## Problem: Das Patchen schlägt fehl, ohne dass eine offensichtliche Ursache oder Fehlermeldung vorliegt
<a name="race-condition-conflict"></a>

**Problem**: Ein Patch-Vorgang schlägt fehl, ohne dass eine Fehlermeldung zurückgegeben wird.

**Mögliche Ursache**: Beim Patchen verwalteter Knoten kann die Ausführung des Dokuments unterbrochen und als fehlgeschlagen markiert werden, obwohl die Patches erfolgreich installiert wurden. Dies kann der Fall sein, wenn das System während des Patchvorgangs einen unerwarteten Neustart einleitet (z. B. um Firmware-Updates oder Funktionen wie) anzuwenden. SecureBoot Der SSM-Agent kann den Status der Dokumentausführung bei externen Neustarts nicht beibehalten und wieder aufnehmen, was dazu führt, dass die Ausführung als fehlgeschlagen gemeldet wird. 

**Lösung**: Um den Status der Patch-Installation nach einer fehlgeschlagenen Ausführung zu überprüfen, führen Sie einen `Scan` Patch-Vorgang aus und überprüfen Sie anschließend die Patch-Kompatibilitätsdaten in Patch Manager, um den aktuellen Konformitätsstatus zu beurteilen.

Wenn Sie feststellen, dass externe Neustarts in diesem Szenario nicht die Ursache für den Fehler waren, empfehlen wir Ihnen, sich an uns zu wenden. [AWS Support](#patch-manager-troubleshooting-contact-support)

## Problem: Unerwartete Patch-Compliance-Ergebnisse
<a name="patch-manager-troubleshooting-compliance"></a>

**Problem**: Bei der Überprüfung der nach einem `Scan`-Vorgang generierten Details zur Patching-Compliance enthalten die Ergebnisse Informationen, die nicht die in Ihrer Patch-Baseline festgelegten Regeln widerspiegeln. Beispielsweise wird eine Ausnahme, die Sie der Liste **Rejected patches** (Abgelehnte Patches) in einer Patch-Baseline hinzugefügt haben, als `Missing` aufgeführt. Oder als `Important` klassifizierte Patches werden als fehlend aufgeführt, obwohl Ihre Patch-Baseline nur `Critical`-Patches angibt.

**Ursache**: Patch Manager unterstützt derzeit mehrere Methoden zum Ausführen von `Scan`-Operationen:
+ Eine in Quick Setup konfigurierte Patch-Richtlinie
+ Eine in Quick Setup konfigurierte Host-Management-Option
+ Ein Wartungsfenster zum Ausführen eines Patch-`Scan` oder einer `Install`-Aufgabe
+ Eine On-Demand **Patch now**-Operation (Jetzt patchen)

Wenn eine `Scan`-Operation ausgeführt wird, überschreibt dies die Compliance-Details aus dem letzten Scan. Wenn Sie mehr als eine Methode zum Ausführen einer `Scan`-Operation eingerichtet haben und diese unterschiedliche Patch-Baselines mit unterschiedlichen Regeln verwenden, führt dies zu unterschiedlichen Patch-Compliance-Ergebnissen. 

**Lösung**: Um unerwartete Patch-Compliance-Ergebnisse zu vermeiden, empfehlen wir, jeweils nur eine Methode zum Ausführen der Patch Manager `Scan`-Operation zu verwenden. Weitere Informationen finden Sie unter [Identifizieren der Ausführung, die Patch-Compliance-Daten erstellt hat](patch-manager-compliance-data-overwrites.md).

## Fehler beim Ausführen von `AWS-RunPatchBaseline` unter Linux
<a name="patch-manager-troubleshooting-linux"></a>

**Topics**
+ [Problem: Fehler 'No such file or directory'](#patch-manager-troubleshooting-linux-1)
+ [Problem: Fehler 'another process has acquired yum lock'](#patch-manager-troubleshooting-linux-2)
+ [Problem: Fehler 'Permission denied / failed to run commands'](#patch-manager-troubleshooting-linux-3)
+ [Problem: Fehler 'Unable to download payload'](#patch-manager-troubleshooting-linux-4)
+ [Problem: Fehler 'unsupported package manager and python version combination'](#patch-manager-troubleshooting-linux-5)
+ [Problem: Patch Manager wendet keine Regeln an, die zum Ausschließen bestimmter Pakete angegeben sind](#patch-manager-troubleshooting-linux-6)
+ [Problem: Patching schlägt fehl und Patch Manager meldet, dass die Erweiterung „Servername Indication“ für TLS nicht verfügbar ist](#patch-manager-troubleshooting-linux-7)
+ [Problem: Patch Manager meldet 'No more mirrors to try'](#patch-manager-troubleshooting-linux-8)
+ [Problem: Patching schlägt fehl mit 'Error code returned from curl is 23'](#patch-manager-troubleshooting-linux-9)
+ [Problem: Patching schlägt mit der Meldung 'Error unpacking rpm package...' fehl](#error-unpacking-rpm)
+ [Problem: Patching schlägt fehl mit 'Fehler auf Serviceseite beim Hochladen des Inventars'](#inventory-upload-error)
+ [Problem: Das Patchen schlägt fehl und die Meldung „Beim Herunterladen von Paketen sind Fehler aufgetreten“ wird angezeigt](#errors-while-downloading)
+ [Problem: Das Patchen schlägt mit einem OOM-Fehler (Out of Memory) fehl](#patch-manager-troubleshooting-linux-oom)
+ [Problem: Patching schlägt fehl mit der Meldung 'Die folgenden Signaturen konnten nicht verifiziert werden, da der öffentliche Schlüssel nicht verfügbar ist'](#public-key-unavailable)
+ [Problem: Das Patchen schlägt fehl und die Meldung '' NoMoreMirrorsRepoError wird angezeigt](#no-more-mirrors-repo-error)
+ [Problem: Das Patchen schlägt mit der Meldung „Payload kann nicht heruntergeladen werden“ fehl](#payload-download-error)
+ [Problem: Das Patchen schlägt fehl und es wird die Meldung „Installationsfehler: dpkg: Fehler:dpkg-Frontend ist durch einen anderen Prozess gesperrt“ angezeigt](#dpkg-frontend-locked)
+ [Problem: Das Patchen auf Ubuntu Server schlägt fehl und es wird der Fehler „dpkg wurde unterbrochen“ angezeigt](#dpkg-interrupted)
+ [Problem: Das Paketmanager-Dienstprogramm kann eine Paketabhängigkeit nicht auflösen](#unresolved-dependency)
+ [Problem: Fehler bei der Abhängigkeit von Zypper-Paketsperren auf verwalteten SLES-Knoten](#patch-manager-troubleshooting-linux-zypper-locks)
+ [Problem: Die Sperre kann nicht abgerufen werden. Ein weiterer Patch-Vorgang ist im Gange.](#patch-manager-troubleshooting-linux-concurrent-lock)

### Problem: Fehler 'No such file or directory'
<a name="patch-manager-troubleshooting-linux-1"></a>

**Problem**: Wenn Sie `AWS-RunPatchBaseline` ausführen, schlägt das Patchen mit einem der folgenden Fehler fehl.

```
IOError: [Errno 2] No such file or directory: 'patch-baseline-operations-X.XX.tar.gz'
```

```
Unable to extract tar file: /var/log/amazon/ssm/patch-baseline-operations/patch-baseline-operations-1.75.tar.gz.failed to run commands: exit status 155
```

```
Unable to load and extract the content of payload, abort.failed to run commands: exit status 152
```

**Ursache 1**: Zwei Befehle zum Ausführen von `AWS-RunPatchBaseline` wurden gleichzeitig auf demselben verwalteten Knoten ausgeführt. Dies erzeugt eine Race-Bedingung, die in der temporären `file patch-baseline-operations*` nicht richtig erstellt oder auf die nicht richtig zugegriffen wird.

**Ursache 2**: Unzureichender Speicherplatz verbleibt im `/var`-Verzeichnis. 

**Lösung 1**: Stellen Sie sicher, dass kein Wartungsfenster zwei oder mehr Run Command Aufgaben umfasst, die `AWS-RunPatchBaseline` mit derselben Prioritätsstufe und auf demselben Ziel IDs ausgeführt werden. Wenn dies der Fall ist, ordnen Sie die Priorität neu an. Run Commandist ein Tool in AWS Systems Manager.

**Lösung 2**: Stellen Sie sicher, dass jeweils nur ein Wartungsfenster Run Command-Aufgaben ausführt, die `AWS-RunPatchBaseline` auf denselben Zielen und nach demselben Zeitplan verwenden. Ändern Sie in diesem Fall den Zeitplan.

**Lösung 3**: Stellen Sie sicher, dass nur eine State Manager-Zuordnung `AWS-RunPatchBaseline` nach demselben Zeitplan ausführt und die gleichen verwalteten Knoten anvisiert. State Manager ist ein Tool in AWS Systems Manager.

**Lösung 4**: Machen Sie genügend Speicherplatz im `/var`-Verzeichnis für die Update-Pakete. frei

### Problem: Fehler 'another process has acquired yum lock'
<a name="patch-manager-troubleshooting-linux-2"></a>

**Problem**: Wenn Sie `AWS-RunPatchBaseline` ausführen, schlägt das Patchen mit dem folgenden Fehler fehl.

```
12/20/2019 21:41:48 root [INFO]: another process has acquired yum lock, waiting 2 s and retry.
```

**Ursache**: Das `AWS-RunPatchBaseline`-Dokument wurde auf einem verwalteten Knoten ausgeführt, in dem es bereits in einer anderen Operation ausgeführt wird und den `yum`-Paketmanager-Prozess erhalten hat.

**Lösung**: Stellen Sie sicher, dass keine State Manager-Zuordnung, Aufgaben im Wartungsfenster oder andere Konfigurationen, die `AWS-RunPatchBaseline`nach einem Zeitplan ausführen, ungefähr zur gleichen Zeit denselben verwalteten Knoten als Ziel haben.

### Problem: Fehler 'Permission denied / failed to run commands'
<a name="patch-manager-troubleshooting-linux-3"></a>

**Problem**: Wenn Sie `AWS-RunPatchBaseline` ausführen, schlägt das Patchen mit dem folgenden Fehler fehl.

```
sh: 
/var/lib/amazon/ssm/instanceid/document/orchestration/commandid/PatchLinux/_script.sh: Permission denied
failed to run commands: exit status 126
```

**Ursache**: `/var/lib/amazon/` könnte mit `noexec`-Berechtigungen gemountet sein. Dies ist ein Problem, weil SSM Agent Payload-Skripte auf `/var/lib/amazon/ssm` herunterlädt und sie von diesem Speicherort ausführt.

**Lösung**: Stellen Sie sicher, dass Sie exklusive Partitionen für `/var/log/amazon` und `/var/lib/amazon` konfiguriert haben und sind mit `exec`-Berechtigungen gemountet sind.

### Problem: Fehler 'Unable to download payload'
<a name="patch-manager-troubleshooting-linux-4"></a>

**Problem**: Wenn Sie `AWS-RunPatchBaseline` ausführen, schlägt das Patchen mit dem folgenden Fehler fehl.

```
Unable to download payload: https://s3.amzn-s3-demo-bucket.region.amazonaws.com/aws-ssm-region/patchbaselineoperations/linux/payloads/patch-baseline-operations-X.XX.tar.gz.failed to run commands: exit status 156
```

**Ursache**: Der verwaltete Knoten verfügt nicht über die erforderlichen Berechtigungen für den Zugriff auf den angegebenen Amazon Simple Storage Service (Amazon S3)-Bucket.

**Lösung**: Aktualisieren Sie Ihre Netzwerkkonfiguration so, dass S3-Endpunkte erreichbar sind. Weitere Informationen finden Sie unter den Informationen zum erforderlichen Zugriff auf S3-Buckets für Patch Manager in [SSM AgentKommunikation mit AWS verwalteten S3-Buckets](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions).

### Problem: Fehler 'unsupported package manager and python version combination'
<a name="patch-manager-troubleshooting-linux-5"></a>

**Problem**: Wenn Sie `AWS-RunPatchBaseline` ausführen, schlägt das Patchen mit dem folgenden Fehler fehl.

```
An unsupported package manager and python version combination was found. Apt requires Python3 to be installed.
failed to run commands: exit status 1
```

**Ursache**: Eine unterstützte Version von Python3 ist nicht auf der Instance Debian Server oder Ubuntu Server installiert.

**Lösung**: Installieren Sie eine unterstützte Version von python3 (3.0–3.12) auf dem Server, die für verwaltete Debian Server- und Ubuntu Server-Knoten erforderlich ist.

### Problem: Patch Manager wendet keine Regeln an, die zum Ausschließen bestimmter Pakete angegeben sind
<a name="patch-manager-troubleshooting-linux-6"></a>

**Problem**: Sie haben versucht, bestimmte Pakete auszuschließen, indem Sie sie in der `/etc/yum.conf`-Datei im Format `exclude=package-name` angeben, aber sie werden nicht während der Patch Manager-Operation `Install` ausgeschlossen.

**Ursache**: Patch Manager enthält keine Ausschlüsse, die in der `/etc/yum.conf`-Datei angegeben sind.

**Lösung**: Um bestimmte Pakete auszuschließen, erstellen Sie eine benutzerdefinierte Patch-Baseline und eine Regel, um die Pakete auszuschließen, die nicht installiert werden sollen.

### Problem: Patching schlägt fehl und Patch Manager meldet, dass die Erweiterung „Servername Indication“ für TLS nicht verfügbar ist
<a name="patch-manager-troubleshooting-linux-7"></a>

**Problem**: Der Patchvorgang gibt die folgende Meldung aus.

```
/var/log/amazon/ssm/patch-baseline-operations/urllib3/util/ssl_.py:369: 
SNIMissingWarning: An HTTPS request has been made, but the SNI (Server Name Indication) extension
to TLS is not available on this platform. This might cause the server to present an incorrect TLS 
certificate, which can cause validation failures. You can upgrade to a newer version of Python 
to solve this. 
For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
```

**Ursache**: Diese Meldung zeigt keinen Fehler an. Stattdessen ist dies eine Warnung, dass die ältere Version von Python, die mit dem Betriebssystem vertrieben wird, TLS Server Name Indication nicht unterstützt. Das Systems Manager Manager-Patch-Payload-Skript gibt diese Warnung aus, wenn eine Verbindung zu AWS APIs diesem unterstützenden SNI hergestellt wird.

**Lösung**: Um Patching-Fehler zu beheben, wenn diese Meldung gemeldet wird, überprüfen Sie den Inhalt der `stdout`- und `stderr`-Dateien. Wenn Sie die Patch-Baseline nicht so konfiguriert haben, dass diese Dateien in einem S3-Bucket oder in Amazon CloudWatch Logs gespeichert werden, können Sie die Dateien am folgenden Speicherort auf Ihrem verwalteten Linux-Node finden. 

`/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`

### Problem: Patch Manager meldet 'No more mirrors to try'
<a name="patch-manager-troubleshooting-linux-8"></a>

**Problem**: Der Patchvorgang gibt die folgende Meldung aus.

```
[Errno 256] No more mirrors to try.
```

**Ursache**: Die auf dem verwalteten Knoten konfigurierten Repositorys funktionieren nicht richtig. Mögliche Gründe hierfür sind:
+ Das `yum`-Cache ist beschädigt.
+ Eine Repository-URL kann aufgrund von Netzwerkproblemen nicht erreicht werden.

**Lösung**: Patch Manager verwendet den Standard-Paketmanager des verwalteten Knoten, um die Patching-Operation durchzuführen. Überprüfen Sie, ob Repositorys richtig konfiguriert sind und funktionieren.

### Problem: Patching schlägt fehl mit 'Error code returned from curl is 23'
<a name="patch-manager-troubleshooting-linux-9"></a>

**Problem**: Eine Patching-Operation, die `AWS-RunPatchBaseline` verwendet, schlägt mit einer Fehlermeldung ähnlich der folgenden fehl:

```
05/01/2025 17:04:30 root [ERROR]: Error code returned from curl is 23
```

**Ursache**: Das auf Ihren Systemen verwendete Curl-Tool verfügt nicht über die erforderlichen Rechte, um in das Dateisystem zu schreiben. Dies kann vorkommen, wenn das Standard-Curl-Tool des Paketmanagers durch eine andere Version ersetzt wurde, beispielsweise durch eine, die mit snap installiert wurde.

**Lösung**: Wenn die vom Paketmanager bereitgestellte curl-Version deinstalliert wurde, während eine andere Version installiert wurde, installieren Sie sie erneut.

Wenn Sie mehrere curl-Versionen installiert halten müssen, stellen Sie sicher, dass sich die mit dem Paketmanager verknüpfte Version im ersten in der `PATH`-Variable aufgeführten Verzeichnis befindet. Sie können dies überprüfen, indem Sie den Befehl `echo $PATH` ausführen, um die aktuelle Reihenfolge der Verzeichnisse zu sehen, die auf Ihrem System auf ausführbare Dateien überprüft werden.

### Problem: Patching schlägt mit der Meldung 'Error unpacking rpm package...' fehl
<a name="error-unpacking-rpm"></a>

**Problem**: Ein Patch-Vorgang schlägt mit einem Fehler ähnlich dem folgenden fehl:

```
Error : Error unpacking rpm package python-urllib3-1.25.9-1.amzn2.0.2.noarch
python-urllib3-1.25.9-1.amzn2.0.1.noarch was supposed to be removed but is not!
failed to run commands: exit status 1
```

**Ursache 1**: Wenn ein bestimmtes Paket in mehreren Paket-Installationsprogrammen vorhanden ist, z. B. sowohl in `pip` als auch in `yum` oder `dnf`, kann es bei der Verwendung des Standard-Paketmanagers zu Konflikten kommen.

Ein häufiges Beispiel ist das `urllib3`-Paket, das sich in `pip`, `yum` und `dnf` befindet.

**Ursache 2**: Das `python-urllib3`-Paket ist beschädigt. Dies kann passieren, wenn die Paketdateien von `pip` installiert oder aktualisiert wurden, nachdem das `rpm`-Paket zuvor von `yum` oder `dnf` installiert wurde.

**Lösung**: Entfernen Sie das `python-urllib3`-Paket aus Pip, indem Sie den Befehl `sudo pip uninstall urllib3` ausführen, und behalten Sie das Paket nur im Standard-Paketmanager (`yum` oder `dnf`) bei. 

### Problem: Patching schlägt fehl mit 'Fehler auf Serviceseite beim Hochladen des Inventars'
<a name="inventory-upload-error"></a>

**Problem**: Beim Ausführen des `AWS-RunPatchBaseline`-Dokuments erhalten Sie die folgende Fehlermeldung:

```
Encounter service side error when uploading the inventory
```

**Ursache**: Zwei Befehle zum Ausführen von `AWS-RunPatchBaseline` wurden gleichzeitig auf demselben verwalteten Knoten ausgeführt. Dies führt zu einer Race-Bedingung, wenn der Boto3-Client während Patch-Vorgängen initialisiert wird.

**Lösung**: Stellen Sie sicher, dass keine State Manager-Zuordnung, Aufgaben im Wartungsfenster oder andere Konfigurationen, die `AWS-RunPatchBaseline`nach einem Zeitplan ausführen, ungefähr zur gleichen Zeit denselben verwalteten Knoten als Ziel haben.

### Problem: Das Patchen schlägt fehl und die Meldung „Beim Herunterladen von Paketen sind Fehler aufgetreten“ wird angezeigt
<a name="errors-while-downloading"></a>

**Problem**: Beim Patchen erhalten Sie eine Fehlermeldung, die der folgenden ähnelt:

```
YumDownloadError: [u'Errors were encountered while downloading 
packages.', u'libxml2-2.9.1-6.el7_9.6.x86_64: [Errno 5] [Errno 12] 
Cannot allocate memory', u'libxslt-1.1.28-6.el7.x86_64: [Errno 5] 
[Errno 12] Cannot allocate memory', u'libcroco-0.6.12-6.el7_9.x86_64: 
[Errno 5] [Errno 12] Cannot allocate memory', u'openldap-2.4.44-25.el7_9.x86_64: 
[Errno 5] [Errno 12] Cannot allocate memory',
```

**Ursache**: Dieser Fehler kann auftreten, wenn auf einem verwalteten Knoten nicht genügend Speicher verfügbar ist.

**Lösung**: Konfigurieren Sie den Swap-Speicher oder aktualisieren Sie die Instance auf einen anderen Typ, um die Speicherunterstützung zu erhöhen. Starten Sie dann einen neuen Patch-Vorgang.

### Problem: Das Patchen schlägt mit einem OOM-Fehler (Out of Memory) fehl
<a name="patch-manager-troubleshooting-linux-oom"></a>

**Problem**: Bei der Ausführung schlägt der Patchvorgang fehl`AWS-RunPatchBaseline`, da auf dem verwalteten Knoten nicht genügend Arbeitsspeicher zur Verfügung steht. Möglicherweise werden Fehler wie `Cannot allocate memory` `Killed` (vom Linux-OOM-Killer) angezeigt, oder der Vorgang schlägt unerwartet fehl. Dieser Fehler tritt eher bei Instanzen mit weniger als 1 GB RAM auf, kann sich aber auch auf Instanzen mit mehr Arbeitsspeicher auswirken, wenn eine große Anzahl von Updates verfügbar ist.

**Ursache**: Patch Manager führt Patchvorgänge mithilfe des systemeigenen Paketmanagers auf dem verwalteten Knoten aus. Der während eines Patchvorgangs benötigte Speicher hängt von mehreren Faktoren ab, darunter:
+ Die Anzahl der installierten Pakete und die verfügbaren Updates auf dem verwalteten Knoten.
+ Der verwendete Paketmanager und seine Speichereigenschaften.
+ Andere Prozesse, die zum Zeitpunkt des Patchvorgangs auf dem verwalteten Knoten ausgeführt werden.

Verwaltete Knoten mit einer großen Anzahl installierter Pakete oder einer großen Anzahl verfügbarer Updates benötigen während der Patchvorgänge mehr Arbeitsspeicher. Wenn der verfügbare Speicher nicht ausreicht, schlägt der Patchvorgang fehl und wird mit einem Fehler beendet. Das Betriebssystem kann den Patchvorgang auch beenden.

**Lösung**: Probieren Sie eine oder mehrere der folgenden Optionen aus:
+ Planen Sie Patch-Vorgänge in Zeiten geringer Arbeitsauslastung auf dem verwalteten Knoten, z. B. mithilfe von Wartungsfenstern.
+ Führen Sie ein Upgrade der Instanz auf einen Typ mit mehr Arbeitsspeicher durch.
+ Konfigurieren Sie den Swap-Speicher auf dem verwalteten Knoten. Beachten Sie, dass bei Instances mit begrenztem EBS-Durchsatz eine starke Swap-Nutzung zu Leistungseinbußen führen kann.
+ Überprüfen und reduzieren Sie die Anzahl der Prozesse, die während der Patching-Vorgänge auf dem verwalteten Knoten ausgeführt werden.

### Problem: Patching schlägt fehl mit der Meldung 'Die folgenden Signaturen konnten nicht verifiziert werden, da der öffentliche Schlüssel nicht verfügbar ist'
<a name="public-key-unavailable"></a>

**Problem**: Das Patchen schlägt bei Ubuntu Server mit einer Fehlermeldung ähnlich der folgenden fehl:

```
02/17/2022 21:08:43 root [ERROR]: W:GPG error: 
http://repo.mysql.com/apt/ubuntu  bionic InRelease: The following 
signatures couldn't be verified because the public key is not available: 
NO_PUBKEY 467B942D3A79BD29, E:The repository ' http://repo.mysql.com/apt/ubuntu bionic
```

**Ursache**: Der Schlüssel für GNU Privacy Guard (GPG) ist abgelaufen oder fehlt.

**Lösung**: Aktualisieren Sie den GPG-Schlüssel, oder fügen Sie den Schlüssel erneut hinzu.

Anhand des zuvor gezeigten Fehlers sehen wir zum Beispiel, dass der `467B942D3A79BD29`-Schlüssel fehlt und hinzugefügt werden muss. Führen Sie dazu einen der folgenden Befehle aus:

```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --recv-keys 467B942D3A79BD29
```

```
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 467B942D3A79BD29
```

Oder, um alle Schlüssel zu aktualisieren, führen Sie den folgenden Befehl aus:

```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --refresh-keys
```

Wenn der Fehler danach weiterhin auftritt, empfehlen wir, das Problem an die Organisation zu melden, die das Repository verwaltet. Bis ein Fix verfügbar ist, können Sie die `/etc/apt/sources.list`-Datei so bearbeiten, dass das Repository während des Patchvorgangs ausgelassen wird.

Öffnen Sie dazu die `sources.list`-Datei zur Bearbeitung, suchen Sie die Zeile für das Repository und fügen Sie am Anfang der Zeile ein `#`-Zeichen ein, um sie auszukommentieren. Speichern und schließen Sie dann die Datei.

### Problem: Das Patchen schlägt fehl und die Meldung '' NoMoreMirrorsRepoError wird angezeigt
<a name="no-more-mirrors-repo-error"></a>

**Problem:** Sie erhalten eine Fehlermeldung ähnlich der folgenden:

```
NoMoreMirrorsRepoError: failure: repodata/repomd.xml from pgdg94: [Errno 256] No more mirrors to try.
```

**Ursache**: Im Quell-Repository ist ein Fehler aufgetreten.

**Lösung**: Wir empfehlen, das Problem der Organisation zu melden, die das Repository verwaltet. Bis der Fehler behoben ist, können Sie das Repository auf Betriebssystemebene deaktivieren. Führen Sie dazu den folgenden Befehl aus und ersetzen Sie den Wert für *repo-name* durch Ihren Repository-Namen:

```
yum-config-manager --disable repo-name
```

Im Folgenden sehen Sie ein Beispiel.

```
yum-config-manager --disable pgdg94
```

Nachdem Sie diesen Befehl ausgeführt haben, führen Sie einen weiteren Patch-Vorgang aus.

### Problem: Das Patchen schlägt mit der Meldung „Payload kann nicht heruntergeladen werden“ fehl
<a name="payload-download-error"></a>

**Problem:** Sie erhalten eine Fehlermeldung ähnlich der folgenden:

```
Unable to download payload: 
https://s3.dualstack.eu-west-1.amazonaws.com/aws-ssm-eu-west-1/patchbaselineoperations/linux/payloads/patch-baseline-operations-1.83.tar.gz.
failed  to run commands: exit status 156
```

**Ursache**: Die Konfiguration des verwalteten Knotens ist fehlerhaft oder unvollständig.

**Lösung**: Versichern Sie sich, dass der verwaltete Knoten wie folgt konfiguriert ist:
+ Ausgehende TCP-443-Regel in der Sicherheitsgruppe.
+ Ausgehende TCP-443-Regel in NACL.
+ TCP-Regel 1024-65535 für eingehenden Datenverkehr in NACL.
+ NAT/IGW in der Routing-Tabelle, um Konnektivität zu einem S3-Endpunkt bereitzustellen. Wenn die Instance keinen Internetzugang hat, stellen Sie ihr Konnektivität mit dem S3-Endpunkt zur Verfügung. Fügen Sie dazu einen S3-Gateway-Endpunkt in der VPC hinzu und integrieren Sie ihn in die Routing-Tabelle des verwalteten Knotens.

### Problem: Das Patchen schlägt fehl und es wird die Meldung „Installationsfehler: dpkg: Fehler:dpkg-Frontend ist durch einen anderen Prozess gesperrt“ angezeigt
<a name="dpkg-frontend-locked"></a>

**Problem**: Das Patchen schlägt mit einem Fehler ähnlich dem folgenden fehl:

```
install errors: dpkg: error: dpkg frontend is locked by another process
failed to run commands: exit status 2
Failed to install package; install status Failed
```

**Ursache**: Der Paketmanager führt bereits einen anderen Prozess auf einem verwalteten Knoten auf Betriebssystemebene aus. Wenn der Abschluss dieses anderen Prozesses viel Zeit in Anspruch nimmt, kann es bei der Patch-Operation von Patch Manager zu einem Timeout kommen und ein Fehler auftreten.

**Lösung**: Führen Sie nach Abschluss des anderen Prozesses, der den Paketmanager verwendet, einen neuen Patchvorgang aus.

### Problem: Das Patchen auf Ubuntu Server schlägt fehl und es wird der Fehler „dpkg wurde unterbrochen“ angezeigt
<a name="dpkg-interrupted"></a>

**Problem**: Auf Ubuntu Server schlägt das Patchen mit einem Fehler ähnlich dem folgenden fehl:

```
E: dpkg was interrupted, you must manually run
'dpkg --configure -a' to correct the problem.
```

**Ursache**: Ein oder mehrere Pakete sind falsch konfiguriert.

**Lösung**: Führen Sie die folgenden Schritte aus:

1. Prüfen Sie, welche Pakete betroffen sind und welche Probleme bei den einzelnen Paketen bestehen, indem Sie nacheinander die folgenden Befehle ausführen:

   ```
   sudo apt-get check
   ```

   ```
   sudo dpkg -C
   ```

   ```
   dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' | grep -E ^.[^nci]
   ```

1. Korrigieren Sie die fehlerhaften Pakete, indem Sie den folgenden Befehl ausführen:

   ```
   sudo dpkg --configure -a
   ```

1. Wenn der vorherige Befehl das Problem nicht vollständig behoben hat, führen Sie den folgenden Befehl aus:

   ```
   sudo apt --fix-broken install
   ```

### Problem: Das Paketmanager-Dienstprogramm kann eine Paketabhängigkeit nicht auflösen
<a name="unresolved-dependency"></a>

**Problem**: Der native Paketmanager auf dem verwalteten Knoten kann eine Paketabhängigkeit nicht auflösen und das Patchen schlägt fehl. Das folgende Beispiel für eine Fehlermeldung weist auf diese Art von Fehler auf einem Betriebssystem hin, das `yum` als Paketmanager verwendet.

```
09/22/2020 08:56:09 root [ERROR]: yum update failed with result code: 1, 
message: [u'rpm-python-4.11.3-25.amzn2.0.3.x86_64 requires rpm = 4.11.3-25.amzn2.0.3', 
u'awscli-1.18.107-1.amzn2.0.1.noarch requires python2-botocore = 1.17.31']
```

**Ursache**: Patch Manager verwendet auf Linux-Betriebssystemen den systemeigenen Paketmanager auf der Maschine, um Patch-Operationen wie `yum`, `dnf`, `apt` und `zypper` auszuführen. Die Anwendungen erkennen, installieren, aktualisieren oder entfernen abhängige Pakete bei Bedarf automatisch. Einige Bedingungen können jedoch dazu führen, dass der Paketmanager einen Abhängigkeitsvorgang nicht abschließen kann, wie zum Beispiel:
+ Auf dem Betriebssystem sind mehrere widersprüchliche Repositorys konfiguriert.
+ Auf eine Remote-Repository-URL kann aufgrund von Netzwerkproblemen nicht zugegriffen werden.
+ Im Repository wurde ein Paket für die falsche Architektur gefunden.

**Lösung**: Das Patchen kann aufgrund eines Abhängigkeitsproblems aus einer Vielzahl von Gründen fehlschlagen. Wir empfehlen Ihnen daher, sich an uns AWS Support zu wenden, um Ihnen bei der Problembehebung behilflich zu sein.

### Problem: Fehler bei der Abhängigkeit von Zypper-Paketsperren auf verwalteten SLES-Knoten
<a name="patch-manager-troubleshooting-linux-zypper-locks"></a>

**Problem**: Wenn Sie `AWS-RunPatchBaseline` mit dem `Install`-Vorgang auf SUSE Linux Enterprise Server-Instances ausführen, schlägt das Patchen fehl und es treten Fehler bei der Abhängigkeitsprüfung auf, die mit Paketsperren zusammenhängen. Sie könnten Fehlermeldungen ähnlich der folgenden erhalten:

```
Problem: mock-pkg-has-dependencies-0.2.0-21.adistro.noarch requires mock-pkg-standalone = 0.2.0, but this requirement cannot be provided
  uninstallable providers: mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
 Solution 1: remove lock to allow installation of mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
 Solution 2: do not install mock-pkg-has-dependencies-0.2.0-21.adistro.noarch
 Solution 3: break mock-pkg-has-dependencies-0.2.0-21.adistro.noarch by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/3/c] (c): c
```

In diesem Beispiel ist das Paket `mock-pkg-standalone` gesperrt, was Sie überprüfen könnten, indem Sie `sudo zypper locks` ausführen und in der Ausgabe nach diesem Paketnamen suchen.

Oder Sie sehen möglicherweise Protokolleinträge, die auf Fehlschläge bei der Abhängigkeitsprüfung hinweisen:

```
Encountered a known exception in the CLI Invoker: CLIInvokerError(error_message='Dependency check failure during commit process', error_code='4')
```

**Anmerkung**  
Dieses Problem tritt nur während `Install`-Vorgängen auf. `Scan`-Vorgänge wenden keine Paketsperren an und sind auch nicht von vorhandenen Sperren betroffen.“

**Ursache**: Dieser Fehler tritt auf, wenn Zypper-Paketsperren die Installation oder Aktualisierung von Paketen aufgrund von Abhängigkeitskonflikten verhindern. Paketsperren können aus verschiedenen Gründen vorhanden sein:
+ **Vom Kunden angewendete Sperren**: Sie oder Ihr Systemadministrator haben Pakete manuell mithilfe von Zypper-Befehlen gesperrt, wie z. B. `zypper addlock`.
+ **Von Patch Manager abgelehnte Patches**: Patch Manager wendet automatisch Paketsperren an, wenn Sie Pakete in der Liste der **abgelehnten Patches** Ihrer Patch-Baseline angeben, um deren Installation zu verhindern.
+ **Restsperren aufgrund unterbrochener Vorgänge**: In seltenen Fällen, in denen ein Patch-Vorgang unterbrochen wurde (z. B. durch einen Systemneustart), konnte zuvor Patch Manager temporäre Sperren aufheben, restliche Paketsperren verblieben jedoch eventuell auf Ihrem verwalteten Knoten.

**Lösung**: Gehen Sie je nach Ursache folgendermaßen vor, um Probleme mit der Zypper-Paketsperre zu beheben:

**Schritt 1: Identifizieren gesperrter Pakete**

Verbinden Sie sich mit Ihrem verwalteten SLES-Knoten und führen Sie den folgenden Befehl aus, um alle derzeit gesperrten Pakete aufzulisten:

```
sudo zypper locks
```

**Schritt 2: Ermitteln der Quelle der Sperren**
+ Wenn es sich bei den gesperrten Paketen um Pakete handelt, die Sie aus Gründen der Systemstabilität absichtlich gesperrt haben, sollten Sie überlegen, ob sie gesperrt bleiben müssen oder ob sie für das Patching vorübergehend entsperrt werden können.
+ Wenn die gesperrten Pakete mit Einträgen in der Liste der **abgelehnten Patches** Ihrer Patch-Baseline übereinstimmen, handelt es sich wahrscheinlich um Restsperren, die auf einen unterbrochenen Patch-Vorgang zurückzuführen sind. Patch Manager wendet diese Sperren während des normalen Betriebs vorübergehend an und entfernt sie automatisch, wenn der Vorgang abgeschlossen ist. Sie können die Pakete entweder aus der Liste der abgelehnten Pakete entfernen oder Ihre Patch-Baseline-Regeln ändern.
+ Wenn Sie die gesperrten Pakete nicht erkennen und sie nicht absichtlich gesperrt wurden, handelt es sich möglicherweise um Restsperren aus einem zuvor unterbrochenen Patch-Vorgang.

**Schritt 3: Entfernen von Sperren nach Notwendigkeit**

Mit diesem Befehl können Sie bestimmte Paketsperren entfernen:

```
sudo zypper removelock package-name
```

Um alle Paketsperren zu entfernen (mit Vorsicht verwenden), führen Sie folgenden Befehl aus:

```
sudo zypper cleanlocks
```

**Schritt 4: Aktualisieren Ihrer Patch-Baseline (falls zutreffend)**

Wenn die Sperren durch abgelehnte Patches in Ihrer Patch-Baseline verursacht wurden:

1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Wählen Sie im Navigationsbereich **Patch Manager** aus.

1. Wählen Sie die Registerkarte **Patch-Baselines** und dann Ihre benutzerdefinierte Patch-Baseline aus.

1. Wählen Sie **Aktionen**, **Patch-Baseline ändern** aus.

1. Überprüfen Sie im Abschnitt **Abgelehnte Patches** die aufgelisteten Pakete und entfernen Sie alle Pakete, deren Installation zulässig sein sollte.

1. Wählen Sie **Änderungen speichern ** aus.

**Schritt 5: Wiederholen des Patch-Vorgangs**

Nachdem Sie die problematischen Sperren entfernt und gegebenenfalls Ihre Patch-Baseline aktualisiert haben, führen Sie das `AWS-RunPatchBaseline`-Dokument erneut aus.

**Anmerkung**  
Wenn während der `Install`-Vorgänge Patch Manager Sperren für abgelehnte Patches anwendet, ist es so konzipiert, dass diese Sperren nach Abschluss des Patch-Vorgangs automatisch aufgehoben werden. Wenn Sie diese Sperren bei der Ausführung von `sudo zypper locks` sehen, bedeutet das, dass ein früherer Patch-Vorgang unterbrochen wurde, bevor die Aufhebung durchgeführt werden konnte. Wenn ein Patch-Vorgang jedoch unterbrochen wird, ist möglicherweise eine manuelle Aufhebung erforderlich, wie in diesem Verfahren beschrieben.

**Prävention**: Vermeiden Sie zukünftige Zypper-Sperrkonflikte wie folgt:
+ Prüfen Sie die Liste der abgelehnten Patches Ihrer Patch-Baseline sorgfältig, um sicherzustellen, dass sie nur Pakete enthält, die Sie wirklich ausschließen möchten.
+ Vermeiden Sie es, Pakete, die möglicherweise als Abhängigkeiten für Sicherheitsupdates benötigt werden, manuell zu sperren.
+ Wenn Sie Pakete manuell sperren müssen, dokumentieren Sie die Gründe dafür und überprüfen Sie die Sperren regelmäßig.
+ Stellen Sie sicher, dass die Patch-Vorgänge erfolgreich abgeschlossen werden und nicht durch Systemneustarts oder andere Faktoren unterbrochen werden.
+ Überwachen Sie Patch-Vorgänge bis zum Abschluss und vermeiden Sie es, sie durch Systemneustarts oder andere Aktionen zu unterbrechen, die das ordnungsgemäße Löschen temporärer Sperren verhindern könnten.

### Problem: Die Sperre kann nicht abgerufen werden. Ein weiterer Patch-Vorgang ist im Gange.
<a name="patch-manager-troubleshooting-linux-concurrent-lock"></a>

**Problem**: Beim Ausführen `AWS-RunPatchBaseline` schlägt das Patchen mit Fehlercode 4 und der folgenden Fehlermeldung fehl.

```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```

**Ursache**: Dieser Fehler tritt auf, wenn mehrere Patch-Operationen versuchen, auf demselben verwalteten Knoten gleichzeitig auszuführen. Die Sperrdatei verhindert gleichzeitige Patch-Vorgänge, um Konflikte zu vermeiden und die Systemstabilität zu gewährleisten.

**Lösung**: Stellen Sie sicher, dass Patchvorgänge nicht so geplant sind, dass sie gleichzeitig auf demselben verwalteten Knoten ausgeführt werden. Überprüfen Sie die folgenden Konfigurationen, um Planungskonflikte zu identifizieren und zu lösen:
+ **Patch-Richtlinien**: Überprüfen Sie Ihre Quick Setup-Patchrichtlinien-Konfigurationen, um sicherzustellen, dass sie sich nicht mit anderen Patch-Zeitplänen überschneiden.
+ **Wartungsfenster**: Überprüfen Sie die Zuordnungen Ihrer Wartungsfenster, um sicherzustellen, dass nicht mehrere Fenster auf dieselben verwalteten Knoten abzielen, wobei sich die Patch-Aufgaben zu überschneidenden Zeiten befinden.
+ **Manuelle Patch-Now-Operationen**: Vermeiden Sie es, manuelle **Patch-Now-Operationen** zu initiieren, während das geplante Patchen ausgeführt wird.

## Fehler beim Ausführen von `AWS-RunPatchBaseline` unter Windows Server
<a name="patch-manager-troubleshooting-windows"></a>

**Topics**
+ [Problem: Nicht übereinstimmende Produktpaare family/product](#patch-manager-troubleshooting-product-family-mismatch)
+ [Problem: `AWS-RunPatchBaseline`-Ausgabe gibt einen `HRESULT` (Windows Server) zurück](#patch-manager-troubleshooting-hresult)
+ [Problem: Der verwaltete Knoten hat keinen Zugriff auf Windows Update Catalog oder WSUS](#patch-manager-troubleshooting-instance-access)
+ [Problem: PatchBaselineOperations PowerShell Das Modul kann nicht heruntergeladen werden](#patch-manager-troubleshooting-module-not-downloadable)
+ [Problem: fehlende Patches](#patch-manager-troubleshooting-missing-patches)
+ [Problem: Die Sperre kann nicht erworben werden. Ein weiterer Patch-Vorgang ist im Gange.](#patch-manager-troubleshooting-windows-concurrent-lock)

### Problem: Nicht übereinstimmende Produktpaare family/product
<a name="patch-manager-troubleshooting-product-family-mismatch"></a>

**Problem**: Wenn Sie eine Patch-Baseline in der Systems Manager-Konsole erstellen, geben Sie eine Produktfamilie und ein Produkt an. Beispiel:
+ **Product Family (Produktfamilie)**: `Office`

  **Produkt**: `Office 2016`

**Ursache**: Wenn Sie versuchen, eine Patch-Baseline mit einem nicht übereinstimmenden family/product Produktpaar zu erstellen, wird eine Fehlermeldung angezeigt. Dies kann folgende Ursachen haben:
+ Sie haben eine gültige Kombination aus Produktfamilie und Produktpaar ausgewählt, dann jedoch die Auswahl der Produktfamilie entfernt.
+ Sie haben ein Produkt aus der Unterliste **Obsolete or mismatched options (Veraltete oder nicht übereinstimmende Optionen)** statt aus der Unterliste **Available and matching options (Verfügbare und übereinstimmende Optionen)** ausgewählt. 

  Artikel in der Produktunterliste **Veraltete oder nicht übereinstimmende Optionen** wurden möglicherweise fälschlicherweise über ein SDK oder AWS Command Line Interface den Befehl () eingegeben.AWS CLI`create-patch-baseline` Dadurch kann es zu einem Schreibfehler oder einer falschen Zuordnung eines Produkts zu einer Produktfamilie kommen. Ein Produkt kann auch in der Unterliste **Obsolete or mismatched options (Veraltete oder nicht übereinstimmende Optionen)** enthalten sein, wenn es für eine vorherige Patch-Baseline angegeben wurde, aber keine Patches für das Produkt von Microsoft verfügbar sind. 

**Lösung**: Um dieses Problem in der Konsole zu vermeiden, wählen Sie immer Optionen aus den Unterlisten **Currently available options (Derzeit verfügbare Optionen)** aus.

Um diejenigen Produkte anzuzeigen, für die Patches verfügbar sind, können Sie auch den Befehl `[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)` in der AWS CLI oder den API-Befehl `[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)` verwenden.

### Problem: `AWS-RunPatchBaseline`-Ausgabe gibt einen `HRESULT` (Windows Server) zurück
<a name="patch-manager-troubleshooting-hresult"></a>

**Problem:** Sie haben eine Fehlermeldung wie die folgende erhalten.

```
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when 
attempting to search Windows Update.
Exception Level 1:
 Error Message: Exception from HRESULT: 0x80240437
 Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)..
(Windows updates)
11/22/2020 09:17:30 UTC | Info | Searching for Windows Updates.
11/22/2020 09:18:59 UTC | Error | Searching for updates resulted in error: Exception from HRESULT: 0x80240437
----------ERROR-------
failed to run commands: exit status 4294967295
```

**Ursache**: Diese Ausgabe weist darauf hin, dass das systemeigene Windows Update die Patchvorgänge nicht ausführen APIs konnte.

**Lösung**: Überprüfen Sie den `HResult`-Code in den folgenden Themen auf microsoft.com, um Schritte zur Fehlerbehebung zum Beheben des Fehlers zu ermitteln:
+ [Windows-Update-Fehlercodes nach Komponenten](https://learn.microsoft.com/en-us/windows/deployment/update/windows-update-error-reference) 
+ [Häufige Fehler und Abhilfemaßnahmen für Windows Update](https://learn.microsoft.com/en-us/troubleshoot/windows-client/deployment/common-windows-update-errors) 

### Problem: Der verwaltete Knoten hat keinen Zugriff auf Windows Update Catalog oder WSUS
<a name="patch-manager-troubleshooting-instance-access"></a>

**Problem:** Sie haben eine Fehlermeldung wie die folgende erhalten.

```
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.

Extracting PatchBaselineOperations zip file contents to temporary folder.

Verifying SHA 256 of the PatchBaselineOperations PowerShell module files.

Successfully downloaded and installed the PatchBaselineOperations PowerShell module.

Patch Summary for

PatchGroup :

BaselineId :

Baseline : null

SnapshotId :

RebootOption : RebootIfNeeded

OwnerInformation :

OperationType : Scan

OperationStartTime : 1970-01-01T00:00:00.0000000Z

OperationEndTime : 1970-01-01T00:00:00.0000000Z

InstalledCount : -1

InstalledRejectedCount : -1

InstalledPendingRebootCount : -1

InstalledOtherCount : -1

FailedCount : -1

MissingCount : -1

NotApplicableCount : -1

UnreportedNotApplicableCount : -1

EC2AMAZ-VL3099P - PatchBaselineOperations Assessment Results - 2020-12-30T20:59:46.169

----------ERROR-------

Invoke-PatchBaselineOperation : Exception Details: An error occurred when attempting to search Windows Update.

Exception Level 1:

Error Message: Exception from HRESULT: 0x80072EE2

Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)

at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String

searchCriteria)

At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\3d2d4864-04b7-4316-84fe-eafff1ea58

e3\PatchWindows\_script.ps1:230 char:13

+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOperation:InstallWindowsUpdateOperation) [Inv

oke-PatchBaselineOperation], Exception

+ FullyQualifiedErrorId : Exception Level 1:

Error Message: Exception Details: An error occurred when attempting to search Windows Update.

Exception Level 1:

Error Message: Exception from HRESULT: 0x80072EE2

Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)

at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String searc

---Error truncated----
```

**Ursache**: Dieser Fehler kann mit den Windows Update-Komponenten oder einer fehlenden Konnektivität zum Windows Update Catalog oder Windows Server Update Services (WSUS) zusammenhängen.

**Lösung**: Bestätigen Sie, dass der verwaltete Knoten über ein Internet-Gateway, ein NAT-Gateway oder eine NAT-Instance eine Verbindung zum [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/home.aspx) hergestellt hat. Wenn Sie WSUS verwenden, bestätigen Sie, dass der verwaltete Knoten eine Verbindung zum WSUS-Server in Ihrer Umgebung hat. Wenn Konnektivität für das beabsichtigte Ziel verfügbar ist, überprüfen Sie die Microsoft-Dokumentation auf andere mögliche Ursachen für `HResult 0x80072EE2`. Dies kann auf ein Problem auf Betriebssystemebene hinweisen. 

### Problem: PatchBaselineOperations PowerShell Das Modul kann nicht heruntergeladen werden
<a name="patch-manager-troubleshooting-module-not-downloadable"></a>

**Problem:** Sie haben eine Fehlermeldung wie die folgende erhalten.

```
Preparing to download PatchBaselineOperations PowerShell module from S3.
                    
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
----------ERROR-------

C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\aaaaaaaa-bbbb-cccc-dddd-4f6ed6bd5514\

PatchWindows\_script.ps1 : An error occurred when executing PatchBaselineOperations: Unable to connect to the remote server

+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException

+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,_script.ps1

failed to run commands: exit status 4294967295
```

**Lösung**: Überprüfen Sie die Konnektivität und Berechtigungen für Amazon Simple Storage Service (Amazon S3) des verwalteten Knoten. Für die Rolle des verwalteten Knotens AWS Identity and Access Management (IAM) müssen die unter angegebenen Mindestberechtigungen verwendet werden. [SSM AgentKommunikation mit AWS verwalteten S3-Buckets](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) Der Knoten muss über den Amazon-S3-Gateway-Endpunkt, das NAT-Gateway oder das Internet-Gateway mit dem Amazon-S3-Endpunkt kommunizieren. Weitere Informationen zu den VPC-Endpunktanforderungen für AWS Systems Manager SSM Agent (SSM Agent) finden Sie unter[Die Sicherheit von EC2-Instances mithilfe von VPC-Endpunkten für Systems Manager verbessern](setup-create-vpc.md). 

### Problem: fehlende Patches
<a name="patch-manager-troubleshooting-missing-patches"></a>

**Problem**: `AWS-RunPatchbaseline` wurde erfolgreich abgeschlossen, aber es fehlen einige Patches.

Nachfolgend finden Sie einige häufige Auslöser und deren Lösungen.

**Ursache 1**: Die Baseline ist nicht effektiv.

**Lösung 1**: Führen Sie die folgenden Schritte aus, um zu überprüfen, ob dies die Ursache ist.

1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)

1. Wählen Sie im Navigationsbereich **Run Command** aus.

1. Wählen Sie die Registerkarte **Befehlsverlauf** und dann den Befehl aus, dessen Baseline Sie überprüfen möchten.

1. Wählen Sie den verwalteten Knoten aus, dem Patches fehlen.

1. Wählen Sie **Schritt 1 – Ausgabe** aus und finden Sie den `BaselineId`-Wert.

1. Aktivieren Sie die zugewiesene [Patch-Baseline-Konfiguration](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom), d. h. Betriebssystem, Produktname, Klassifizierung und Schweregrad für die Patch-Baseline.

1. Rufen Sie den [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/home.aspx) auf.

1. Suchen Sie im Artikel der Microsoft Knowledge Base IDs (KB) (z. B. KB3216916).

1. Stellen Sie sicher, dass der Wert unter **Product** (Produkt) dem Ihres verwalteten Knotens entspricht, und wählen Sie den entsprechenden **Title** (Titel) aus. Ein neues Fenser **Details aktualisieren** wird geöffnet.

1. In der Registerkarte **Übersicht** müssen **Klassifizierung** und **Schweregrad des MSRC** der Patch-Baseline-Konfiguration entsprechen, die Sie zuvor gefunden haben.

**Ursache 2**: Das Patch wurde ersetzt.

**Lösung 2**: Führen Sie die folgenden Schritte aus, um zu überprüfen, ob dies der Fall ist.

1. Rufen Sie den [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/home.aspx) auf.

1. Suchen Sie im Artikel der Microsoft Knowledge Base IDs (KB) (z. B. KB3216916).

1. Stellen Sie sicher, dass der Wert unter **Product** (Produkt) dem Ihres verwalteten Knotens entspricht, und wählen Sie den entsprechenden **Title** (Titel) aus. Ein neues Fenser **Details aktualisieren** wird geöffnet.

1. Gehen Sie zur Registerkarte **Paketdetails**. Suchen Sie nach einem Eintrag unter dem Header **Dieses Update wurde durch die folgenden Updates ersetzt:**.

**Ursache 3**: Dasselbe Patch hat möglicherweise unterschiedliche KB-Nummern, da die WSUS- und Windows-Online-Updates von Microsoft als unabhängige Versionskanäle behandelt werden.

**Lösung 3**: Überprüfen Sie die Berechtigung des Patches. Wenn das Paket unter WSUS nicht verfügbar ist, installieren Sie [OS Build 14393.3115](https://support.microsoft.com/en-us/topic/july-16-2019-kb4507459-os-build-14393-3115-511a3df6-c07e-14e3-dc95-b9898a7a7a57). Wenn das Paket für alle Betriebssystem-Builds verfügbar ist, installieren Sie [OS-Builds 18362.1256 und 18363.1256](https://support.microsoft.com/en-us/topic/december-8-2020-kb4592449-os-builds-18362-1256-and-18363-1256-c448f3df-a5f1-1d55-aa31-0e1cf7a440a9).

### Problem: Die Sperre kann nicht erworben werden. Ein weiterer Patch-Vorgang ist im Gange.
<a name="patch-manager-troubleshooting-windows-concurrent-lock"></a>

**Problem**: Beim Ausführen `AWS-RunPatchBaseline` schlägt das Patchen mit Fehlercode 4 und der folgenden Fehlermeldung fehl.

```
Cannot acquire lock on C:\ProgramData\Amazon\SSM\patch-baseline-concurrent.lock. Another patching operation is in progress.
```

**Ursache**: Dieser Fehler tritt auf, wenn mehrere Patch-Operationen versuchen, auf demselben verwalteten Knoten gleichzeitig auszuführen. Die Sperrdatei verhindert gleichzeitige Patch-Vorgänge, um Konflikte zu vermeiden und die Systemstabilität zu gewährleisten.

**Lösung**: Stellen Sie sicher, dass Patchvorgänge nicht so geplant sind, dass sie gleichzeitig auf demselben verwalteten Knoten ausgeführt werden. Überprüfen Sie die folgenden Konfigurationen, um Planungskonflikte zu identifizieren und zu lösen:
+ **Patch-Richtlinien**: Überprüfen Sie Ihre Quick Setup-Patchrichtlinien-Konfigurationen, um sicherzustellen, dass sie sich nicht mit anderen Patch-Zeitplänen überschneiden.
+ **Wartungsfenster**: Überprüfen Sie die Zuordnungen Ihrer Wartungsfenster, um sicherzustellen, dass nicht mehrere Fenster auf dieselben verwalteten Knoten abzielen, wobei sich die Patch-Aufgaben zu überschneidenden Zeiten befinden.
+ **Manuelle Patch-Now-Operationen**: Vermeiden Sie es, manuelle **Patch-Now-Operationen** zu initiieren, während das geplante Patchen ausgeführt wird.

## Fehler bei der Ausführung `AWS-RunPatchBaseline` auf macOS
<a name="patch-manager-troubleshooting-macos"></a>

**Topics**
+ [Problem: Die Sperre kann nicht abgerufen werden. Ein weiterer Patch-Vorgang ist im Gange.](#patch-manager-troubleshooting-macos-concurrent-lock)

### Problem: Die Sperre kann nicht abgerufen werden. Ein weiterer Patch-Vorgang ist im Gange.
<a name="patch-manager-troubleshooting-macos-concurrent-lock"></a>

**Problem**: Beim Ausführen `AWS-RunPatchBaseline` schlägt das Patchen mit Fehlercode 4 und der folgenden Fehlermeldung fehl.

```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```

**Ursache**: Dieser Fehler tritt auf, wenn mehrere Patch-Operationen versuchen, auf demselben verwalteten Knoten gleichzeitig auszuführen. Die Sperrdatei verhindert gleichzeitige Patch-Vorgänge, um Konflikte zu vermeiden und die Systemstabilität zu gewährleisten.

**Lösung**: Stellen Sie sicher, dass Patchvorgänge nicht so geplant sind, dass sie gleichzeitig auf demselben verwalteten Knoten ausgeführt werden. Überprüfen Sie die folgenden Konfigurationen, um Planungskonflikte zu identifizieren und zu lösen:
+ **Patch-Richtlinien**: Überprüfen Sie Ihre Quick Setup-Patchrichtlinien-Konfigurationen, um sicherzustellen, dass sie sich nicht mit anderen Patch-Zeitplänen überschneiden.
+ **Wartungsfenster**: Überprüfen Sie die Zuordnungen Ihrer Wartungsfenster, um sicherzustellen, dass nicht mehrere Fenster auf dieselben verwalteten Knoten abzielen, wobei sich die Patch-Aufgaben zu überschneidenden Zeiten befinden.
+ **Manuelle Patch-Now-Operationen**: Vermeiden Sie es, manuelle **Patch-Now-Operationen** zu initiieren, während das geplante Patchen ausgeführt wird.

## Verwenden von Automation-Runbooks AWS Support
<a name="patch-manager-troubleshooting-using-support-runbooks"></a>

AWS Support stellt zwei Automation-Runbooks bereit, mit denen Sie bestimmte Probleme im Zusammenhang mit Patches beheben können.
+ `AWSSupport-TroubleshootWindowsUpdate` – Das [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html)-Runbook wird verwendet, um Probleme zu identifizieren, bei denen die Windows Server-Updates für Amazon Elastic Compute Cloud (Amazon EC2) Windows Server-Instances fehlschlagen könnten.
+ `AWSSupport-TroubleshootPatchManagerLinux` – Das [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html)-Runbook behebt häufig auftretende Probleme, die zu einem Patch-Fehler auf Linux-basierten verwalteten Knoten führen können, mithilfe von Patch Manager. Das Hauptziel dieses Runbooks besteht darin, die Hauptursache des Fehlers beim Patch-Befehl zu ermitteln und einen Plan zur Behebung vorzuschlagen.

**Anmerkung**  
Für die Ausführung von Automation-Runbooks fallen Gebühren an. Weitere Informationen finden Sie unter [AWS Systems Manager Preise für Automatisierung](https://aws.amazon.com/systems-manager/pricing/#Automation).

## Kontaktaufnahme AWS Support
<a name="patch-manager-troubleshooting-contact-support"></a>

Wenn Sie Problembehandlungs-Lösungen in diesem Abschnitt oder im bschnitt zu Systems-Manager-Problemen in [AWS re:Post](https://repost.aws/tags/TA-UbbRGVYRWCDaCvae6itYg/aws-systems-manager) nicht finden können und einen [Developer-, Business- oder Enterprise- Support -Plan](https://aws.amazon.com/premiumsupport/plans) haben, können Sie unter [AWS Support](https://aws.amazon.com/premiumsupport/) einen technischen Supportfall erstellen.

Sammeln Sie die folgenden Artikel Support, bevor Sie Kontakt aufnehmen:
+ [SSM-Agent-Protokolle](ssm-agent-logs.md)
+ Run Command-Befehls-ID, Wartungsfenster-ID oder Automatisierungsausführungs-ID
+ Sammeln Sie für von Windows Server verwaltete Knoten auch Folgendes:
  + `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs`, wie auf der **Windows**-Registerkarte von [Wie Patches installiert werden](patch-manager-installing-patches.md) beschrieben
  + Windows Update-Protokolle: Für Windows Server 2012 R2 und älter verwenden Sie `%windir%/WindowsUpdate.log`. Führen Sie für Windows Server 2016 und neuere Versionen zuerst den PowerShell Befehl aus, [https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps](https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps)bevor Sie `%windir%/WindowsUpdate.log`
+ Sammeln Sie für Linux-verwaltete Knoten auch Folgendes:
  + Der Inhalt des Verzeichnisses `/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`