Dépannage des échecs d’extension de machine virtuelle Windows dans Azure

Vue d’ensemble des modèles Azure Resource Manager

Les modèles Azure Resource Manager vous permettent de spécifier de manière déclarative l’infrastructure IaaS Azure en langage JSON en définissant les dépendances entre ressources.

Pour en savoir plus sur la création de modèles permettant l’utilisation d’extensions, consultez Création de modèles Azure Resource Manager avec des extensions de machine virtuelle Windows .

Dans cet article, nous apprendrons à dépanner certains des échecs d’extension de machine virtuelle les plus courants.

Affichage de l’état de l’extension

Les modèles Azure Resource Manager sont exécutables à partir d’Azure PowerShell. Une fois que le modèle est exécuté, l'état de l'extension peut être affiché à partir d'Azure Resource Explorer ou des outils de ligne de commande.

Voici un exemple :

Azure PowerShell :

Get-AzVM -ResourceGroupName $RGName -Name $vmName -Status

Voici l'exemple de sortie :

Extensions:  {
  "ExtensionType": "Microsoft.Compute.CustomScriptExtension",
  "Name": "myCustomScriptExtension",
  "SubStatuses": [
    {
      "Code": "ComponentStatus/StdOut/succeeded",
      "DisplayStatus": "Provisioning succeeded",
      "Level": "Info",
      "Message": "    Directory: C:\\temp\\n\\n\\nMode                LastWriteTime     Length Name
          \\n----                -------------     ------ ----                              \\n-a---          9/1/2015   2:03 AM         11
          test.txt                          \\n\\n",
                  "Time": null
      },
    {
      "Code": "ComponentStatus/StdErr/succeeded",
      "DisplayStatus": "Provisioning succeeded",
      "Level": "Info",
      "Message": "",
      "Time": null
    }
  ]
}

Dépannage des échecs d’extension

Vérifier que l'agent de machine virtuelle est en cours d'exécution et prêt

L'agent de machine virtuelle est nécessaire pour gérer, installer et exécuter les extensions. Si l'agent de machine virtuelle n'est pas en cours d'exécution ou ne parvient pas à signaler un état Prêt à la plateforme Azure, les extensions ne fonctionneront pas correctement.

Pour résoudre les problèmes liés à l'agent de machine virtuelle, consultez les pages suivantes :

Rechercher le guide de résolution des problèmes liés à votre extension

Certaines extensions disposent d'une page dédiée à la résolution des problèmes. Pour obtenir la liste de ces extensions et pages, consultez Résolution des problèmes.

Afficher l'état de l'extension

Comme expliqué ci-dessus, pour connaître l'état de l’extension, exécutez la cmdlet PowerShell suivante :

Get-AzVM -ResourceGroupName $RGName -Name $vmName -Status

ou la commande CLI suivante :

az vm extension show -g <RG Name> --vm-name <VM Name>  --name <Extension Name>

ou, sur le portail Azure, accédez au panneau des machines virtuelles et sélectionnez Paramètres/Extensions. Vous pouvez ensuite cliquer sur l'extension pour consulter son état et son message.

Réexécuter l’extension sur la machine virtuelle

Si vous exécutez des scripts sur la machine virtuelle à l’aide de l’extension de script personnalisé, cela peut générer une erreur indiquant que la machine virtuelle a été créée avec succès mais que le script a échoué. Dans ces conditions, la méthode recommandée pour corriger cette erreur consiste à supprimer l'extension et exécuter le modèle à nouveau. Remarque : cette fonctionnalité sera ultérieurement améliorée de manière à ne plus devoir désinstaller l'extension.

Suppression de l’extension d’Azure PowerShell

Remove-AzVMExtension -ResourceGroupName $RGName -VMName $vmName -Name "myCustomScriptExtension"

Une fois que l'extension a été supprimée, le modèle peut être réexécuté pour exécuter les scripts sur la machine virtuelle.

Déclencher un nouveau GoalState sur la machine virtuelle

Vous pouvez remarquer qu’une extension n’a pas été exécutée ou ne peut pas s’exécuter en raison d’un « générateur de certificats CRP Windows Azure » manquant (ce certificat est utilisé pour sécuriser le transport des paramètres protégés de l’extension). Ce certificat est automatiquement régénéré lors du redémarrage de l’agent invité Windows à partir de la machine virtuelle :

  • Ouvrir le Gestionnaire des tâches
  • Accéder à l’onglet Détails
  • Rechercher le processus WindowsAzureGuestAgent.exe
  • Cliquez avec le bouton droit, puis sélectionnez « Terminer la tâche ». Le processus sera redémarré automatiquement.

