Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résolution des problèmes de Patch Manager

Utilisez les informations suivantes pour vous aider à résoudre les problèmes liés Patch Manager à une fonctionnalité de AWS Systems Manager.

Problème : erreur « Invoke- PatchBaselineOperation  : accès refusé » ou erreur « Impossible de télécharger le fichier depuis S3 » pour baseline_overrides.json

Problème : lorsque les opérations de correction spécifiées par votre politique de correction s'exécutent, vous recevez une erreur similaire à l'exemple suivant.

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.

Cause : vous avez créé une politique de correctif dansQuick Setup, et certains de vos nœuds gérés étaient déjà associés à un profil d'instance (pour les EC2 instances) ou à un rôle de service (pour les EC2 non-machines). Cependant, vous n'avez pas coché la case Ajouter IAM les politiques requises aux profils d'instance existants attachés à vos instances, comme illustré dans l'image suivante.

Lorsque vous créez une politique de correctifs, un compartiment Amazon S3 est également créé pour stocker le fichier baseline_overrides.json de configuration de la politique. Si vous ne cochez pas la case Ajouter IAM les politiques requises aux profils d'instance existants attachés à vos instances lors de la création de la politique, IAM les politiques et les balises de ressources nécessaires pour accéder baseline_overrides.json au compartiment S3 ne sont pas automatiquement ajoutées à vos profils d'IAMinstance et rôles de service existants.

Solution 1 : supprimer la configuration de politique de correctifs existante, puis créer une configuration de remplacement, en veillant à cocher la case Ajouter IAM les politiques requises aux profils d'instance existants attachés à vos instances. Cette sélection applique les IAM politiques créées par cette Quick Setup configuration aux nœuds auxquels un profil d'instance ou un rôle de service est déjà attaché. (Par défaut, Quick Setup ajoute les politiques requises aux instances et aux nœuds qui n'ont pas encore de profils d'instance ou de fonction du service.) Pour plus d'informations, consultez Automatiser l'application de correctifs à l'échelle de l'organisation à l'aide d'une politique de correctifs Quick Setup.

Solution 2 : ajoutez manuellement les autorisations et les balises requises à chaque profil d'IAMinstance et rôle de IAM service que vous utilisez avecQuick Setup. Pour obtenir des instructions, consultez Autorisations pour le compartiment S3 de la politique de correctifs.

Problème : le correctif échoue sans cause apparente ni message d'erreur

Problème : une opération de correctif échoue sans renvoyer de message d'erreur.

Cause possible : si plusieurs invocations de AWS-RunPatchBaseline se produisent en même temps, elles peuvent entrer en conflit les unes avec les autres, ce qui entraîne l'échec des tâches de correctif. Cela peut ne pas être indiqué dans les journaux correctifs.

Pour vérifier si des opérations de correction simultanées peuvent s'être interrompues, consultez l'historique des commandes dansRun Command, une fonctionnalité de AWS Systems Manager. Pour un nœud géré qui présente un échec de correction, vérifiez si plusieurs opérations ont tenté de corriger l'ordinateur à moins de deux minutes d'intervalle. Ce scénario peut parfois provoquer une défaillance.

Vous pouvez également utiliser le AWS Command Line Interface (AWS CLI) pour vérifier les tentatives d'application de correctifs simultanées à l'aide de la commande suivante. Remplacez la valeur de node-id avec l'ID de votre nœud géré.

aws ssm list-commands \
    --filter "key=DocumentName,value=AWS-RunPatchBaseline" \
    --query 'Commands[*].{CommandId:CommandId,RequestedDateTime:RequestedDateTime,Status:Status}' \
    --instance-id node-id \
    --output table

