• 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.
# Fehlerbehebung für Patch Manager
Im Folgenden finden Sie Informationen zur Behandlung von Problemen mit Patch Manager, einem Tool in AWS Systems Manager.
**Topics**
+ [Problem: Fehler „Invoke-PatchBaselineOperation : Zugriff verweigert“ oder Fehler „Datei kann nicht von S3 heruntergeladen werden“ für `baseline_overrides.json`](#patch-manager-troubleshooting-patch-policy-baseline-overrides)
+ [Problem: Das Patchen schlägt fehl, ohne dass eine offensichtliche Ursache oder Fehlermeldung vorliegt](#race-condition-conflict)
+ [Problem: Unerwartete Patch-Compliance-Ergebnisse](#patch-manager-troubleshooting-compliance)
+ [Fehler beim Ausführen von `AWS-RunPatchBaseline` unter Linux](#patch-manager-troubleshooting-linux)
+ [Fehler beim Ausführen von `AWS-RunPatchBaseline` unter Windows Server](#patch-manager-troubleshooting-windows)
+ [Fehler bei der Ausführung `AWS-RunPatchBaseline` auf macOS](#patch-manager-troubleshooting-macos)
+ [Verwenden von Automation-Runbooks AWS Support](#patch-manager-troubleshooting-using-support-runbooks)
+ [Kontaktaufnahme AWS Support](#patch-manager-troubleshooting-contact-support)
## Problem: Fehler „Invoke-PatchBaselineOperation : Zugriff verweigert“ oder Fehler „Datei kann nicht von S3 heruntergeladen werden“ für `baseline_overrides.json`
**Problem**: Wenn die von Ihrer Patch-Richtlinie festgelegten Patching-Vorgänge ausgeführt werden, erhalten Sie eine Fehlermeldung ähnlich dem folgenden Beispiel.
------
#### [ Example error on Windows Server ]
```
----------ERROR-------
Invoke-PatchBaselineOperation : Access Denied
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestr
ation\792dd5bd-2ad3-4f1e-931d-abEXAMPLE\PatchWindows\_script.ps1:219 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOpera
tion:InstallWindowsUpdateOperation) [Invoke-PatchBaselineOperation], Amazo
nS3Exception
+ FullyQualifiedErrorId : PatchBaselineOperations,Amazon.Patch.Baseline.Op
erations.PowerShellCmdlets.InvokePatchBaselineOperation
failed to run commands: exit status 0xffffffff
```
------
#### [ Example error on Linux ]
```
[INFO]: Downloading Baseline Override from s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json
[ERROR]: Unable to download file from S3: s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json.
[ERROR]: Error loading entrance module.
```
------
**Ursache**: Sie haben eine Patch-Richtlinie in Quick Setup erstellt, und einige Ihrer verwalteten Knoten waren bereits mit einem Instance-Profil (für EC2-Instances) oder einer Servicerolle (für Nicht-EC2-Maschinen) versehen.
Sie haben jedoch das Kontrollkästchen **Erforderliche IAM-Richtlinien zu vorhandenen Instance-Profilen hinzufügen, die an Ihre Instances angehängt** sind, nicht aktiviert, wie in der folgenden Abbildung dargestellt.
![\[\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/QS-instance-profile-option.png)
Wenn Sie eine Patch-Richtlinie erstellen, wird auch ein Amazon-S3-Bucket erstellt, in dem die `baseline_overrides.json` Konfigurationsdatei der Richtlinie gespeichert wird. Wenn Sie bei der Erstellung der Richtlinie das Kontrollkästchen **Erforderliche IAM-Richtlinien zu bestehenden Instance-Profilen hinzufügen, die mit Ihren Instances verbunden sind**, nicht aktivieren, werden die IAM-Richtlinien und Ressourcen-Tags, die für den Zugriff auf `baseline_overrides.json` im S3-Bucket erforderlich sind, nicht automatisch zu Ihren bestehenden IAM-Instance-Profilen und Servicerollen hinzugefügt.
**Lösung 1**: Löschen Sie die bestehende Patch-Richtlinienkonfiguration und erstellen Sie dann eine neue. Aktivieren Sie dabei das Kontrollkästchen **Erforderliche IAM-Richtlinien zu bestehenden Instance-Profilen hinzufügen, die mit Ihren Instances verbunden** sind. Diese Auswahl wendet die mit dieser Quick Setup-Konfiguration erstellten IAM-Richtlinien auf Knoten an, denen bereits ein Instance-Profil oder eine Servicerolle zugewiesen ist. (Quick Setup fügt standardmäßig die erforderlichen Richtlinien zu Instances und Knoten hinzu, die *noch nicht* über Instance-Profile oder Servicerollen verfügen.) Weitere Informationen finden Sie unter [Automatisieren von unternehmensweitem Patching mithilfe einer Quick Setup-Patch-Richtlinie](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html).
**Lösung 2**: Fügen Sie die erforderlichen Berechtigungen und Tags manuell zu jedem IAM-Instance-Profil und jeder IAM-Servicerolle hinzu, die Sie mit Quick Setup verwenden. Detaillierte Anweisungen finden Sie unter [Berechtigungen für den S3-Bucket mit der Patch-Richtlinie](quick-setup-patch-manager.md#patch-policy-s3-bucket-permissions).
## Problem: Das Patchen schlägt fehl, ohne dass eine offensichtliche Ursache oder Fehlermeldung vorliegt
**Problem**: Ein Patch-Vorgang schlägt fehl, ohne dass eine Fehlermeldung zurückgegeben wird.
**Mögliche Ursache**: Beim Patchen verwalteter Knoten kann die Ausführung des Dokuments unterbrochen und als fehlgeschlagen markiert werden, obwohl die Patches erfolgreich installiert wurden. Dies kann der Fall sein, wenn das System während des Patchvorgangs einen unerwarteten Neustart einleitet (z. B. um Firmware-Updates oder Funktionen wie) anzuwenden. SecureBoot Der SSM-Agent kann den Status der Dokumentausführung bei externen Neustarts nicht beibehalten und wieder aufnehmen, was dazu führt, dass die Ausführung als fehlgeschlagen gemeldet wird.
**Lösung**: Um den Status der Patch-Installation nach einer fehlgeschlagenen Ausführung zu überprüfen, führen Sie einen `Scan` Patch-Vorgang aus und überprüfen Sie anschließend die Patch-Kompatibilitätsdaten in Patch Manager, um den aktuellen Konformitätsstatus zu beurteilen.
Wenn Sie feststellen, dass externe Neustarts in diesem Szenario nicht die Ursache für den Fehler waren, empfehlen wir Ihnen, sich an uns zu wenden. [AWS Support](#patch-manager-troubleshooting-contact-support)
## Problem: Unerwartete Patch-Compliance-Ergebnisse
**Problem**: Bei der Überprüfung der nach einem `Scan`-Vorgang generierten Details zur Patching-Compliance enthalten die Ergebnisse Informationen, die nicht die in Ihrer Patch-Baseline festgelegten Regeln widerspiegeln. Beispielsweise wird eine Ausnahme, die Sie der Liste **Rejected patches** (Abgelehnte Patches) in einer Patch-Baseline hinzugefügt haben, als `Missing` aufgeführt. Oder als `Important` klassifizierte Patches werden als fehlend aufgeführt, obwohl Ihre Patch-Baseline nur `Critical`-Patches angibt.
**Ursache**: Patch Manager unterstützt derzeit mehrere Methoden zum Ausführen von `Scan`-Operationen:
+ Eine in Quick Setup konfigurierte Patch-Richtlinie
+ Eine in Quick Setup konfigurierte Host-Management-Option
+ Ein Wartungsfenster zum Ausführen eines Patch-`Scan` oder einer `Install`-Aufgabe
+ Eine On-Demand **Patch now**-Operation (Jetzt patchen)
Wenn eine `Scan`-Operation ausgeführt wird, überschreibt dies die Compliance-Details aus dem letzten Scan. Wenn Sie mehr als eine Methode zum Ausführen einer `Scan`-Operation eingerichtet haben und diese unterschiedliche Patch-Baselines mit unterschiedlichen Regeln verwenden, führt dies zu unterschiedlichen Patch-Compliance-Ergebnissen.
**Lösung**: Um unerwartete Patch-Compliance-Ergebnisse zu vermeiden, empfehlen wir, jeweils nur eine Methode zum Ausführen der Patch Manager `Scan`-Operation zu verwenden. Weitere Informationen finden Sie unter [Identifizieren der Ausführung, die Patch-Compliance-Daten erstellt hat](patch-manager-compliance-data-overwrites.md).
## Fehler beim Ausführen von `AWS-RunPatchBaseline` unter Linux
**Topics**
+ [Problem: Fehler 'No such file or directory'](#patch-manager-troubleshooting-linux-1)
+ [Problem: Fehler 'another process has acquired yum lock'](#patch-manager-troubleshooting-linux-2)
+ [Problem: Fehler 'Permission denied / failed to run commands'](#patch-manager-troubleshooting-linux-3)
+ [Problem: Fehler 'Unable to download payload'](#patch-manager-troubleshooting-linux-4)
+ [Problem: Fehler 'unsupported package manager and python version combination'](#patch-manager-troubleshooting-linux-5)
+ [Problem: Patch Manager wendet keine Regeln an, die zum Ausschließen bestimmter Pakete angegeben sind](#patch-manager-troubleshooting-linux-6)
+ [Problem: Patching schlägt fehl und Patch Manager meldet, dass die Erweiterung „Servername Indication“ für TLS nicht verfügbar ist](#patch-manager-troubleshooting-linux-7)
+ [Problem: Patch Manager meldet 'No more mirrors to try'](#patch-manager-troubleshooting-linux-8)
+ [Problem: Patching schlägt fehl mit 'Error code returned from curl is 23'](#patch-manager-troubleshooting-linux-9)
+ [Problem: Patching schlägt mit der Meldung 'Error unpacking rpm package...' fehl](#error-unpacking-rpm)
+ [Problem: Patching schlägt fehl mit 'Fehler auf Serviceseite beim Hochladen des Inventars'](#inventory-upload-error)
+ [Problem: Das Patchen schlägt fehl und die Meldung „Beim Herunterladen von Paketen sind Fehler aufgetreten“ wird angezeigt](#errors-while-downloading)
+ [Problem: Das Patchen schlägt mit einem OOM-Fehler (Out of Memory) fehl](#patch-manager-troubleshooting-linux-oom)
+ [Problem: Patching schlägt fehl mit der Meldung 'Die folgenden Signaturen konnten nicht verifiziert werden, da der öffentliche Schlüssel nicht verfügbar ist'](#public-key-unavailable)
+ [Problem: Das Patchen schlägt fehl und die Meldung '' NoMoreMirrorsRepoError wird angezeigt](#no-more-mirrors-repo-error)
+ [Problem: Das Patchen schlägt mit der Meldung „Payload kann nicht heruntergeladen werden“ fehl](#payload-download-error)
+ [Problem: Das Patchen schlägt fehl und es wird die Meldung „Installationsfehler: dpkg: Fehler:dpkg-Frontend ist durch einen anderen Prozess gesperrt“ angezeigt](#dpkg-frontend-locked)
+ [Problem: Das Patchen auf Ubuntu Server schlägt fehl und es wird der Fehler „dpkg wurde unterbrochen“ angezeigt](#dpkg-interrupted)
+ [Problem: Das Paketmanager-Dienstprogramm kann eine Paketabhängigkeit nicht auflösen](#unresolved-dependency)
+ [Problem: Fehler bei der Abhängigkeit von Zypper-Paketsperren auf verwalteten SLES-Knoten](#patch-manager-troubleshooting-linux-zypper-locks)
+ [Problem: Die Sperre kann nicht abgerufen werden. Ein weiterer Patch-Vorgang ist im Gange.](#patch-manager-troubleshooting-linux-concurrent-lock)
### Problem: Fehler 'No such file or directory'
**Problem**: Wenn Sie `AWS-RunPatchBaseline` ausführen, schlägt das Patchen mit einem der folgenden Fehler fehl.
```
IOError: [Errno 2] No such file or directory: 'patch-baseline-operations-X.XX.tar.gz'
```
```
Unable to extract tar file: /var/log/amazon/ssm/patch-baseline-operations/patch-baseline-operations-1.75.tar.gz.failed to run commands: exit status 155
```
```
Unable to load and extract the content of payload, abort.failed to run commands: exit status 152
```
**Ursache 1**: Zwei Befehle zum Ausführen von `AWS-RunPatchBaseline` wurden gleichzeitig auf demselben verwalteten Knoten ausgeführt. Dies erzeugt eine Race-Bedingung, die in der temporären `file patch-baseline-operations*` nicht richtig erstellt oder auf die nicht richtig zugegriffen wird.
**Ursache 2**: Unzureichender Speicherplatz verbleibt im `/var`-Verzeichnis.
**Lösung 1**: Stellen Sie sicher, dass kein Wartungsfenster zwei oder mehr Run Command Aufgaben umfasst, die `AWS-RunPatchBaseline` mit derselben Prioritätsstufe und auf demselben Ziel IDs ausgeführt werden. Wenn dies der Fall ist, ordnen Sie die Priorität neu an. Run Commandist ein Tool in AWS Systems Manager.
**Lösung 2**: Stellen Sie sicher, dass jeweils nur ein Wartungsfenster Run Command-Aufgaben ausführt, die `AWS-RunPatchBaseline` auf denselben Zielen und nach demselben Zeitplan verwenden. Ändern Sie in diesem Fall den Zeitplan.
**Lösung 3**: Stellen Sie sicher, dass nur eine State Manager-Zuordnung `AWS-RunPatchBaseline` nach demselben Zeitplan ausführt und die gleichen verwalteten Knoten anvisiert. State Manager ist ein Tool in AWS Systems Manager.
**Lösung 4**: Machen Sie genügend Speicherplatz im `/var`-Verzeichnis für die Update-Pakete. frei
### Problem: Fehler 'another process has acquired yum lock'
**Problem**: Wenn Sie `AWS-RunPatchBaseline` ausführen, schlägt das Patchen mit dem folgenden Fehler fehl.
```
12/20/2019 21:41:48 root [INFO]: another process has acquired yum lock, waiting 2 s and retry.
```
**Ursache**: Das `AWS-RunPatchBaseline`-Dokument wurde auf einem verwalteten Knoten ausgeführt, in dem es bereits in einer anderen Operation ausgeführt wird und den `yum`-Paketmanager-Prozess erhalten hat.
**Lösung**: Stellen Sie sicher, dass keine State Manager-Zuordnung, Aufgaben im Wartungsfenster oder andere Konfigurationen, die `AWS-RunPatchBaseline`nach einem Zeitplan ausführen, ungefähr zur gleichen Zeit denselben verwalteten Knoten als Ziel haben.
### Problem: Fehler 'Permission denied / failed to run commands'
**Problem**: Wenn Sie `AWS-RunPatchBaseline` ausführen, schlägt das Patchen mit dem folgenden Fehler fehl.
```
sh:
/var/lib/amazon/ssm/instanceid/document/orchestration/commandid/PatchLinux/_script.sh: Permission denied
failed to run commands: exit status 126
```
**Ursache**: `/var/lib/amazon/` könnte mit `noexec`-Berechtigungen gemountet sein. Dies ist ein Problem, weil SSM Agent Payload-Skripte auf `/var/lib/amazon/ssm` herunterlädt und sie von diesem Speicherort ausführt.
**Lösung**: Stellen Sie sicher, dass Sie exklusive Partitionen für `/var/log/amazon` und `/var/lib/amazon` konfiguriert haben und sind mit `exec`-Berechtigungen gemountet sind.
### Problem: Fehler 'Unable to download payload'
**Problem**: Wenn Sie `AWS-RunPatchBaseline` ausführen, schlägt das Patchen mit dem folgenden Fehler fehl.
```
Unable to download payload: https://s3.amzn-s3-demo-bucket.region.amazonaws.com/aws-ssm-region/patchbaselineoperations/linux/payloads/patch-baseline-operations-X.XX.tar.gz.failed to run commands: exit status 156
```
**Ursache**: Der verwaltete Knoten verfügt nicht über die erforderlichen Berechtigungen für den Zugriff auf den angegebenen Amazon Simple Storage Service (Amazon S3)-Bucket.
**Lösung**: Aktualisieren Sie Ihre Netzwerkkonfiguration so, dass S3-Endpunkte erreichbar sind. Weitere Informationen finden Sie unter den Informationen zum erforderlichen Zugriff auf S3-Buckets für Patch Manager in [SSM AgentKommunikation mit AWS verwalteten S3-Buckets](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions).
### Problem: Fehler 'unsupported package manager and python version combination'
**Problem**: Wenn Sie `AWS-RunPatchBaseline` ausführen, schlägt das Patchen mit dem folgenden Fehler fehl.
```
An unsupported package manager and python version combination was found. Apt requires Python3 to be installed.
failed to run commands: exit status 1
```
**Ursache**: Eine unterstützte Version von Python3 ist nicht auf der Instance Debian Server oder Ubuntu Server installiert.
**Lösung**: Installieren Sie eine unterstützte Version von python3 (3.0–3.12) auf dem Server, die für verwaltete Debian Server- und Ubuntu Server-Knoten erforderlich ist.
### Problem: Patch Manager wendet keine Regeln an, die zum Ausschließen bestimmter Pakete angegeben sind
**Problem**: Sie haben versucht, bestimmte Pakete auszuschließen, indem Sie sie in der `/etc/yum.conf`-Datei im Format `exclude=package-name` angeben, aber sie werden nicht während der Patch Manager-Operation `Install` ausgeschlossen.
**Ursache**: Patch Manager enthält keine Ausschlüsse, die in der `/etc/yum.conf`-Datei angegeben sind.
**Lösung**: Um bestimmte Pakete auszuschließen, erstellen Sie eine benutzerdefinierte Patch-Baseline und eine Regel, um die Pakete auszuschließen, die nicht installiert werden sollen.
### Problem: Patching schlägt fehl und Patch Manager meldet, dass die Erweiterung „Servername Indication“ für TLS nicht verfügbar ist
**Problem**: Der Patchvorgang gibt die folgende Meldung aus.
```
/var/log/amazon/ssm/patch-baseline-operations/urllib3/util/ssl_.py:369:
SNIMissingWarning: An HTTPS request has been made, but the SNI (Server Name Indication) extension
to TLS is not available on this platform. This might cause the server to present an incorrect TLS
certificate, which can cause validation failures. You can upgrade to a newer version of Python
to solve this.
For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
```
**Ursache**: Diese Meldung zeigt keinen Fehler an. Stattdessen ist dies eine Warnung, dass die ältere Version von Python, die mit dem Betriebssystem vertrieben wird, TLS Server Name Indication nicht unterstützt. Das Systems Manager Manager-Patch-Payload-Skript gibt diese Warnung aus, wenn eine Verbindung zu AWS APIs diesem unterstützenden SNI hergestellt wird.
**Lösung**: Um Patching-Fehler zu beheben, wenn diese Meldung gemeldet wird, überprüfen Sie den Inhalt der `stdout`- und `stderr`-Dateien. Wenn Sie die Patch-Baseline nicht so konfiguriert haben, dass diese Dateien in einem S3-Bucket oder in Amazon CloudWatch Logs gespeichert werden, können Sie die Dateien am folgenden Speicherort auf Ihrem verwalteten Linux-Node finden.
`/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`
### Problem: Patch Manager meldet 'No more mirrors to try'
**Problem**: Der Patchvorgang gibt die folgende Meldung aus.
```
[Errno 256] No more mirrors to try.
```
**Ursache**: Die auf dem verwalteten Knoten konfigurierten Repositorys funktionieren nicht richtig. Mögliche Gründe hierfür sind:
+ Das `yum`-Cache ist beschädigt.
+ Eine Repository-URL kann aufgrund von Netzwerkproblemen nicht erreicht werden.
**Lösung**: Patch Manager verwendet den Standard-Paketmanager des verwalteten Knoten, um die Patching-Operation durchzuführen. Überprüfen Sie, ob Repositorys richtig konfiguriert sind und funktionieren.
### Problem: Patching schlägt fehl mit 'Error code returned from curl is 23'
**Problem**: Eine Patching-Operation, die `AWS-RunPatchBaseline` verwendet, schlägt mit einer Fehlermeldung ähnlich der folgenden fehl:
```
05/01/2025 17:04:30 root [ERROR]: Error code returned from curl is 23
```
**Ursache**: Das auf Ihren Systemen verwendete Curl-Tool verfügt nicht über die erforderlichen Rechte, um in das Dateisystem zu schreiben. Dies kann vorkommen, wenn das Standard-Curl-Tool des Paketmanagers durch eine andere Version ersetzt wurde, beispielsweise durch eine, die mit snap installiert wurde.
**Lösung**: Wenn die vom Paketmanager bereitgestellte curl-Version deinstalliert wurde, während eine andere Version installiert wurde, installieren Sie sie erneut.
Wenn Sie mehrere curl-Versionen installiert halten müssen, stellen Sie sicher, dass sich die mit dem Paketmanager verknüpfte Version im ersten in der `PATH`-Variable aufgeführten Verzeichnis befindet. Sie können dies überprüfen, indem Sie den Befehl `echo $PATH` ausführen, um die aktuelle Reihenfolge der Verzeichnisse zu sehen, die auf Ihrem System auf ausführbare Dateien überprüft werden.
### Problem: Patching schlägt mit der Meldung 'Error unpacking rpm package...' fehl
**Problem**: Ein Patch-Vorgang schlägt mit einem Fehler ähnlich dem folgenden fehl:
```
Error : Error unpacking rpm package python-urllib3-1.25.9-1.amzn2.0.2.noarch
python-urllib3-1.25.9-1.amzn2.0.1.noarch was supposed to be removed but is not!
failed to run commands: exit status 1
```
**Ursache 1**: Wenn ein bestimmtes Paket in mehreren Paket-Installationsprogrammen vorhanden ist, z. B. sowohl in `pip` als auch in `yum` oder `dnf`, kann es bei der Verwendung des Standard-Paketmanagers zu Konflikten kommen.
Ein häufiges Beispiel ist das `urllib3`-Paket, das sich in `pip`, `yum` und `dnf` befindet.
**Ursache 2**: Das `python-urllib3`-Paket ist beschädigt. Dies kann passieren, wenn die Paketdateien von `pip` installiert oder aktualisiert wurden, nachdem das `rpm`-Paket zuvor von `yum` oder `dnf` installiert wurde.
**Lösung**: Entfernen Sie das `python-urllib3`-Paket aus Pip, indem Sie den Befehl `sudo pip uninstall urllib3` ausführen, und behalten Sie das Paket nur im Standard-Paketmanager (`yum` oder `dnf`) bei.
### Problem: Patching schlägt fehl mit 'Fehler auf Serviceseite beim Hochladen des Inventars'
**Problem**: Beim Ausführen des `AWS-RunPatchBaseline`-Dokuments erhalten Sie die folgende Fehlermeldung:
```
Encounter service side error when uploading the inventory
```
**Ursache**: Zwei Befehle zum Ausführen von `AWS-RunPatchBaseline` wurden gleichzeitig auf demselben verwalteten Knoten ausgeführt. Dies führt zu einer Race-Bedingung, wenn der Boto3-Client während Patch-Vorgängen initialisiert wird.
**Lösung**: Stellen Sie sicher, dass keine State Manager-Zuordnung, Aufgaben im Wartungsfenster oder andere Konfigurationen, die `AWS-RunPatchBaseline`nach einem Zeitplan ausführen, ungefähr zur gleichen Zeit denselben verwalteten Knoten als Ziel haben.
### Problem: Das Patchen schlägt fehl und die Meldung „Beim Herunterladen von Paketen sind Fehler aufgetreten“ wird angezeigt
**Problem**: Beim Patchen erhalten Sie eine Fehlermeldung, die der folgenden ähnelt:
```
YumDownloadError: [u'Errors were encountered while downloading
packages.', u'libxml2-2.9.1-6.el7_9.6.x86_64: [Errno 5] [Errno 12]
Cannot allocate memory', u'libxslt-1.1.28-6.el7.x86_64: [Errno 5]
[Errno 12] Cannot allocate memory', u'libcroco-0.6.12-6.el7_9.x86_64:
[Errno 5] [Errno 12] Cannot allocate memory', u'openldap-2.4.44-25.el7_9.x86_64:
[Errno 5] [Errno 12] Cannot allocate memory',
```
**Ursache**: Dieser Fehler kann auftreten, wenn auf einem verwalteten Knoten nicht genügend Speicher verfügbar ist.
**Lösung**: Konfigurieren Sie den Swap-Speicher oder aktualisieren Sie die Instance auf einen anderen Typ, um die Speicherunterstützung zu erhöhen. Starten Sie dann einen neuen Patch-Vorgang.
### Problem: Das Patchen schlägt mit einem OOM-Fehler (Out of Memory) fehl
**Problem**: Bei der Ausführung schlägt der Patchvorgang fehl`AWS-RunPatchBaseline`, da auf dem verwalteten Knoten nicht genügend Arbeitsspeicher zur Verfügung steht. Möglicherweise werden Fehler wie `Cannot allocate memory` `Killed` (vom Linux-OOM-Killer) angezeigt, oder der Vorgang schlägt unerwartet fehl. Dieser Fehler tritt eher bei Instanzen mit weniger als 1 GB RAM auf, kann sich aber auch auf Instanzen mit mehr Arbeitsspeicher auswirken, wenn eine große Anzahl von Updates verfügbar ist.
**Ursache**: Patch Manager führt Patchvorgänge mithilfe des systemeigenen Paketmanagers auf dem verwalteten Knoten aus. Der während eines Patchvorgangs benötigte Speicher hängt von mehreren Faktoren ab, darunter:
+ Die Anzahl der installierten Pakete und die verfügbaren Updates auf dem verwalteten Knoten.
+ Der verwendete Paketmanager und seine Speichereigenschaften.
+ Andere Prozesse, die zum Zeitpunkt des Patchvorgangs auf dem verwalteten Knoten ausgeführt werden.
Verwaltete Knoten mit einer großen Anzahl installierter Pakete oder einer großen Anzahl verfügbarer Updates benötigen während der Patchvorgänge mehr Arbeitsspeicher. Wenn der verfügbare Speicher nicht ausreicht, schlägt der Patchvorgang fehl und wird mit einem Fehler beendet. Das Betriebssystem kann den Patchvorgang auch beenden.
**Lösung**: Probieren Sie eine oder mehrere der folgenden Optionen aus:
+ Planen Sie Patch-Vorgänge in Zeiten geringer Arbeitsauslastung auf dem verwalteten Knoten, z. B. mithilfe von Wartungsfenstern.
+ Führen Sie ein Upgrade der Instanz auf einen Typ mit mehr Arbeitsspeicher durch.
+ Konfigurieren Sie den Swap-Speicher auf dem verwalteten Knoten. Beachten Sie, dass bei Instances mit begrenztem EBS-Durchsatz eine starke Swap-Nutzung zu Leistungseinbußen führen kann.
+ Überprüfen und reduzieren Sie die Anzahl der Prozesse, die während der Patching-Vorgänge auf dem verwalteten Knoten ausgeführt werden.
### Problem: Patching schlägt fehl mit der Meldung 'Die folgenden Signaturen konnten nicht verifiziert werden, da der öffentliche Schlüssel nicht verfügbar ist'
**Problem**: Das Patchen schlägt bei Ubuntu Server mit einer Fehlermeldung ähnlich der folgenden fehl:
```
02/17/2022 21:08:43 root [ERROR]: W:GPG error:
http://repo.mysql.com/apt/ubuntu bionic InRelease: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 467B942D3A79BD29, E:The repository ' http://repo.mysql.com/apt/ubuntu bionic
```
**Ursache**: Der Schlüssel für GNU Privacy Guard (GPG) ist abgelaufen oder fehlt.
**Lösung**: Aktualisieren Sie den GPG-Schlüssel, oder fügen Sie den Schlüssel erneut hinzu.
Anhand des zuvor gezeigten Fehlers sehen wir zum Beispiel, dass der `467B942D3A79BD29`-Schlüssel fehlt und hinzugefügt werden muss. Führen Sie dazu einen der folgenden Befehle aus:
```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --recv-keys 467B942D3A79BD29
```
```
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 467B942D3A79BD29
```
Oder, um alle Schlüssel zu aktualisieren, führen Sie den folgenden Befehl aus:
```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --refresh-keys
```
Wenn der Fehler danach weiterhin auftritt, empfehlen wir, das Problem an die Organisation zu melden, die das Repository verwaltet. Bis ein Fix verfügbar ist, können Sie die `/etc/apt/sources.list`-Datei so bearbeiten, dass das Repository während des Patchvorgangs ausgelassen wird.
Öffnen Sie dazu die `sources.list`-Datei zur Bearbeitung, suchen Sie die Zeile für das Repository und fügen Sie am Anfang der Zeile ein `#`-Zeichen ein, um sie auszukommentieren. Speichern und schließen Sie dann die Datei.
### Problem: Das Patchen schlägt fehl und die Meldung '' NoMoreMirrorsRepoError wird angezeigt
**Problem:** Sie erhalten eine Fehlermeldung ähnlich der folgenden:
```
NoMoreMirrorsRepoError: failure: repodata/repomd.xml from pgdg94: [Errno 256] No more mirrors to try.
```
**Ursache**: Im Quell-Repository ist ein Fehler aufgetreten.
**Lösung**: Wir empfehlen, das Problem der Organisation zu melden, die das Repository verwaltet. Bis der Fehler behoben ist, können Sie das Repository auf Betriebssystemebene deaktivieren. Führen Sie dazu den folgenden Befehl aus und ersetzen Sie den Wert für *repo-name* durch Ihren Repository-Namen:
```
yum-config-manager --disable repo-name
```
Im Folgenden sehen Sie ein Beispiel.
```
yum-config-manager --disable pgdg94
```
Nachdem Sie diesen Befehl ausgeführt haben, führen Sie einen weiteren Patch-Vorgang aus.
### Problem: Das Patchen schlägt mit der Meldung „Payload kann nicht heruntergeladen werden“ fehl
**Problem:** Sie erhalten eine Fehlermeldung ähnlich der folgenden:
```
Unable to download payload:
https://s3.dualstack.eu-west-1.amazonaws.com/aws-ssm-eu-west-1/patchbaselineoperations/linux/payloads/patch-baseline-operations-1.83.tar.gz.
failed to run commands: exit status 156
```
**Ursache**: Die Konfiguration des verwalteten Knotens ist fehlerhaft oder unvollständig.
**Lösung**: Versichern Sie sich, dass der verwaltete Knoten wie folgt konfiguriert ist:
+ Ausgehende TCP-443-Regel in der Sicherheitsgruppe.
+ Ausgehende TCP-443-Regel in NACL.
+ TCP-Regel 1024-65535 für eingehenden Datenverkehr in NACL.
+ NAT/IGW in der Routing-Tabelle, um Konnektivität zu einem S3-Endpunkt bereitzustellen. Wenn die Instance keinen Internetzugang hat, stellen Sie ihr Konnektivität mit dem S3-Endpunkt zur Verfügung. Fügen Sie dazu einen S3-Gateway-Endpunkt in der VPC hinzu und integrieren Sie ihn in die Routing-Tabelle des verwalteten Knotens.
### Problem: Das Patchen schlägt fehl und es wird die Meldung „Installationsfehler: dpkg: Fehler:dpkg-Frontend ist durch einen anderen Prozess gesperrt“ angezeigt
**Problem**: Das Patchen schlägt mit einem Fehler ähnlich dem folgenden fehl:
```
install errors: dpkg: error: dpkg frontend is locked by another process
failed to run commands: exit status 2
Failed to install package; install status Failed
```
**Ursache**: Der Paketmanager führt bereits einen anderen Prozess auf einem verwalteten Knoten auf Betriebssystemebene aus. Wenn der Abschluss dieses anderen Prozesses viel Zeit in Anspruch nimmt, kann es bei der Patch-Operation von Patch Manager zu einem Timeout kommen und ein Fehler auftreten.
**Lösung**: Führen Sie nach Abschluss des anderen Prozesses, der den Paketmanager verwendet, einen neuen Patchvorgang aus.
### Problem: Das Patchen auf Ubuntu Server schlägt fehl und es wird der Fehler „dpkg wurde unterbrochen“ angezeigt
**Problem**: Auf Ubuntu Server schlägt das Patchen mit einem Fehler ähnlich dem folgenden fehl:
```
E: dpkg was interrupted, you must manually run
'dpkg --configure -a' to correct the problem.
```
**Ursache**: Ein oder mehrere Pakete sind falsch konfiguriert.
**Lösung**: Führen Sie die folgenden Schritte aus:
1. Prüfen Sie, welche Pakete betroffen sind und welche Probleme bei den einzelnen Paketen bestehen, indem Sie nacheinander die folgenden Befehle ausführen:
```
sudo apt-get check
```
```
sudo dpkg -C
```
```
dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' | grep -E ^.[^nci]
```
1. Korrigieren Sie die fehlerhaften Pakete, indem Sie den folgenden Befehl ausführen:
```
sudo dpkg --configure -a
```
1. Wenn der vorherige Befehl das Problem nicht vollständig behoben hat, führen Sie den folgenden Befehl aus:
```
sudo apt --fix-broken install
```
### Problem: Das Paketmanager-Dienstprogramm kann eine Paketabhängigkeit nicht auflösen
**Problem**: Der native Paketmanager auf dem verwalteten Knoten kann eine Paketabhängigkeit nicht auflösen und das Patchen schlägt fehl. Das folgende Beispiel für eine Fehlermeldung weist auf diese Art von Fehler auf einem Betriebssystem hin, das `yum` als Paketmanager verwendet.
```
09/22/2020 08:56:09 root [ERROR]: yum update failed with result code: 1,
message: [u'rpm-python-4.11.3-25.amzn2.0.3.x86_64 requires rpm = 4.11.3-25.amzn2.0.3',
u'awscli-1.18.107-1.amzn2.0.1.noarch requires python2-botocore = 1.17.31']
```
**Ursache**: Patch Manager verwendet auf Linux-Betriebssystemen den systemeigenen Paketmanager auf der Maschine, um Patch-Operationen wie `yum`, `dnf`, `apt` und `zypper` auszuführen. Die Anwendungen erkennen, installieren, aktualisieren oder entfernen abhängige Pakete bei Bedarf automatisch. Einige Bedingungen können jedoch dazu führen, dass der Paketmanager einen Abhängigkeitsvorgang nicht abschließen kann, wie zum Beispiel:
+ Auf dem Betriebssystem sind mehrere widersprüchliche Repositorys konfiguriert.
+ Auf eine Remote-Repository-URL kann aufgrund von Netzwerkproblemen nicht zugegriffen werden.
+ Im Repository wurde ein Paket für die falsche Architektur gefunden.
**Lösung**: Das Patchen kann aufgrund eines Abhängigkeitsproblems aus einer Vielzahl von Gründen fehlschlagen. Wir empfehlen Ihnen daher, sich an uns AWS Support zu wenden, um Ihnen bei der Problembehebung behilflich zu sein.
### Problem: Fehler bei der Abhängigkeit von Zypper-Paketsperren auf verwalteten SLES-Knoten
**Problem**: Wenn Sie `AWS-RunPatchBaseline` mit dem `Install`-Vorgang auf SUSE Linux Enterprise Server-Instances ausführen, schlägt das Patchen fehl und es treten Fehler bei der Abhängigkeitsprüfung auf, die mit Paketsperren zusammenhängen. Sie könnten Fehlermeldungen ähnlich der folgenden erhalten:
```
Problem: mock-pkg-has-dependencies-0.2.0-21.adistro.noarch requires mock-pkg-standalone = 0.2.0, but this requirement cannot be provided
uninstallable providers: mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
Solution 1: remove lock to allow installation of mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
Solution 2: do not install mock-pkg-has-dependencies-0.2.0-21.adistro.noarch
Solution 3: break mock-pkg-has-dependencies-0.2.0-21.adistro.noarch by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/c] (c): c
```
In diesem Beispiel ist das Paket `mock-pkg-standalone` gesperrt, was Sie überprüfen könnten, indem Sie `sudo zypper locks` ausführen und in der Ausgabe nach diesem Paketnamen suchen.
Oder Sie sehen möglicherweise Protokolleinträge, die auf Fehlschläge bei der Abhängigkeitsprüfung hinweisen:
```
Encountered a known exception in the CLI Invoker: CLIInvokerError(error_message='Dependency check failure during commit process', error_code='4')
```
**Anmerkung**
Dieses Problem tritt nur während `Install`-Vorgängen auf. `Scan`-Vorgänge wenden keine Paketsperren an und sind auch nicht von vorhandenen Sperren betroffen.“
**Ursache**: Dieser Fehler tritt auf, wenn Zypper-Paketsperren die Installation oder Aktualisierung von Paketen aufgrund von Abhängigkeitskonflikten verhindern. Paketsperren können aus verschiedenen Gründen vorhanden sein:
+ **Vom Kunden angewendete Sperren**: Sie oder Ihr Systemadministrator haben Pakete manuell mithilfe von Zypper-Befehlen gesperrt, wie z. B. `zypper addlock`.
+ **Von Patch Manager abgelehnte Patches**: Patch Manager wendet automatisch Paketsperren an, wenn Sie Pakete in der Liste der **abgelehnten Patches** Ihrer Patch-Baseline angeben, um deren Installation zu verhindern.
+ **Restsperren aufgrund unterbrochener Vorgänge**: In seltenen Fällen, in denen ein Patch-Vorgang unterbrochen wurde (z. B. durch einen Systemneustart), konnte zuvor Patch Manager temporäre Sperren aufheben, restliche Paketsperren verblieben jedoch eventuell auf Ihrem verwalteten Knoten.
**Lösung**: Gehen Sie je nach Ursache folgendermaßen vor, um Probleme mit der Zypper-Paketsperre zu beheben:
**Schritt 1: Identifizieren gesperrter Pakete**
Verbinden Sie sich mit Ihrem verwalteten SLES-Knoten und führen Sie den folgenden Befehl aus, um alle derzeit gesperrten Pakete aufzulisten:
```
sudo zypper locks
```
**Schritt 2: Ermitteln der Quelle der Sperren**
+ Wenn es sich bei den gesperrten Paketen um Pakete handelt, die Sie aus Gründen der Systemstabilität absichtlich gesperrt haben, sollten Sie überlegen, ob sie gesperrt bleiben müssen oder ob sie für das Patching vorübergehend entsperrt werden können.
+ Wenn die gesperrten Pakete mit Einträgen in der Liste der **abgelehnten Patches** Ihrer Patch-Baseline übereinstimmen, handelt es sich wahrscheinlich um Restsperren, die auf einen unterbrochenen Patch-Vorgang zurückzuführen sind. Patch Manager wendet diese Sperren während des normalen Betriebs vorübergehend an und entfernt sie automatisch, wenn der Vorgang abgeschlossen ist. Sie können die Pakete entweder aus der Liste der abgelehnten Pakete entfernen oder Ihre Patch-Baseline-Regeln ändern.
+ Wenn Sie die gesperrten Pakete nicht erkennen und sie nicht absichtlich gesperrt wurden, handelt es sich möglicherweise um Restsperren aus einem zuvor unterbrochenen Patch-Vorgang.
**Schritt 3: Entfernen von Sperren nach Notwendigkeit**
Mit diesem Befehl können Sie bestimmte Paketsperren entfernen:
```
sudo zypper removelock package-name
```
Um alle Paketsperren zu entfernen (mit Vorsicht verwenden), führen Sie folgenden Befehl aus:
```
sudo zypper cleanlocks
```
**Schritt 4: Aktualisieren Ihrer Patch-Baseline (falls zutreffend)**
Wenn die Sperren durch abgelehnte Patches in Ihrer Patch-Baseline verursacht wurden:
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Patch Manager** aus.
1. Wählen Sie die Registerkarte **Patch-Baselines** und dann Ihre benutzerdefinierte Patch-Baseline aus.
1. Wählen Sie **Aktionen**, **Patch-Baseline ändern** aus.
1. Überprüfen Sie im Abschnitt **Abgelehnte Patches** die aufgelisteten Pakete und entfernen Sie alle Pakete, deren Installation zulässig sein sollte.
1. Wählen Sie **Änderungen speichern ** aus.
**Schritt 5: Wiederholen des Patch-Vorgangs**
Nachdem Sie die problematischen Sperren entfernt und gegebenenfalls Ihre Patch-Baseline aktualisiert haben, führen Sie das `AWS-RunPatchBaseline`-Dokument erneut aus.
**Anmerkung**
Wenn während der `Install`-Vorgänge Patch Manager Sperren für abgelehnte Patches anwendet, ist es so konzipiert, dass diese Sperren nach Abschluss des Patch-Vorgangs automatisch aufgehoben werden. Wenn Sie diese Sperren bei der Ausführung von `sudo zypper locks` sehen, bedeutet das, dass ein früherer Patch-Vorgang unterbrochen wurde, bevor die Aufhebung durchgeführt werden konnte. Wenn ein Patch-Vorgang jedoch unterbrochen wird, ist möglicherweise eine manuelle Aufhebung erforderlich, wie in diesem Verfahren beschrieben.
**Prävention**: Vermeiden Sie zukünftige Zypper-Sperrkonflikte wie folgt:
+ Prüfen Sie die Liste der abgelehnten Patches Ihrer Patch-Baseline sorgfältig, um sicherzustellen, dass sie nur Pakete enthält, die Sie wirklich ausschließen möchten.
+ Vermeiden Sie es, Pakete, die möglicherweise als Abhängigkeiten für Sicherheitsupdates benötigt werden, manuell zu sperren.
+ Wenn Sie Pakete manuell sperren müssen, dokumentieren Sie die Gründe dafür und überprüfen Sie die Sperren regelmäßig.
+ Stellen Sie sicher, dass die Patch-Vorgänge erfolgreich abgeschlossen werden und nicht durch Systemneustarts oder andere Faktoren unterbrochen werden.
+ Überwachen Sie Patch-Vorgänge bis zum Abschluss und vermeiden Sie es, sie durch Systemneustarts oder andere Aktionen zu unterbrechen, die das ordnungsgemäße Löschen temporärer Sperren verhindern könnten.
### Problem: Die Sperre kann nicht abgerufen werden. Ein weiterer Patch-Vorgang ist im Gange.
**Problem**: Beim Ausführen `AWS-RunPatchBaseline` schlägt das Patchen mit Fehlercode 4 und der folgenden Fehlermeldung fehl.
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**Ursache**: Dieser Fehler tritt auf, wenn mehrere Patch-Operationen versuchen, auf demselben verwalteten Knoten gleichzeitig auszuführen. Die Sperrdatei verhindert gleichzeitige Patch-Vorgänge, um Konflikte zu vermeiden und die Systemstabilität zu gewährleisten.
**Lösung**: Stellen Sie sicher, dass Patchvorgänge nicht so geplant sind, dass sie gleichzeitig auf demselben verwalteten Knoten ausgeführt werden. Überprüfen Sie die folgenden Konfigurationen, um Planungskonflikte zu identifizieren und zu lösen:
+ **Patch-Richtlinien**: Überprüfen Sie Ihre Quick Setup-Patchrichtlinien-Konfigurationen, um sicherzustellen, dass sie sich nicht mit anderen Patch-Zeitplänen überschneiden.
+ **Wartungsfenster**: Überprüfen Sie die Zuordnungen Ihrer Wartungsfenster, um sicherzustellen, dass nicht mehrere Fenster auf dieselben verwalteten Knoten abzielen, wobei sich die Patch-Aufgaben zu überschneidenden Zeiten befinden.
+ **Manuelle Patch-Now-Operationen**: Vermeiden Sie es, manuelle **Patch-Now-Operationen** zu initiieren, während das geplante Patchen ausgeführt wird.
## Fehler beim Ausführen von `AWS-RunPatchBaseline` unter Windows Server
**Topics**
+ [Problem: Nicht übereinstimmende Produktpaare family/product](#patch-manager-troubleshooting-product-family-mismatch)
+ [Problem: `AWS-RunPatchBaseline`-Ausgabe gibt einen `HRESULT` (Windows Server) zurück](#patch-manager-troubleshooting-hresult)
+ [Problem: Der verwaltete Knoten hat keinen Zugriff auf Windows Update Catalog oder WSUS](#patch-manager-troubleshooting-instance-access)
+ [Problem: PatchBaselineOperations PowerShell Das Modul kann nicht heruntergeladen werden](#patch-manager-troubleshooting-module-not-downloadable)
+ [Problem: fehlende Patches](#patch-manager-troubleshooting-missing-patches)
+ [Problem: Die Sperre kann nicht erworben werden. Ein weiterer Patch-Vorgang ist im Gange.](#patch-manager-troubleshooting-windows-concurrent-lock)
### Problem: Nicht übereinstimmende Produktpaare family/product
**Problem**: Wenn Sie eine Patch-Baseline in der Systems Manager-Konsole erstellen, geben Sie eine Produktfamilie und ein Produkt an. Beispiel:
+ **Product Family (Produktfamilie)**: `Office`
**Produkt**: `Office 2016`
**Ursache**: Wenn Sie versuchen, eine Patch-Baseline mit einem nicht übereinstimmenden family/product Produktpaar zu erstellen, wird eine Fehlermeldung angezeigt. Dies kann folgende Ursachen haben:
+ Sie haben eine gültige Kombination aus Produktfamilie und Produktpaar ausgewählt, dann jedoch die Auswahl der Produktfamilie entfernt.
+ Sie haben ein Produkt aus der Unterliste **Obsolete or mismatched options (Veraltete oder nicht übereinstimmende Optionen)** statt aus der Unterliste **Available and matching options (Verfügbare und übereinstimmende Optionen)** ausgewählt.
Artikel in der Produktunterliste **Veraltete oder nicht übereinstimmende Optionen** wurden möglicherweise fälschlicherweise über ein SDK oder AWS Command Line Interface den Befehl () eingegeben.AWS CLI`create-patch-baseline` Dadurch kann es zu einem Schreibfehler oder einer falschen Zuordnung eines Produkts zu einer Produktfamilie kommen. Ein Produkt kann auch in der Unterliste **Obsolete or mismatched options (Veraltete oder nicht übereinstimmende Optionen)** enthalten sein, wenn es für eine vorherige Patch-Baseline angegeben wurde, aber keine Patches für das Produkt von Microsoft verfügbar sind.
**Lösung**: Um dieses Problem in der Konsole zu vermeiden, wählen Sie immer Optionen aus den Unterlisten **Currently available options (Derzeit verfügbare Optionen)** aus.
Um diejenigen Produkte anzuzeigen, für die Patches verfügbar sind, können Sie auch den Befehl `[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)` in der AWS CLI oder den API-Befehl `[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)` verwenden.
### Problem: `AWS-RunPatchBaseline`-Ausgabe gibt einen `HRESULT` (Windows Server) zurück
**Problem:** Sie haben eine Fehlermeldung wie die folgende erhalten.
```
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when
attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80240437
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)..
(Windows updates)
11/22/2020 09:17:30 UTC | Info | Searching for Windows Updates.
11/22/2020 09:18:59 UTC | Error | Searching for updates resulted in error: Exception from HRESULT: 0x80240437
----------ERROR-------
failed to run commands: exit status 4294967295
```
**Ursache**: Diese Ausgabe weist darauf hin, dass das systemeigene Windows Update die Patchvorgänge nicht ausführen APIs konnte.
**Lösung**: Überprüfen Sie den `HResult`-Code in den folgenden Themen auf microsoft.com, um Schritte zur Fehlerbehebung zum Beheben des Fehlers zu ermitteln:
+ [Windows-Update-Fehlercodes nach Komponenten](https://learn.microsoft.com/en-us/windows/deployment/update/windows-update-error-reference)
+ [Häufige Fehler und Abhilfemaßnahmen für Windows Update](https://learn.microsoft.com/en-us/troubleshoot/windows-client/deployment/common-windows-update-errors)
### Problem: Der verwaltete Knoten hat keinen Zugriff auf Windows Update Catalog oder WSUS
**Problem:** Sie haben eine Fehlermeldung wie die folgende erhalten.
```
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
Extracting PatchBaselineOperations zip file contents to temporary folder.
Verifying SHA 256 of the PatchBaselineOperations PowerShell module files.
Successfully downloaded and installed the PatchBaselineOperations PowerShell module.
Patch Summary for
PatchGroup :
BaselineId :
Baseline : null
SnapshotId :
RebootOption : RebootIfNeeded
OwnerInformation :
OperationType : Scan
OperationStartTime : 1970-01-01T00:00:00.0000000Z
OperationEndTime : 1970-01-01T00:00:00.0000000Z
InstalledCount : -1
InstalledRejectedCount : -1
InstalledPendingRebootCount : -1
InstalledOtherCount : -1
FailedCount : -1
MissingCount : -1
NotApplicableCount : -1
UnreportedNotApplicableCount : -1
EC2AMAZ-VL3099P - PatchBaselineOperations Assessment Results - 2020-12-30T20:59:46.169
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80072EE2
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)
at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String
searchCriteria)
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\3d2d4864-04b7-4316-84fe-eafff1ea58
e3\PatchWindows\_script.ps1:230 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOperation:InstallWindowsUpdateOperation) [Inv
oke-PatchBaselineOperation], Exception
+ FullyQualifiedErrorId : Exception Level 1:
Error Message: Exception Details: An error occurred when attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80072EE2
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)
at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String searc
---Error truncated----
```
**Ursache**: Dieser Fehler kann mit den Windows Update-Komponenten oder einer fehlenden Konnektivität zum Windows Update Catalog oder Windows Server Update Services (WSUS) zusammenhängen.
**Lösung**: Bestätigen Sie, dass der verwaltete Knoten über ein Internet-Gateway, ein NAT-Gateway oder eine NAT-Instance eine Verbindung zum [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/home.aspx) hergestellt hat. Wenn Sie WSUS verwenden, bestätigen Sie, dass der verwaltete Knoten eine Verbindung zum WSUS-Server in Ihrer Umgebung hat. Wenn Konnektivität für das beabsichtigte Ziel verfügbar ist, überprüfen Sie die Microsoft-Dokumentation auf andere mögliche Ursachen für `HResult 0x80072EE2`. Dies kann auf ein Problem auf Betriebssystemebene hinweisen.
### Problem: PatchBaselineOperations PowerShell Das Modul kann nicht heruntergeladen werden
**Problem:** Sie haben eine Fehlermeldung wie die folgende erhalten.
```
Preparing to download PatchBaselineOperations PowerShell module from S3.
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
----------ERROR-------
C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\aaaaaaaa-bbbb-cccc-dddd-4f6ed6bd5514\
PatchWindows\_script.ps1 : An error occurred when executing PatchBaselineOperations: Unable to connect to the remote server
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,_script.ps1
failed to run commands: exit status 4294967295
```
**Lösung**: Überprüfen Sie die Konnektivität und Berechtigungen für Amazon Simple Storage Service (Amazon S3) des verwalteten Knoten. Für die Rolle des verwalteten Knotens AWS Identity and Access Management (IAM) müssen die unter angegebenen Mindestberechtigungen verwendet werden. [SSM AgentKommunikation mit AWS verwalteten S3-Buckets](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) Der Knoten muss über den Amazon-S3-Gateway-Endpunkt, das NAT-Gateway oder das Internet-Gateway mit dem Amazon-S3-Endpunkt kommunizieren. Weitere Informationen zu den VPC-Endpunktanforderungen für AWS Systems Manager SSM Agent (SSM Agent) finden Sie unter[Die Sicherheit von EC2-Instances mithilfe von VPC-Endpunkten für Systems Manager verbessern](setup-create-vpc.md).
### Problem: fehlende Patches
**Problem**: `AWS-RunPatchbaseline` wurde erfolgreich abgeschlossen, aber es fehlen einige Patches.
Nachfolgend finden Sie einige häufige Auslöser und deren Lösungen.
**Ursache 1**: Die Baseline ist nicht effektiv.
**Lösung 1**: Führen Sie die folgenden Schritte aus, um zu überprüfen, ob dies die Ursache ist.
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Run Command** aus.
1. Wählen Sie die Registerkarte **Befehlsverlauf** und dann den Befehl aus, dessen Baseline Sie überprüfen möchten.
1. Wählen Sie den verwalteten Knoten aus, dem Patches fehlen.
1. Wählen Sie **Schritt 1 – Ausgabe** aus und finden Sie den `BaselineId`-Wert.
1. Aktivieren Sie die zugewiesene [Patch-Baseline-Konfiguration](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom), d. h. Betriebssystem, Produktname, Klassifizierung und Schweregrad für die Patch-Baseline.
1. Rufen Sie den [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/home.aspx) auf.
1. Suchen Sie im Artikel der Microsoft Knowledge Base IDs (KB) (z. B. KB3216916).
1. Stellen Sie sicher, dass der Wert unter **Product** (Produkt) dem Ihres verwalteten Knotens entspricht, und wählen Sie den entsprechenden **Title** (Titel) aus. Ein neues Fenser **Details aktualisieren** wird geöffnet.
1. In der Registerkarte **Übersicht** müssen **Klassifizierung** und **Schweregrad des MSRC** der Patch-Baseline-Konfiguration entsprechen, die Sie zuvor gefunden haben.
**Ursache 2**: Das Patch wurde ersetzt.
**Lösung 2**: Führen Sie die folgenden Schritte aus, um zu überprüfen, ob dies der Fall ist.
1. Rufen Sie den [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/home.aspx) auf.
1. Suchen Sie im Artikel der Microsoft Knowledge Base IDs (KB) (z. B. KB3216916).
1. Stellen Sie sicher, dass der Wert unter **Product** (Produkt) dem Ihres verwalteten Knotens entspricht, und wählen Sie den entsprechenden **Title** (Titel) aus. Ein neues Fenser **Details aktualisieren** wird geöffnet.
1. Gehen Sie zur Registerkarte **Paketdetails**. Suchen Sie nach einem Eintrag unter dem Header **Dieses Update wurde durch die folgenden Updates ersetzt:**.
**Ursache 3**: Dasselbe Patch hat möglicherweise unterschiedliche KB-Nummern, da die WSUS- und Windows-Online-Updates von Microsoft als unabhängige Versionskanäle behandelt werden.
**Lösung 3**: Überprüfen Sie die Berechtigung des Patches. Wenn das Paket unter WSUS nicht verfügbar ist, installieren Sie [OS Build 14393.3115](https://support.microsoft.com/en-us/topic/july-16-2019-kb4507459-os-build-14393-3115-511a3df6-c07e-14e3-dc95-b9898a7a7a57). Wenn das Paket für alle Betriebssystem-Builds verfügbar ist, installieren Sie [OS-Builds 18362.1256 und 18363.1256](https://support.microsoft.com/en-us/topic/december-8-2020-kb4592449-os-builds-18362-1256-and-18363-1256-c448f3df-a5f1-1d55-aa31-0e1cf7a440a9).
### Problem: Die Sperre kann nicht erworben werden. Ein weiterer Patch-Vorgang ist im Gange.
**Problem**: Beim Ausführen `AWS-RunPatchBaseline` schlägt das Patchen mit Fehlercode 4 und der folgenden Fehlermeldung fehl.
```
Cannot acquire lock on C:\ProgramData\Amazon\SSM\patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**Ursache**: Dieser Fehler tritt auf, wenn mehrere Patch-Operationen versuchen, auf demselben verwalteten Knoten gleichzeitig auszuführen. Die Sperrdatei verhindert gleichzeitige Patch-Vorgänge, um Konflikte zu vermeiden und die Systemstabilität zu gewährleisten.
**Lösung**: Stellen Sie sicher, dass Patchvorgänge nicht so geplant sind, dass sie gleichzeitig auf demselben verwalteten Knoten ausgeführt werden. Überprüfen Sie die folgenden Konfigurationen, um Planungskonflikte zu identifizieren und zu lösen:
+ **Patch-Richtlinien**: Überprüfen Sie Ihre Quick Setup-Patchrichtlinien-Konfigurationen, um sicherzustellen, dass sie sich nicht mit anderen Patch-Zeitplänen überschneiden.
+ **Wartungsfenster**: Überprüfen Sie die Zuordnungen Ihrer Wartungsfenster, um sicherzustellen, dass nicht mehrere Fenster auf dieselben verwalteten Knoten abzielen, wobei sich die Patch-Aufgaben zu überschneidenden Zeiten befinden.
+ **Manuelle Patch-Now-Operationen**: Vermeiden Sie es, manuelle **Patch-Now-Operationen** zu initiieren, während das geplante Patchen ausgeführt wird.
## Fehler bei der Ausführung `AWS-RunPatchBaseline` auf macOS
**Topics**
+ [Problem: Die Sperre kann nicht abgerufen werden. Ein weiterer Patch-Vorgang ist im Gange.](#patch-manager-troubleshooting-macos-concurrent-lock)
### Problem: Die Sperre kann nicht abgerufen werden. Ein weiterer Patch-Vorgang ist im Gange.
**Problem**: Beim Ausführen `AWS-RunPatchBaseline` schlägt das Patchen mit Fehlercode 4 und der folgenden Fehlermeldung fehl.
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**Ursache**: Dieser Fehler tritt auf, wenn mehrere Patch-Operationen versuchen, auf demselben verwalteten Knoten gleichzeitig auszuführen. Die Sperrdatei verhindert gleichzeitige Patch-Vorgänge, um Konflikte zu vermeiden und die Systemstabilität zu gewährleisten.
**Lösung**: Stellen Sie sicher, dass Patchvorgänge nicht so geplant sind, dass sie gleichzeitig auf demselben verwalteten Knoten ausgeführt werden. Überprüfen Sie die folgenden Konfigurationen, um Planungskonflikte zu identifizieren und zu lösen:
+ **Patch-Richtlinien**: Überprüfen Sie Ihre Quick Setup-Patchrichtlinien-Konfigurationen, um sicherzustellen, dass sie sich nicht mit anderen Patch-Zeitplänen überschneiden.
+ **Wartungsfenster**: Überprüfen Sie die Zuordnungen Ihrer Wartungsfenster, um sicherzustellen, dass nicht mehrere Fenster auf dieselben verwalteten Knoten abzielen, wobei sich die Patch-Aufgaben zu überschneidenden Zeiten befinden.
+ **Manuelle Patch-Now-Operationen**: Vermeiden Sie es, manuelle **Patch-Now-Operationen** zu initiieren, während das geplante Patchen ausgeführt wird.
## Verwenden von Automation-Runbooks AWS Support
AWS Support stellt zwei Automation-Runbooks bereit, mit denen Sie bestimmte Probleme im Zusammenhang mit Patches beheben können.
+ `AWSSupport-TroubleshootWindowsUpdate` – Das [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html)-Runbook wird verwendet, um Probleme zu identifizieren, bei denen die Windows Server-Updates für Amazon Elastic Compute Cloud (Amazon EC2) Windows Server-Instances fehlschlagen könnten.
+ `AWSSupport-TroubleshootPatchManagerLinux` – Das [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html)-Runbook behebt häufig auftretende Probleme, die zu einem Patch-Fehler auf Linux-basierten verwalteten Knoten führen können, mithilfe von Patch Manager. Das Hauptziel dieses Runbooks besteht darin, die Hauptursache des Fehlers beim Patch-Befehl zu ermitteln und einen Plan zur Behebung vorzuschlagen.
**Anmerkung**
Für die Ausführung von Automation-Runbooks fallen Gebühren an. Weitere Informationen finden Sie unter [AWS Systems Manager Preise für Automatisierung](https://aws.amazon.com/systems-manager/pricing/#Automation).
## Kontaktaufnahme AWS Support
Wenn Sie Problembehandlungs-Lösungen in diesem Abschnitt oder im bschnitt zu Systems-Manager-Problemen in [AWS re:Post](https://repost.aws/tags/TA-UbbRGVYRWCDaCvae6itYg/aws-systems-manager) nicht finden können und einen [Developer-, Business- oder Enterprise- Support -Plan](https://aws.amazon.com/premiumsupport/plans) haben, können Sie unter [AWS Support](https://aws.amazon.com/premiumsupport/) einen technischen Supportfall erstellen.
Sammeln Sie die folgenden Artikel Support, bevor Sie Kontakt aufnehmen:
+ [SSM-Agent-Protokolle](ssm-agent-logs.md)
+ Run Command-Befehls-ID, Wartungsfenster-ID oder Automatisierungsausführungs-ID
+ Sammeln Sie für von Windows Server verwaltete Knoten auch Folgendes:
+ `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs`, wie auf der **Windows**-Registerkarte von [Wie Patches installiert werden](patch-manager-installing-patches.md) beschrieben
+ Windows Update-Protokolle: Für Windows Server 2012 R2 und älter verwenden Sie `%windir%/WindowsUpdate.log`. Führen Sie für Windows Server 2016 und neuere Versionen zuerst den PowerShell Befehl aus, [https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps](https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps)bevor Sie `%windir%/WindowsUpdate.log`
+ Sammeln Sie für Linux-verwaltete Knoten auch Folgendes:
+ Der Inhalt des Verzeichnisses `/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`