• 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.
# SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaselineWithHooks`
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
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
`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`
**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`
**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`
**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`
**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`
**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`
**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).