Solution : si vous déterminez que la correction a échoué en raison d'opérations de correction concurrentes sur le même nœud géré, ajustez vos configurations de correction pour éviter que cela ne se reproduise. Par exemple, si deux fenêtres de maintenance spécifient des heures de correctif qui se chevauchent, supprimez ou révisez l'une d'entre elles. Si une fenêtre de maintenance spécifie une opération de correction, mais qu'une politique de correctifs en spécifie une autre pour la même heure, envisagez de supprimer la tâche de la fenêtre de maintenance.

Si vous déterminez que les opérations de correctifs conflictuelles n'étaient pas la cause de l'échec dans ce scénario, nous vous recommandons de contacter AWS Support.

Problème : résultats de conformité aux correctifs inattendus

Problème : lorsque vous examinez les informations de conformité aux correctifs générées après une opération Scan, les résultats incluent des informations qui ne reflètent pas les règles définies dans votre référentiel de correctifs. Par exemple, une exception que vous avez ajoutée à la liste Rejected patches (Correctifs rejetés) dans un référentiel de correctifs est répertoriée comme Missing. Ou les correctifs considérés comme Important sont répertoriés comme manquants alors que votre référentiel de correctifs ne spécifie que des correctifs Critical.

Cause : Patch Manager prend actuellement en charge plusieurs méthodes d'exécution des opérations Scan :

Lorsqu'une opération Scan s'exécute, elle remplace les informations de conformité issues de l'analyse la plus récente. Si plusieurs méthodes sont configurées pour exécuter une opération Scan et qu'elles utilisent des référentiels de correctifs différents avec des règles différentes, elles se traduiront par des résultats de conformité aux correctifs différents.

Solution : pour éviter des résultats inattendus de conformité aux correctifs, nous vous recommandons de n'utiliser qu'une seule méthode à la fois pour exécuter l'opération Scan de Patch Manager. Pour de plus amples informations, veuillez consulter Éviter les remplacements involontaires des données de conformité aux correctifs.

Erreurs lors de l'exécution de AWS-RunPatchBaseline sur Linux

Problème : erreur indiquant « Pas de fichier ou de répertoire »

Problème : lorsque vous exécutez AWS-RunPatchBaseline, l'application des correctifs échoue avec l'une des erreurs suivantes.

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

Cause 1 : deux commandes servant à exécuter AWS-RunPatchBaseline s'exécutaient en même temps sur le même nœud géré. Cela crée une condition de concurrence qui empêche la création des file patch-baseline-operations* temporaires, ou l'accès normal à celles-ci.

Cause 2 : l'espace de stockage restant dans le répertoire /var est insuffisant.

Solution 1 : assurez-vous qu'aucune fenêtre de maintenance ne comporte au moins deux Run Command tâches exécutées AWS-RunPatchBaseline avec le même niveau de priorité et exécutées sur la même cibleIDs. Si tel est le cas, réorganisez la priorité .Run Command est une fonctionnalité de AWS Systems Manager.

Solution 2 : vérifiez qu'une seule fenêtre de maintenance à la fois exécute des tâches Run Command qui utilisent AWS-RunPatchBaseline sur les mêmes cibles et selon le même calendrier. Si tel est le cas, modifiez le calendrier.

Solution 3 : vérifiez qu'une seule association State Manager exécute AWS-RunPatchBaseline selon le même calendrier et cible les mêmes nœuds gérés. State Manager est une fonctionnalité d' AWS Systems Manager.

Solution 4 : libérez suffisamment d'espace de stockage dans le répertoire /var pour les packages de mise à jour.

Problème : erreur indiquant « un autre processus a acquis yum lock »

Problème : lorsque vous exécutez AWS-RunPatchBaseline, l'application des correctifs échoue avec l'erreur suivante.

12/20/2019 21:41:48 root [INFO]: another process has acquired yum lock, waiting 2 s and retry.

Cause : le document AWS-RunPatchBaseline a commencé à s'exécuter sur un nœud géré alors qu'il est déjà en cours d'exécution dans une autre opération. Il a acquis le processus yum du gestionnaire de packages.

