Comment puis-je résoudre les problèmes liés à une instance WorkSpace Windows à l’état non sain ?

Brève description

WorkSpaces envoie régulièrement une requête de statut d’intégrité à chaque instance WorkSpace pour vérifier leur état. Si WorkSpaces ne reçoit pas de réponse de l’instance WorkSpace, l’état de cette dernière passe à Non sain.

Les problèmes suivants peuvent entraîner le passage du WorkSpace à l’état Non sain :

• Le processeur du WorkSpace est systématiquement sollicité.
• L'agent ou le service qui répond à WorkSpaces n'est pas en cours d'exécution ou l'interface de gestion (ETH0) est désactivée.
• Aucun service Amazon DCV ou PCoIP n'est en cours d'exécution.
• Un logiciel antivirus bloque les composants de WorkSpaces.
• Une application ou une politique de groupe sur le WorkSpace bloque la connexion réseau entre WorkSpaces et le WorkSpace sur l'interface de gestion.
• Les routes de métadonnées sont manquantes.

Résolution

Remarque : Si des erreurs surviennent lorsque vous exécutez des commandes de l'interface de la ligne de commande AWS (AWS CLI), consultez la section Résoudre des erreurs liées à l’AWS CLI. Vérifiez également que vous utilisez bien la version la plus récente de l'AWS CLI.

Utiliser les métriques CloudWatch pour examiner vos WorkSpaces

Pour vous aider à déterminer la cause, consultez les métriques WorkSpaces CPUUsage, MemoryUsage et Non sain dans Amazon CloudWatch.

Redémarrer l’instance WorkSpace

Redémarrez le WorkSpace. Si un redémarrage ne résout pas le problème, utilisez le protocole RDP (Remote Desktop Protocol) pour vous connecter au WorkSpace.

Si vous ne pouvez pas utiliser le protocole RDP pour vous connecter au WorkSpace, consultez la section Comment résoudre les problèmes de connexion RDP liés à mon instance Windows Amazon Elastic Compute Cloud (Amazon EC2) ? Si vous ne parvenez toujours pas à vous connecter au WorkSpace via RDP, consultez la section Restaurer ou reconstruire le WorkSpace.

Vous pouvez également exécuter la commande reboot-workspaces de l’AWS CLI.

Vérifier si l’utilisation du processeur est élevée

Vérifiez si le processeur est fortement sollicité par votre instance Amazon EC2.

Vérifier que les interfaces de gestion et client sont en cours d’exécution

Pour identifier les adresses IP de gestion et d'interface client, exécutez la commande suivante :

ipconfig /all

Pour afficher l'état des interfaces de gestion et client, exécutez la commande suivante :

netsh interface show interface

Si une interface n'est pas à l'état Connecté, exécutez la commande suivante pour activer l'interface :

netsh interface set interface "interface-name" enable

Remarque : Remplacez interface-name par le nom de votre interface.

Vérifier que les services WorkSpaces sont en cours d’exécution et réactifs

Pour vérifier l’état du service, procédez comme suit :

1. Connectez-vous au WorkSpace à l’aide du protocole RDP.
2. Choisissez le menu Démarrer, puis accédez à Services.
3. Sélectionnez l’onglet Services.
4. Vérifiez l’état de chaque service pour votre WorkSpace :
   Instance WorkSpace PCoIP :
   SkylightWorkSpacesConfigService
   Agent standard PCoIP pour Windows
   Instance WorkSpace DCV :
   SkylightWorkSpacesConfigService
   Adaptateur WSP pour DC
   Serveur DCV
5. Si un service n'est pas à l’état En cours d'exécution, ouvrez le menu contextuel et sélectionnez le service. 
   Remarque : Assurez-vous que Type de démarrage est défini sur Automatique.
6. Choisissez Démarrer.

Vérifier la configuration de WorkSpaces

Vérifiez que les logiciels de protection des points de terminaison, tels que les logiciels antivirus ou antimalware, autorisent les composants de service WorkSpaces. Si vous avez activé WorkSpaces Web Access pour PCoIP WorkSpaces, vérifiez que le Service d'application hébergé STXHD est **En cours d’exécution ** et que le Type de démarrage est Automatique.

Remarque : Si vous n'utilisez pas WorkSpaces Web Access, désactivez l'agent STXHD.

Vérifiez également qu'aucune application ou VPN ne bloque votre adaptateur de gestion. Pus, vérifiez la connectivité de votre instance WorkSpace.

Pour vérifier si le certificat Skylight se trouve dans votre magasin de certificats, ouvrez certmgr.msc sur votre ordinateur local. Le certificat se trouve dans le dossier Skylight.

Pour vérifier si une stratégie de groupe bloque la communication sur l'interface de gestion ou sur un service WorkSpaces requis, procédez comme suit :

1. Connectez-vous au WorkSpace à l’aide du protocole RDP.

2. Lancez l'invite de commandes, puis exécutez la commande suivante pour créer un fichier policy.html :

   gpresult /h policy.html

3. Ouvrez le document policy.html, puis recherchez les stratégies qui bloquent la communication avec les interfaces réseau ou les services WorkSpaces.

