Felsöka fel i Azure Windows VM-tillägg

  • Artikel

Översikt över Azure Resource Manager-mallar

Med Azure Resource Manager-mallar kan du ange Azure IaaS-infrastrukturen med deklarativt JSON-språk genom att definiera beroenden mellan resurser.

Mer information om hur du redigerar mallar för att använda tillägg finns i Redigera tilläggsmallar .

I den här artikeln ska vi lära oss om felsökning av vanliga problem med virtuella datortillägg.

Visa tilläggsstatus

Azure Resource Manager mallar kan köras från Azure PowerShell. När mallen har körts kan tilläggsstatusen visas från Azure Resource Explorer eller kommandoradsverktygen.

Här är ett exempel:

Azure PowerShell:

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

Här är exempelutdata:

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

Felsöka tilläggsfel

Kontrollera att VM-agenten körs och är klar

VM-agenten krävs för att hantera, installera och köra tillägg. Om VM-agenten inte körs eller inte rapporterar statusen Klar till Azure-plattformen fungerar inte tilläggen korrekt.

Se följande sidor för att felsöka VM-agenten:

Sök efter felsökningsguiden för ditt specifika tillägg

Vissa tillägg har en specifik sida som beskriver hur du felsöker dem. Du hittar listan över dessa tillägg och sidor i Felsöka tillägg .

Visa tilläggets status

Som beskrivs ovan kan tilläggets status hittas genom att köra PowerShell-cmdleten:

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

eller CLI-kommandot:

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

eller i Azure Portal genom att bläddra till vm-bladet/inställningar/tillägg. Du kan sedan klicka på tillägget och kontrollera dess status och meddelande.

Kör tillägget på den virtuella datorn igen

Om du kör skript på den virtuella datorn med hjälp av tillägget för anpassat skript kan du ibland stöta på ett fel där den virtuella datorn skapades, men skriptet misslyckades. Under dessa förhållanden är det rekommenderade sättet att återställa från det här felet att ta bort tillägget och köra mallen igen. Obs! I framtiden skulle den här funktionen förbättras för att ta bort behovet av att avinstallera tillägget.

Ta bort tillägget från Azure PowerShell

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

När tillägget har tagits bort kan mallen köras igen för att köra skripten på den virtuella datorn.

Utlösa en ny GoalState till den virtuella datorn

Du kanske märker att ett tillägg inte har körts eller inte kan köras på grund av att "Windows Azure CRP Certificate Generator" saknas (certifikatet används för att skydda transporten av tilläggets skyddade inställningar). Certifikatet återskapas automatiskt genom att windows-gästagenten startas om från den virtuella datorn:

  • Öppna Aktivitetshanteraren
  • Gå till fliken Information
  • Leta upp WindowsAzureGuestAgent.exe processen
  • Högerklicka och välj "Avsluta uppgift". Processen startas om automatiskt

Du kan också utlösa en ny GoalState till den virtuella datorn genom att köra en "VM Reapply". Vm Reapply är ett API som introducerades 2020 för att återappa en virtuell dators tillstånd. Vi rekommenderar att du gör detta i en tid då du kan tolerera en kort stilleståndstid för virtuella datorer. Även om reapply inte orsakar omstart av en virtuell dator och de allra flesta gånger som anropar Reapply inte startar om den virtuella datorn, finns det en mycket liten risk att någon annan väntande uppdatering av VM-modellen tillämpas när Reapply utlöser ett nytt måltillstånd, och att andra ändringar kan kräva en omstart.

Azure Portal:

I portalen väljer du den virtuella datorn och i den vänstra rutan under Support + felsökning väljer du Omdistribuera + använd igen och väljer sedan Använd igen.

Azure PowerShell (ersätt RG-namnet och VM-namnet med dina värden):

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

Azure CLI (ersätt RG-namnet och vm-namnet med dina värden):

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

Om en "VM Reapply" inte fungerade kan du lägga till en ny tom datadisk till den virtuella datorn från Azure-hanteringsportalen och sedan ta bort den senare när certifikatet har lagts till igen.

Titta på tilläggsloggarna i den virtuella datorn

Om föregående steg inte fungerade och tillägget fortfarande är i ett misslyckat tillstånd är nästa steg att titta på loggarna i den virtuella datorn.

På en virtuell Windows-dator finns tilläggsloggarna vanligtvis i

C:\WindowsAzure\Logs\Plugins

Och tilläggsinställningarna och statusfilerna finns i

C:\Packages\Plugins

På en virtuell Linux-dator finns tilläggsloggarna vanligtvis i

/var/log/azure/

Och tilläggsinställningarna och statusfilerna finns i

/var/lib/waagent/