Solution : vérifiez qu'aucune association State Manager, tâche de fenêtre de maintenance ou autre configuration qui exécute AWS-RunPatchBaseline selon une planification ne cible le même nœud géré en même temps.

Problème : erreur indiquant « Autorisation refusée /échec d'exécution des commandes »

Problème : lorsque vous exécutez AWS-RunPatchBaseline, l'application des correctifs échoue avec l'erreur suivante.

sh: 
/var/lib/amazon/ssm/instanceid/document/orchestration/commandid/PatchLinux/_script.sh: Permission denied
failed to run commands: exit status 126

Cause : /var/lib/amazon/ peut être monté avec des autorisations noexec. Cela pose un problème car SSM Agent télécharge des scripts de charge utile dans /var/lib/amazon/ssm et les exécute depuis cet emplacement.

Solution : la vérification de la configuration des partitions exclusives est nécessaire pour /var/log/amazon et /var/lib/amazon, ainsi que leur montée avec des autorisations exec.

Problème : erreur indiquant « Impossible de télécharger la charge utile »

Problème : lorsque vous exécutez AWS-RunPatchBaseline, l'application des correctifs échoue avec l'erreur suivante.

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

Cause : le nœud géré ne dispose pas des autorisations requises pour accéder au compartiment Amazon Simple Storage Service (Amazon S3) spécifié.

Solution : mettez à jour votre configuration réseau pour que les points de terminaison S3 soient accessibles. Pour plus de détails, consultez les informations relatives à l'accès requis aux compartiments S3 pour Patch Manager dans Communications de l'SSM Agent avec des compartiments S3 gérés par AWS.

Problème : erreur indiquant « gestionnaire de packages et combinaison de versions python non pris en charge »

Problème : lorsque vous exécutez AWS-RunPatchBaseline, l'application des correctifs échoue avec l'erreur suivante.

An unsupported package manager and python version combination was found. Apt requires Python3 to be installed.
failed to run commands: exit status 1

Cause : aucune version prise en charge de python3 n'est pas installée sur l'instance Debian Server, Raspberry Pi OS ou Ubuntu Server.

Solution : installez une version prise en charge de python3 (3.0 à 3.10) sur le serveur, comme l'exigent les nœuds gérés Debian Server, Raspberry Pi OS et Ubuntu Server.

Problème : Patch Manager n'applique pas les règles spécifiées pour exclure certains packages

Problème : vous avez tenté d'exclure certains packages en les spécifiant dans le fichier /etc/yum.conf, au format exclude=package-name, mais lors de l'opération Install de Patch Manager il s'avère qu'ils ne sont pas exclus.

Cause : Patch Manager n'incorpore pas les exclusions spécifiées dans le fichier /etc/yum.conf.

Solution : pour exclure des packages spécifiques, créez un référentiel de correctifs personnalisé et créez une règle pour exclure les packages que vous ne voulez pas installer.

Problème : l'application des correctifs échoue et Patch Manager indique que l'extension d'indication du nom du serveur vers n'TLSest pas disponible

Problème : l'opération d'application de correctifs émet le message suivant.

/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

Cause : ce message n'indique pas une erreur. Il s'agit plutôt d'un avertissement indiquant que l'ancienne version de Python distribuée avec le système d'exploitation ne prend pas en charge l'indication TLS du nom du serveur. Le script de charge utile du correctif Systems Manager émet cet avertissement lors de la connexion à AWS APIs ce supportSNI.

Solution : pour résoudre les échecs d'application de correctifs lorsque ce message est signalé, consultez le contenu des fichiers stdout et stderr. Si vous n'avez pas configuré la ligne de base de correctifs pour stocker ces fichiers dans un compartiment S3 ou dans Amazon CloudWatch Logs, vous pouvez les localiser à l'emplacement suivant sur votre nœud géré Linux.

/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux

Problème : Patch Manager signale « Plus de miroirs à essayer »