4. Si vous identifiez une stratégie de blocage, déplacez l'objet informatique WorkSpace vers une unité d’organisation (UO) distincte dans Microsoft Active Directory. Utilisez le paramètre Bloquer l’héritage pour l'objet. Pour plus d'informations sur l'utilisation de Bloquer l’héritage, consultez la section Remplacer et bloquer la stratégie de groupe sur le site Web de Microsoft.

5. Redémarrez le WorkSpace.

Vérifier les règles de pare-feu

Le pare-feu doit autoriser le trafic répertorié sur l'interface du réseau de gestion. Vérifiez également que le pare-feu du système d'exploitation (OS) ou un pare-feu tiers dispose de règles qui autorisent les ports requis.

Vérifier si les routes de métadonnées sont manquantes

Pour vérifier si tous les itinéraires de métadonnées requis se trouvent dans votre instance WorkSpace, exécutez la commande Windows PowerShell suivante :

Get-NetRoute

Si un itinéraire de métadonnées est manquant, exécutez le script suivant pour l'ajouter à votre instance WorkSpace :

$mgmtIp = (Get-ItemProperty "hklm:\software\Amazon\SkyLight\ConfigurationData").ManagementIp
$mgmtGW = (Get-WmiObject win32_networkAdapterConfiguration | where IPAddress -eq $mgmtIp |select DefaultIPGateway).DefaultIPGateway

if($mgmtGW){

route delete 169.254.169.123
route delete 169.254.169.249
route delete 169.254.169.250
route delete 169.254.169.251
route delete 169.254.169.252
route delete 169.254.169.253
route delete 169.254.169.254

route -P add 169.254.169.249 MASK 255.255.255.255 $mgmtGW METRIC 1000
route -P add 169.254.169.250 MASK 255.255.255.255 $mgmtGW METRIC 1000
route -P add 169.254.169.251 MASK 255.255.255.255 $mgmtGW METRIC 1000
route -P add 169.254.169.252 MASK 255.255.255.255 $mgmtGW METRIC 1000
route -P add 169.254.169.253 MASK 255.255.255.255 $mgmtGW METRIC 1000
route -P add 169.254.169.254 MASK 255.255.255.255 $mgmtGW METRIC 1000
route -P add 169.254.169.123 MASK 255.255.255.255 $mgmtGW METRIC 1000

}

Après avoir ajouté la route de métadonnées manquante, redémarrez le WorkSpace.

Restaurer ou reconstruire le WorkSpace

Si vous ne pouvez pas utiliser le protocole RDP pour vous connecter au WorkSpace, restaurez le WorkSpace pour revenir au dernier instantané. Si l’instance WorkSpace est toujours non saine, reconstruisez-la.

Pour restaurer ou reconstruire l’instance WorkSpace, il est recommandé d'utiliser le dossier d’exploitation AWSSupport-RecoverWorkSpace d'AWS Systems Manager.

Important : Lorsque vous restaurez ou reconstruisez un WorkSpace, des pertes de données peuvent survenir. La fonction de restauration rétablit le WorkSpace à partir du dernier instantané disponible datant de moins de 12 heures. La fonction de reconstruction recrée le volume d'utilisateurs à partir de l'instantané le plus récent et le WorkSpace à partir de l'image du bundle à partir duquel vous avez créé l’instance. Vous perdez les applications que vous avez installées ou les paramètres système que vous avez modifiés après avoir créé le WorkSpace.

Avant de lancer l'automatisation, assurez-vous que votre utilisateur ou rôle Gestion des identités et des accès AWS (AWS IAM) dispose des autorisations requises. Pour plus d'informations, consultez la section Autorisations IAM requises d'AWSSupport-RecoverWorkSpace.

Pour utiliser le dossier d’exploitation, procédez comme suit :

1. Ouvrez le dossier d’exploitation AWSSupport-RecoverWorkSpace.
2. Sélectionnez Exécuter l'automatisation.
3. Pour les paramètres d'entrée, saisissez les valeurs suivantes :
   (Facultatif) Dans AutomationAssumeRole, saisissez l’Amazon Resource Name (ARN) du rôle IAM qui permet à l’automatisation d’effectuer les actions. Si vous ne spécifiez aucun rôle, l'automatisation utilise les autorisations de l'utilisateur qui lance le dossier d’exploitation.
   Dans Confirmer, saisissez Oui pour confirmer que les actions de restauration et de reconstruction permettent de récupérer l’instance WorkSpace à partir de l'instantané le plus récent.
   Pour Redémarrer, Reconstruire ou Restaurer, sélectionnez Oui comme option préférée.
   Pour WorkspaceId, saisissez l'ID du WorkSpace que vous souhaitez récupérer.
4. Sélectionnez Exécuter.
5. Vérifiez l’état de votre WorkSpace dans la section Sortie du dossier d’exploitation.

Vous pouvez également exécuter les commandes restore-workspace ou rebuild-workspaces de l’AWS CLI.

Si aucune des étapes de dépannage précédentes ne résout votre problème, collectez les journaux côté client et ouvrez un dossier AWS Support.

Informations connexes

Adresse IP et port requis pour WorkSpaces Personal

Activer les fonctionnalités de gestion en libre-service de WorkSpaces pour vos utilisateurs dans WorkSpaces Personal

Comment puis-je résoudre les problèmes liés à une instance WorkSpace Linux à l’état non sain ?