• 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 Tutorials
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
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
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
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
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).