Problème : l'opération d'application de correctifs émet le message suivant.

[Errno 256] No more mirrors to try.

Cause : les référentiels configurés sur le nœud géré ne fonctionnent pas correctement. Les causes possibles incluent :

Solution : Patch Manager utilise le gestionnaire de packages par défaut du nœud géré pour appliquer les correctifs. Vérifiez que les référentiels sont configurés et fonctionnent correctement.

Problème : le correctif échoue avec « Code d'erreur 23 renvoyé par curl »

Problème : une opération d'application de correctifs qui utilise AWS-RunPatchBaseline échoue avec une erreur semblable à celle-ci :

05/01/2023 17:04:30 root [ERROR]: Error code returned from curl is 23

Cause : l'outil curl utilisé sur vos systèmes ne dispose pas des autorisations nécessaires pour écrire sur le système de fichiers. Cela peut se produire lorsque l'outil curl par défaut du gestionnaire de packages a été remplacé par une version différente, telle que celle installée avec snap.

Solution : si la version curl fournie par le gestionnaire de packages a été désinstallée lors de l'installation d'une autre version, réinstallez-la.

Si vous devez conserver plusieurs versions de curl installées, assurez-vous que la version associée au gestionnaire de packages se trouve dans le premier répertoire répertorié dans la variable PATH. Vous pouvez le vérifier en exécutant la commande echo $PATH pour voir l'ordre actuel des répertoires dans lesquels les fichiers exécutables sont vérifiés sur votre système.

Problème : le correctif échoue avec le message « Error unpacking rpm package… » (Erreur de décompactage du package rpm…)

Problème : une opération de correctif échoue avec un message d'erreur similaire au suivant :

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

Cause 1 : lorsqu'un package particulier est présent dans plusieurs installateurs de packages, comme pip et yum ou dnf, des conflits peuvent survenir lors de l'utilisation du gestionnaire de packages par défaut.

Un exemple courant est celui du package urllib3, qui se trouve dans pip, yum et dnf.

Cause 2 : le package python-urllib3 est endommagé. Cela peut se produire si les fichiers du package ont été installés ou mis à jour par pip après que le package rpm ait été précédemment installé par yum ou dnf.

Solution : supprimez le package python-urllib3 de pip en exécutant la commande sudo pip uninstall urllib3, en conservant le package uniquement dans le gestionnaire de package par défaut (yum ou dnf).

Problème : le correctif échoue avec le message « Errors were encountered while downloading packages » (Des erreurs ont été rencontrées lors du téléchargement des packages)

Problème : pendant le correctif, vous recevez un message d'erreur similaire au suivant :

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',

Cause : cette erreur peut se produire lorsque la mémoire disponible sur un nœud géré est insuffisante.

Solution : configurez la mémoire d'échange ou mettez à niveau l'instance vers un type différent pour augmenter la prise en charge de la mémoire. Lancez ensuite une nouvelle opération de correctif.

Problème : le correctif échoue avec le message suivant : « The following signatures couldn't be verified because the public key is not available » (Les signatures suivantes n'ont pas pu être vérifiées, car la clé publique n'est pas disponible)

Problème : le correctif échoue sur Ubuntu Server avec une erreur similaire à la suivante :

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

Cause : La clé GNU Privacy Guard (GPG) a expiré ou est manquante.

Solution : actualisez la GPG clé ou ajoutez-la de nouveau.

Par exemple, en utilisant l'erreur montrée précédemment, nous voyons que la clé 467B942D3A79BD29 est manquante et doit être ajoutée. Pour ce faire, exécutez l'une des commandes suivantes :

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

Ou, pour actualiser toutes les clés, exécutez la commande suivante :

sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --refresh-keys

Si l'erreur se reproduit, nous vous recommandons de signaler le problème à l'organisation qui gère le référentiel. Jusqu'à ce qu'un correctif soit disponible, vous pouvez modifier le fichier /etc/apt/sources.list afin d'omettre le référentiel pendant le processus de correctif.