Vous pouvez également déclencher un nouveau GoalState sur la machine virtuelle, en exécutant « VM Reapply ». L’API VM Reapply, introduite en 2020, permet de réappliquer l’état d’une machine virtuelle. Nous vous recommandons de le faire à un moment où vous pouvez tolérer un court temps d’arrêt des machines virtuelles. Reapply ne provoque pas en elle-même le redémarrage d’une machine virtuelle, qui la plupart du temps ne se produit pas. Cependant, il est très peu probable qu’une autre mise à jour en attente du modèle de machine virtuelle soit appliquée lorsque Reapply déclenche un nouveau GoalState et qu’une autre modification exige un redémarrage.

Portail Azure :

Sur le portail, sélectionnez la machine virtuelle. Dans le volet gauche, sous Support + dépannage, sélectionnez Redéployer + réappliquer, puis Reapply.

Azure PowerShell (remplacez « RG Name » et « VM Name » par le nom de votre groupe de ressources et celui de votre machine virtuelle) :

Set-AzVM -ResourceGroupName <RG Name> -Name <VM Name> -Reapply

Azure CLI (remplacez « RG Name » et « VM Name » par le nom de votre groupe de ressources et celui de votre machine virtuelle) :

az vm reapply -g <RG Name> -n <VM Name>

Si « VM Reapply » n’a pas fonctionné, vous pouvez ajouter un nouveau disque de données vide à la machine virtuelle sur le Portail de gestion Azure, puis le supprimer une fois le certificat rajouté.

Examiner les journaux d'une extension à l'intérieur de la machine virtuelle

Si les étapes précédentes n'ont pas fonctionné et si votre extension est toujours en état d'échec, l'étape suivante consiste à consulter ses journaux à l'intérieur de la machine virtuelle.

Sur une machine virtuelle Windows, les journaux des extensions se trouvent généralement à l'emplacement suivant :

C:\WindowsAzure\Logs\Plugins

Tandis que les paramètres et les fichiers d'état de ces extensions se trouvent sous :

C:\Packages\Plugins

Sur une machine virtuelle Linux, les journaux des extensions se trouvent généralement à l'emplacement suivant :

/var/log/azure/

Tandis que les paramètres et les fichiers d'état de ces extensions se trouvent sous :

/var/lib/waagent/

Chaque extension est différente, mais elles obéissent généralement à des principes similaires :

Les packages d’extension et les fichiers binaires sont téléchargés sur la machine virtuelle (par ex., « /var/lib/waagent/custom-script/download/1 » pour Linux ou « C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\Downloads\0 » pour Windows).

Leur configuration et leurs paramètres sont passés de la plateforme Azure au gestionnaire d’extensions à travers l’agent VM (par ex., « /var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.3/config » pour Linux ou « C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\RuntimeSettings » pour Windows)

Les gestionnaires d’extensions des machines virtuelles écrivent dans un fichier d’état (par ex. « /var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.3/status/1.status » pour Linux ou « C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\Status » pour Windows) qui est ensuite rapporté à la plateforme Azure. Cet état est celui signalé par le biais de PowerShell, de l'interface CLI ou du panneau Extension de la machine virtuelle sur le portail Azure.

Ils écrivent également des journaux détaillés de leur exécution (par ex., « /var/log/azure/custom-script/handler.log » pour Linux ou « C:\WindowsAzure\Logs\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\CustomScriptHandler.log » pour Windows).

Si la machine virtuelle est recréée à partir d'une machine virtuelle existante

Dans certaines circonstances, vous pouvez être amené à créer une machine virtuelle Azure basée sur un disque spécialisé provenant d'une autre machine virtuelle Azure. Dans ce cas, il est possible que l'ancienne machine virtuelle contienne des extensions et qu'il reste donc des fichiers binaires, des journaux et des fichiers d'état. Le nouveau modèle de machine virtuelle ne connaîtra pas l'état des extensions de la machine virtuelle précédente, ce qui peut entraîner le signalement d'un état incorrect pour ces extensions. Nous vous recommandons fortement de supprimer les extensions de l'ancienne machine virtuelle avant de créer la nouvelle, puis de réinstaller ces extensions une fois la nouvelle machine virtuelle créée. La même chose peut se produire lorsque vous créez une image généralisée à partir d'une machine virtuelle Azure existante. Nous vous invitons à supprimer les extensions pour éviter les incohérences d'état liées à celles-ci.