Varje tillägg är olika, men de följer vanligtvis liknande principer:

Tilläggspaket och binärfiler laddas ned på den virtuella datorn (t.ex. "/var/lib/waagent/custom-script/download/1" för Linux eller "C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\Downloads\0" för Windows).

Deras konfiguration och inställningar skickas från Azure Platform till tilläggshanteraren via VM-agenten (t.ex. "/var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.3/config" för Linux eller "C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\RuntimeSettings" för Windows)

Tilläggshanterare i den virtuella datorn skriver till en statusfil (t.ex. "/var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.3/status/1.status" för Linux eller "C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\Status" för Windows) som sedan rapporteras till Azure-plattformen. Den statusen är den som rapporteras via PowerShell, CLI eller på den virtuella datorns tilläggsblad i Azure Portal.

De skriver också detaljerade loggar över sin körning (t.ex. "/var/log/azure/custom-script/handler.log" för Linux eller "C:\WindowsAzure\Logs\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\CustomScriptHandler.log" för Windows).

Om den virtuella datorn återskapas från en befintlig virtuell dator

Det kan hända att du skapar en virtuell Azure-dator baserat på en specialiserad disk som kommer från en annan virtuell Azure-dator. I så fall är det möjligt att den gamla virtuella datorn innehåller tillägg, och därför har binärfiler, loggar och statusfiler kvar. Den nya VM-modellen känner inte till den tidigare virtuella datorns tilläggstillstånd, och den kan rapportera en felaktig status för dessa tillägg. Vi rekommenderar starkt att du tar bort tilläggen från den gamla virtuella datorn innan du skapar den nya och sedan installerar om tilläggen när den nya virtuella datorn har skapats. Samma sak kan inträffa när du skapar en generaliserad avbildning från en befintlig virtuell Azure-dator. Vi inbjuder dig att ta bort tillägg för att undvika inkonsekvent tillstånd från tilläggen.

Kända problem

PowerShell identifieras inte som ett internt eller externt kommando

Du ser följande felposter i RunCommand-tilläggets utdata:

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

Analys

Tillägg körs under lokalt systemkonto, så det är mycket möjligt att powershell.exe fungerar bra när du RDP till den virtuella datorn, men misslyckas när du kör med RunCommand.

Lösning

  • Kontrollera att PowerShell visas korrekt i PATH-miljövariabeln:
    • Öppna Kontrollpanelen
    • System och säkerhet
    • System
    • Fliken Avancerat –> Miljövariabler
  • Under Systemvariabler klickar du på Redigera och kontrollerar att PowerShell finns i PATH-miljövariabeln (vanligtvis: "C:\Windows\System32\WindowsPowerShell\v1.0")
  • Starta om den virtuella datorn eller starta om windowsAzureGuestAgent-tjänsten och försök sedan köra kommandot igen.

Kommandot identifieras inte som ett internt eller externt kommando

Du ser följande i filen 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.

Analys

Tillägg körs under lokalt systemkonto, så det är mycket möjligt att powershell.exe fungerar bra när du RDP till den virtuella datorn, men misslyckas när du kör med RunCommand.

Lösning

  • Öppna en kommandotolk på den virtuella datorn och kör ett kommando för att återskapa felet. VM-agenten använder administratörs-cmd.exe och du kan ha ett förkonfigurerat kommando för att köra varje gång cmd startas.
  • Det är också troligt att path-variabeln är felkonfigurerad, men detta beror på vilket kommando som har problemet.

VMAccessAgent misslyckas med Det går inte att uppdatera anslutningsinställningarna för fjärrskrivbord för administratörskontot. Fel: System.Runtime.InteropServices.COMException (0x800706D9): Det finns inga fler slutpunkter tillgängliga från slutpunktsmapparen.

Du ser följande i tilläggets status:

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

Analys

Det här felet kan inträffa när Windows-brandväggstjänsten inte körs.

Lösning

Kontrollera om Windows-brandväggstjänsten är aktiverad och körs. Om det inte är det aktiverar du och startar det . Försök sedan igen för att köra VMAccessAgent.

Fjärrcertifikatet är ogiltigt enligt valideringsproceduren.

Du ser följande i 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.

Analys

Den virtuella datorn saknar förmodligen Baltimore CyberTrust Root-certifikatet i "Betrodda rotcertifikatutfärdare".

Lösning

Öppna certifikatkonsolen med certmgr.msc och kontrollera om certifikatet finns där.

Ett annat möjligt problem är att certifikatkedjan bryts av ett SSL-inspektionsverktyg från tredje part, till exempel ZScaler. Den typen av verktyg bör konfigureras för att kringgå SSL-inspektion.