Pour ce faire, ouvrez le fichier sources.list pour le modifier, localisez la ligne relative au référentiel et insérez un caractère # au début de la ligne pour la mettre en commentaire. Ensuite, enregistrez et fermez le fichier.

Problème : l'application de correctifs échoue avec un message « NoMoreMirrorsRepoError »

Problème : vous recevez une erreur similaire à la suivante :

NoMoreMirrorsRepoError: failure: repodata/repomd.xml from pgdg94: [Errno 256] No more mirrors to try.

Cause : il y a une erreur dans le référentiel source.

Solution : nous vous recommandons de signaler le problème à l'organisation qui gère le référentiel. Jusqu'à ce que l'erreur soit corrigée, vous pouvez désactiver le référentiel au niveau du système d'exploitation. Pour ce faire, exécutez la commande suivante en remplaçant la valeur de repo-name avec le nom de votre dépôt :

yum-config-manager --disable repo-name

Voici un exemple.

yum-config-manager --disable pgdg94

Après avoir exécuté cette commande, lancez une autre opération de correctif.

Problème : le correctif échoue avec un message « Unable to download payload » (Impossible de télécharger la charge utile)

Problème : vous recevez une erreur similaire à la suivante :

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

Cause : la configuration du nœud géré contient des erreurs ou est incomplète.

Solution : assurez-vous que le nœud géré est configuré avec les éléments suivants :

