• Le AWS Systems Manager CloudWatch tableau de bord ne sera plus disponible après le 30 avril 2026. Les clients peuvent continuer à utiliser CloudWatch la console Amazon pour consulter, créer et gérer leurs CloudWatch tableaux de bord Amazon, comme ils le font aujourd'hui. Pour plus d'informations, consultez la [documentation Amazon CloudWatch Dashboard](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html).
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.
# Mise à jour du logiciel à l'aide de Run Command
Les procédures suivantes décrivent comment mettre à jour le logiciel sur vos nœuds gérés.
## Mise à jour de SSM Agent à l'aide de Run Command
La procédure suivante décrit comment mettre à jour l'SSM Agent en cours d'exécution sur vos nœuds gérés. Vous pouvez mettre à jour à l'aide de la dernière version de l'SSM Agent ou d'une version plus ancienne. Lorsque vous exécutez la commande, le système télécharge la version depuis AWS, l'installe, puis désinstalle la version qui existait avant l'exécution de la commande. Si une erreur se produit au cours de ce processus, le système revient à la version du serveur avant l'exécution de la commande et le statut de cette dernière indique qu'elle a échoué.
**Note**
Si une instance exécute macOS version 13.0 (Ventura) ou ultérieure, elle doit disposer de l’SSM Agent version 3.1.941.0 ou supérieure pour exécuter le document AWS-UpdateSSMAgent. Si l'instance exécute une version de l'SSM Agent publiée avant la version 3.1.941.0, vous pouvez mettre à jour votre SSM Agent pour exécuter le document AWS-UpdateSSMAgent en exécutant les commandes `brew update` et `brew upgrade amazon-ssm-agent`.
Pour recevoir des notifications concernant les mises à jour de SSM Agent, inscrivez‑vous sur la page [SSM Agent Release Notes](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) du site Web de GitHub.
**Pour mettre à jour l'SSM Agent en utilisant Run Command**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Run Command**.
1. Sélectionnez **Run Command (Exécuter la commande)**.
1. In the **Command document (Document de commande)**, sélectionnez **`AWS-UpdateSSMAgent`**.
1. Dans la section **Paramètres de la commande**, indiquez des valeurs pour les paramètres suivants, si vous le souhaitez :
1. (Facultatif) Pour **Version**, saisissez la version de l'SSM Agent à installer. Vous pouvez installer des [versions plus anciennes](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) de l'agent. Si vous ne spécifiez pas de version, le service installe la dernière version.
1. (Facultatif) Pour **Allow Downgrade (Autoriser le retour à la version précédente)**, sélectionnez **true** pour installer une version antérieure de l'SSM Agent. Si vous sélectionnez cette option, spécifiez le numéro de version [antérieure](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md). Sélectionnez **false** pour installer uniquement la dernière version du service.
1. Dans la section **Targets (Cibles)**, sélectionnez les nœuds gérés sur lesquels vous souhaitez exécuter cette opération en spécifiant des balises, en sélectionnant des instances ou des appareils de périphérie manuellement ou en spécifiant un groupe de ressources.
**Astuce**
Si, contrairement à vos attentes, un nœud géré ne figure pas dans la liste, consultez [Résolution des problèmes de disponibilité des nœuds gérés](fleet-manager-troubleshooting-managed-nodes.md) pour obtenir des conseils de dépannage.
1. Pour **Autres paramètres** :
+ Pour **Comment (Commentaire)**, saisissez des informations à propos de cette commande.
+ Pour **Délai (secondes)**, précisez le nombre de secondes durant lesquelles le système doit attendre avant de mettre en échec l'exécution de la commande globale.
1. Pour **Rate control (Contrôle de débit)** :
+ Dans **Concurrency (Simultanéité)**, spécifiez un nombre ou un pourcentage de nœuds gérés sur lesquels exécuter simultanément la commande.
**Note**
Si vous avez sélectionné des cibles en spécifiant des balises appliquées aux nœuds gérés ou en spécifiant AWS des groupes de ressources, et que vous n'êtes pas certain du nombre de nœuds gérés ciblés, limitez le nombre de cibles pouvant exécuter le document en même temps en spécifiant un pourcentage.
+ Dans **Error threshold (Seuil d'erreur)**, indiquez quand arrêter l'exécution de la commande sur les autres nœuds gérés après l'échec de celle-ci sur un certain nombre ou un certain pourcentage de nœuds. Si, par exemple, vous spécifiez trois erreurs, Systems Manager cesse d'envoyer la commande à la réception de la quatrième erreur. Les nœuds gérés sur lesquels la commande est toujours en cours de traitement peuvent également envoyer des erreurs.
1. (Facultatif) Pour **Output options (Options de sortie)**, pour enregistrer la sortie de la commande dans un fichier, cochez la case **Write command output to an S3 bucket (Écrire la sortie de commande vers un compartiment S3)**. Saisissez les noms de compartiment et de préfixe (dossier) dans les zones.
**Note**
Les autorisations S3 qui accordent la possibilité d'écrire les données dans un compartiment S3 sont celles du profil d'instance (pour les instances EC2) ou de la fonction du service IAM (pour les machines activées par un système hybride) attribués à l'instance, et non celles de l'utilisateur IAM qui effectue cette tâche. Pour plus d’informations, consultez les sections [Configurer des autorisations d’instance requises pour Systems Manager](setup-instance-permissions.md) et [Créer un rôle de service IAM pour un environnement hybride](hybrid-multicloud-service-role.md). En outre, si le compartiment S3 spécifié se trouve sur un autre Compte AWS, assurez-vous que le profil d'instance ou la fonction de service IAM associé au nœud géré dispose des autorisations nécessaires pour écrire dans ce compartiment.
1. Dans la section **SNS notifications (Notifications SNS)**, si vous souhaitez envoyer des notifications sur le statut d'exécution des commandes, cochez la case **Enable SNS notifications (Activer les notifications SNS)**.
Pour plus d'informations sur la configuration des notifications Amazon SNS pour Run Command, consultez [Surveillance des changements d'état du Systems Manager à l'aide des notifications Amazon SNS](monitoring-sns-notifications.md).
1. Cliquez sur **Exécuter**.
## Mise à jour PowerShell en utilisant Run Command
La procédure suivante décrit comment effectuer une mise à jour PowerShell vers la version 5.1 sur vos nœuds gérés Windows Server 2012 et 2012 R2. Le script fourni dans cette procédure télécharge la mise à jour de Windows Management Framework (WMF) version 5.1 et démarre l'installation de la mise à jour. Le nœud redémarre au cours de ce processus, comme l'exige l'installation de WMF 5.1. Le téléchargement et l'installation de la mise à jour prennent environ cinq minutes.
**Pour effectuer une mise à jour PowerShell avec Run Command**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Run Command**.
1. Sélectionnez **Run Command (Exécuter la commande)**.
1. In the **Command document (Document de commande)**, sélectionnez **`AWS-RunPowerShellScript`**.
1. Dans la section **Commands (Commandes)**, collez les commandes suivantes pour votre système d'exploitation.
------
#### [ Windows Server 2012 R2 ]
```
Set-Location -Path "C:\Windows\Temp"
Invoke-WebRequest "https://go.microsoft.com/fwlink/?linkid=839516" -OutFile "Win8.1AndW2K12R2-KB3191564-x64.msu"
Start-Process -FilePath "$env:systemroot\system32\wusa.exe" -Verb RunAs -ArgumentList ('Win8.1AndW2K12R2-KB3191564-x64.msu', '/quiet')
```
------
#### [ Windows Server 2012 ]
```
Set-Location -Path "C:\Windows\Temp"
Invoke-WebRequest "https://go.microsoft.com/fwlink/?linkid=839513" -OutFile "W2K12-KB3191565-x64.msu"
Start-Process -FilePath "$env:systemroot\system32\wusa.exe" -Verb RunAs -ArgumentList ('W2K12-KB3191565-x64.msu', '/quiet')
```
------
1. Dans la section **Targets (Cibles)**, sélectionnez les nœuds gérés sur lesquels vous souhaitez exécuter cette opération en spécifiant des balises, en sélectionnant des instances ou des appareils de périphérie manuellement ou en spécifiant un groupe de ressources.
**Astuce**
Si, contrairement à vos attentes, un nœud géré ne figure pas dans la liste, consultez [Résolution des problèmes de disponibilité des nœuds gérés](fleet-manager-troubleshooting-managed-nodes.md) pour obtenir des conseils de dépannage.
1. Pour **Autres paramètres** :
+ Pour **Comment (Commentaire)**, saisissez des informations à propos de cette commande.
+ Pour **Délai (secondes)**, précisez le nombre de secondes durant lesquelles le système doit attendre avant de mettre en échec l'exécution de la commande globale.
1. Pour **Rate control (Contrôle de débit)** :
+ Dans **Concurrency (Simultanéité)**, spécifiez un nombre ou un pourcentage de nœuds gérés sur lesquels exécuter simultanément la commande.
**Note**
Si vous avez sélectionné des cibles en spécifiant des balises appliquées aux nœuds gérés ou en spécifiant AWS des groupes de ressources, et que vous n'êtes pas certain du nombre de nœuds gérés ciblés, limitez le nombre de cibles pouvant exécuter le document en même temps en spécifiant un pourcentage.
+ Dans **Error threshold (Seuil d'erreur)**, indiquez quand arrêter l'exécution de la commande sur les autres nœuds gérés après l'échec de celle-ci sur un certain nombre ou un certain pourcentage de nœuds. Si, par exemple, vous spécifiez trois erreurs, Systems Manager cesse d'envoyer la commande à la réception de la quatrième erreur. Les nœuds gérés sur lesquels la commande est toujours en cours de traitement peuvent également envoyer des erreurs.
1. (Facultatif) Pour **Output options (Options de sortie)**, pour enregistrer la sortie de la commande dans un fichier, cochez la case **Write command output to an S3 bucket (Écrire la sortie de commande vers un compartiment S3)**. Saisissez les noms de compartiment et de préfixe (dossier) dans les zones.
**Note**
Les autorisations S3 qui accordent la possibilité d'écrire les données dans un compartiment S3 sont celles du profil d'instance (pour les instances EC2) ou de la fonction du service IAM (pour les machines activées par un système hybride) attribués à l'instance, et non celles de l'utilisateur IAM qui effectue cette tâche. Pour plus d’informations, consultez les sections [Configurer des autorisations d’instance requises pour Systems Manager](setup-instance-permissions.md) et [Créer un rôle de service IAM pour un environnement hybride](hybrid-multicloud-service-role.md). En outre, si le compartiment S3 spécifié se trouve sur un autre Compte AWS, assurez-vous que le profil d'instance ou la fonction de service IAM associé au nœud géré dispose des autorisations nécessaires pour écrire dans ce compartiment.
1. Dans la section **SNS notifications (Notifications SNS)**, si vous souhaitez envoyer des notifications sur le statut d'exécution des commandes, cochez la case **Enable SNS notifications (Activer les notifications SNS)**.
Pour plus d'informations sur la configuration des notifications Amazon SNS pour Run Command, consultez [Surveillance des changements d'état du Systems Manager à l'aide des notifications Amazon SNS](monitoring-sns-notifications.md).
1. Cliquez sur **Exécuter**.
Une fois que le nœud géré a redémarré et que l'installation de la mise à jour est terminée, connectez-vous à votre nœud pour confirmer que la mise à niveau vers la version 5.1 a été effectuée PowerShell avec succès. Pour vérifier la version de PowerShell sur votre nœud, ouvrez PowerShell et entrez`$PSVersionTable`. La valeur `PSVersion` dans le tableau de sortie affiche 5.1 si la mise à niveau a réussi.
Si la valeur `PSVersion` est différente de 5.1, par exemple 3.0 ou 4.0, consultez les journaux **Setup (Configuration)** dans Event Viewer, sous **Windows Logs (Journaux Windows)**. Ces journaux indiquent la raison de l'échec de la mise à jour.