Problèmes connus

PowerShell n’est pas reconnu comme une commande interne ou externe

Vous remarquez les entrées d’erreur suivantes dans la sortie de l’extension RunCommand :

RunCommandExtension failed with "'powershell' isn't recognized as an internal or external command,"

Analyse

Les extensions s’exécutent sous le compte système local. Il est donc très possible que powershell.exe fonctionne correctement lorsque vous RDP dans la machine virtuelle, mais échoue lors de l’exécution avec RunCommand.

Solution

  • Vérifiez que PowerShell est correctement répertorié dans la variable d’environnement PATH :
    • Ouvrez le Panneau de configuration
    • Système et sécurité
    • Système
    • Onglet Avancé - Variables environnementales >
  • Sous « Variables système », cliquez sur modifier et vérifiez que PowerShell se trouve dans la variable d’environnement PATH (généralement : « C:\Windows\System32\WindowsPowerShell\v1.0 »)
  • Redémarrez la machine virtuelle ou redémarrez le service WindowsAzureGuestAgent, puis réessayez d’exécuter la commande.

Command n’est pas reconnu comme une commande interne ou externe

Vous voyez les éléments suivants dans le fichier C:\WindowsAzure\Logs\Plugins<ExtensionName><Version>\CommandExecution.log :

Execution Error: '<command>' isn't recognized as an internal or external command, operable program or batch file.

Analyse

Les extensions s’exécutent sous le compte système local. Il est donc très possible que powershell.exe fonctionne correctement lorsque vous RDP dans la machine virtuelle, mais échoue lors de l’exécution avec RunCommand.

Solution

  • Ouvrez une invite de commandes dans la machine virtuelle et exécutez une commande pour reproduire l’erreur. L’agent de machine virtuelle utilise l’administrateur cmd.exe et vous pouvez avoir une commande préconfigurée pour s’exécuter chaque fois que cmd est démarré.
  • Il est également probable que votre variable PATH soit mal configurée, mais cela dépend de la commande qui rencontre le problème.

VMAccessAgent échoue avec impossible de mettre à jour les paramètres de connexion Bureau à distance pour le compte Administrateur. Erreur : System.Runtime.InteropServices.COMException (0x800706D9) : aucun point de terminaison n’est disponible à partir du mappeur de point de terminaison.

Vous voyez les éléments suivants dans l’état de l’extension :

Type Microsoft.Compute.VMAccessAgent
Version 2.4.8
Status Provisioning failed
Status level Error
Status message Cannot update Remote Desktop Connection settings for Administrator account. Error: System.Runtime.InteropServices.COMException (0x800706D9): There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9) at NetFwTypeLib.INetFwRules.GetEnumerator() at 
Microsoft.WindowsAzure.GuestAgent.Plugins.JsonExtensions.VMAccess.RemoteDesktopManager.EnableRemoteDesktopFirewallRules() 
at Microsoft.WindowsAzure.GuestAgent.Plugins.JsonExtensions.VMAccess.RemoteDesktopManager.EnableRemoteDesktop() at

Analyse

Cette erreur peut se produire lorsque le service de pare-feu Windows n’est pas en cours d’exécution.

Solution

Vérifiez si le service de pare-feu Windows est activé et en cours d’exécution. Si ce n’est pas le cas, activez et démarrez-le, puis réessayez d’exécuter VMAccessAgent.

Le certificat distant n’est pas valide selon la procédure de validation.

Vous voyez ce qui suit dans WaAppAgent.log

System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.
Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

Analyse

Votre machine virtuelle manque probablement le certificat racine Baltimore CyberTrust dans « Autorités de certification racines approuvées ».

Solution

Ouvrez la console de certificats avec certmgr.msc, puis vérifiez si le certificat existe.

Un autre problème possible est que la chaîne de certificats est rompue par un outil d’inspection SSL tiers, comme ZScaler. Ce type d’outil doit être configuré pour contourner l’inspection SSL.