Problème : le correctif échoue avec un message « install errors: dpkg: error: dpkg frontend is locked by another process » (erreurs d'installation : dpkg : erreur : dpkg frontend est bloqué par un autre processus)

Problème : le correctif échoue avec une erreur similaire à la suivante :

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

Cause : le gestionnaire de packages exécute déjà un autre processus sur un nœud géré au niveau du système d'exploitation. Si cet autre processus prend beaucoup de temps à se terminer, l'opération de correctif Patch Manager peut prendre du temps et échouer.

Solution : une fois que l'autre processus utilisant le gestionnaire de packages est terminé, exécutez une nouvelle opération de correctif.

Problème : le correctif sur Ubuntu Server échoue avec une erreur « dpkg was interrupted » (dpkg a été interrompu)

Problème : sur Ubuntu Server, le correctif échoue avec une erreur similaire à la suivante :

E: dpkg was interrupted, you must manually run
'dpkg --configure -a' to correct the problem.

Cause : un ou plusieurs packages sont mal configurés.

Solution : procédez comme suit :

Problème : l'utilitaire du gestionnaire de packages ne peut pas résoudre la dépendance d'un package

Problème : le gestionnaire de packages natif du nœud géré ne parvient pas à résoudre une dépendance de package et le correctif échoue. L'exemple de message d'erreur suivant indique ce type d'échec sur un système d'exploitation qui utilise yum comme gestionnaire de packages.

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']

Cause : sur les systèmes d'exploitation Linux, Patch Manager utilise le gestionnaire de packages natif de l'ordinateur pour exécuter les opérations de correctif. telles que yum, dnf, apt et zypper. Les applications détectent, installent, mettent à jour ou suppriment automatiquement les packages dépendants selon les besoins. Cependant, dans certaines conditions, le gestionnaire de packages peut être dans l'incapacité de mener à bien une opération de dépendance, comme par exemple :

Solution : le correctif peut échouer en raison d'un problème de dépendance pour une grande variété de raisons. Par conséquent, nous vous recommandons de nous contacter AWS Support pour obtenir de l'aide pour le dépannage.

Erreurs lors de l'exécution de AWS-RunPatchBaseline sur Windows Server

Problème : familles de produits/paires de produits dépareillées

Problèmes : lorsque vous créez un référentiel de correctifs dans la console Systems Manager, vous spécifiez une famille de produits et un produit. Par exemple, vous pouvez choisir ce qui suit :

Cause : si vous essayez de créer un référentiel de correctifs avec une paire famille de produits/produit non assortie, un message d'erreur s'affiche. Voici les cas où cette situation peut se présenter :

Solution : pour éviter ce problème dans la console, sélectionnez toujours des options des sous-listes Currently available options (Options actuellement disponibles).

Vous pouvez également afficher les produits pour lesquels des correctifs sont disponibles à l'aide de la describe-patch-properties commande AWS CLI ou de la DescribePatchProperties API commande.

Problème: AWS-RunPatchBaseline renvoie un HRESULT (Windows Server)

Problème : vous avez reçu une erreur similaire à la suivante.

----------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

Cause : ce résultat indique que le Windows Update natif n'a pas APIs pu exécuter les opérations de correction.

Solution : vérifiez le code HResult dans les rubriques suivantes sur microsoft.com afin d'identifier les étapes de résolution de cette erreur :

Problème : le nœud géré n'a pas accès au catalogue Windows Update ou WSUS

Problème : vous avez reçu une erreur similaire à la suivante.

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----

Cause : Cette erreur peut être liée aux composants Windows Update ou à un manque de connectivité au catalogue Windows Update ou aux services Windows Server Update (WSUS).

Solution : Vérifiez que le nœud géré est connecté au catalogue Microsoft Update via une passerelle Internet, une NAT passerelle ou une NAT instance. Si vous en utilisezWSUS, vérifiez que le nœud géré est connecté au WSUS serveur de votre environnement. Si la connectivité est disponible pour la destination prévue, vérifiez la documentation Microsoft pour trouver d'autres causes potentielles à HResult 0x80072EE2. Cela peut indiquer un problème au niveau du système d'exploitation.

Problème : le PatchBaselineOperations PowerShell module n'est pas téléchargeable

Problème : vous avez reçu une erreur similaire à la suivante.

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

Solution : vérifiez la connectivité du nœud géré et les autorisations d'accès à Amazon Simple Storage Service (Amazon S3). Le rôle du nœud géré AWS Identity and Access Management (IAM) doit utiliser les autorisations minimales citées dansCommunications de l'SSM Agent avec des compartiments S3 gérés par AWS. Le nœud doit communiquer avec le point de terminaison Amazon S3 via le point de terminaison, la NAT passerelle ou la passerelle Internet Amazon S3. Pour plus d'informations sur les exigences relatives au point de VPC terminaison pour AWS Systems Manager SSM Agent (SSM Agent), consultezAméliorez la sécurité des EC2 instances en utilisant des VPC points de terminaison pour Systems Manager.

Problème : correctifs manquants

Problème : AWS-RunPatchbaseline s'est terminé avec succès, mais il manque certains correctifs.

Voici quelques causes courantes et leurs solutions.

Cause 1 : le référentiel n'est pas en vigueur.

Solution 1 : pour vérifier si la cause est bien liée à ce problème, procédez comme suit :

Cause 2 : le correctif a été remplacé.

Solution 2 : pour vérifier si cela est vrai, procédez comme suit.

Cause 3 : le même correctif peut avoir des numéros de base de données différents car les mises à jour en ligne WSUS et Windows sont traitées comme des canaux de publication indépendants par Microsoft.

Solution 3 : vérifiez l'éligibilité du correctif. Si le package n'est pas disponible sousWSUS, installez le build du système d'exploitation 14393.3115. Si le package est disponible pour toutes les versions du système d'exploitation, installez les versions de système d'exploitation 18362.1256 et 18363.1256.

Contacter AWS Support

Si vous ne trouvez pas de solutions de dépannage dans cette section ou dans les problèmes Systems Manager de AWS re:Post, et que vous disposez d'une formule AWS Support Développeur, Business ou Entreprise, vous pouvez formuler une demande de prise en charge technique à l'adresse AWS Support.

Avant de nous contacter AWS Support, collectez les objets suivants :