• 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. # Patch-Baselines 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 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 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 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 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 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 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 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) **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 **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) **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 **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 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 **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 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 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 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.