Problembehandlung bei Fehlern im Zusammenhang mit Azure Windows-VM-Erweiterungen
Übersicht über Azure-Ressourcen-Manager-Vorlagen
Azure Resource Manager-Vorlagen ermöglichen es Ihnen, deklarativ die Azure IaaS-Infrastruktur in der JSON-Sprache anzugeben, indem Sie die Abhängigkeiten zwischen Ressourcen definieren.
Weitere Informationen zum Erstellen von Vorlagen für die Verwendung von Erweiterungen finden Sie unter Erstellen von Erweiterungsvorlagen .
In diesem Artikel erfahren Sie mehr über die Problembehandlung für einige der allgemeinen VM-Erweiterungsfehler.
Anzeigen des Erweiterungsstatus
Azure Resource Manager-Vorlagen können aus Azure PowerShell ausgeführt werden. Sobald die Vorlage ausgeführt wird, kann der Erweiterungsstatus im Azure-Ressourcen-Explorer oder in den Befehlszeilentools angezeigt werden.
Beispiel:
Azure PowerShell:
Get-AzVM -ResourceGroupName $RGName -Name $vmName -Status
Hier ist die Beispielausgabe:
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
}
]
}
Problembehandlung bei Erweiterungsfehlern
Überprüfen Sie, ob der VM-Agent ausgeführt wird und bereit ist.
Der VM-Agent ist zum Verwalten, Installieren und Ausführen von Erweiterungen erforderlich. Wenn der VM-Agent nicht ausgeführt wird oder nicht den Status „Bereit“ an die Azure-Plattform melden kann, funktionieren die Erweiterungen nicht ordnungsgemäß.
Informationen zur Problembehandlung für den VM-Agent finden Sie auf den folgenden Seiten:
- Problembehandlung beim Microsoft Azure-Gast-Agent für eine Windows-VM
- Behandeln von Problemen mit dem Azure Linux-Agent für eine Linux-VM
Suchen Sie nach ihrem spezifischen Leitfaden zur Problembehandlung für Erweiterungen.
Einige Erweiterungen verfügen über eine bestimmte Seite, auf der die Problembehandlung beschrieben wird. Die Liste dieser Erweiterungen und Seiten finden Sie unter Problembehandlung bei Erweiterungen.
Anzeigen des Erweiterungsstatus
Wie oben erläutert wurde, kann der Status der Erweiterung durch Ausführen des PowerShell-Cmdlets:
Get-AzVM -ResourceGroupName $RGName -Name $vmName -Status
oder des CLI-Befehls:
az vm extension show -g <RG Name> --vm-name <VM Name> --name <Extension Name>
oder im Azure-Portal ermittelt werden, indem Sie zum VM-Blatt /Einstellungen/Erweiterungen navigieren. Sie können dann auf die Erweiterung klicken und deren Status und Meldung überprüfen.
Erneutes Ausführen der Erweiterung auf dem virtuellen Computer
Wenn Sie mithilfe der benutzerdefinierten Skripterweiterung Skripts auf der VM ausführen, könnten ab und an Fehler auftreten, bei denen die VM erfolgreich erstellt wurde, das Skript jedoch fehlgeschlagen ist. Unter diesen Bedingungen empfiehlt es sich, die Erweiterung zu entfernen und die Vorlage erneut auszuführen, um den Fehler zu beheben. Hinweis: In Zukunft wird diese Funktionalität verbessert, damit es nicht mehr notwendig ist, die Erweiterung zu deinstallieren.
Entfernen der Erweiterung aus Azure PowerShell
Remove-AzVMExtension -ResourceGroupName $RGName -VMName $vmName -Name "myCustomScriptExtension"
Nachdem die Erweiterung entfernt wurde, kann die Vorlage erneut ausgeführt werden, um die Skripts auf dem virtuellen Computer auszuführen.
Auslösen eines neuen GoalState für die VM
Möglicherweise stellen Sie fest, dass eine Erweiterung nicht ausgeführt wurde oder aufgrund eines fehlenden „Microsoft Azure CRP Certificate Generator“ nicht ausgeführt werden kann. (Dieses Zertifikat wird verwendet, um den Transport der geschützten Einstellungen der Erweiterung abzusichern.) Dieses Zertifikat wird automatisch erneut generiert, indem der Windows-Gast-Agent im virtuellen Computer neu gestartet wird:
- Öffnen Sie den Task-Manager.
- Navigieren Sie zur Registerkarte „Details“.
- Suchen Sie den Prozess „WindowsAzureGuestAgent.exe“.
- Klicken Sie mit der rechten Maustaste darauf, und wählen Sie „Task beenden“ aus. Der Prozess wird automatisch neu gestartet.
Ferner können Sie für die VM einen neuen GoalState auslösen, indem Sie ein „VM Reapply“ ausführen. VM Reapply ist eine API, die 2020 eingeführt wurde und dazu dient, den Zustand einer VM erneut anzuwenden. Wir empfehlen Ihnen, dies zu einem Zeitpunkt durchzuführen, an dem eine kurze Ausfallzeit der VM akzeptabel ist. Zwar löst Reapply selbst keinen Neustart der VM aus, und in der überwiegenden Mehrzahl der Fälle führt das Aufrufen von Reapply nicht zu einem Neustart der VM, es besteht jedoch das sehr kleine Risiko, dass ein anderes ausstehendes Update des VM-Modells angewendet wird, wenn Reapply einen neuen Zielzustand auslöst, und diese andere Änderung macht möglicherweise einen Neustart erforderlich.
Azure-Portal:
Wählen Sie im Portal die VM und im linken Bereich unter Support und Problembehandlung die Option Redeploy + reapply (Erneut bereitstellen und erneut anwenden) aus. Wählen Sie dann Reapply (Erneut anwenden) aus.
Azure PowerShell (ersetzen Sie den RG-Namen und den VM-Namen durch Ihre Werte) :
Set-AzVM -ResourceGroupName <RG Name> -Name <VM Name> -Reapply
Azure CLI (ersetzen Sie den RG-Namen und den VM-Namen durch Ihre Werte) :
az vm reapply -g <RG Name> -n <VM Name>
Wenn ein „VM Reapply“ nicht funktioniert, können Sie der VM einen neuen leeren Datenträger für Daten aus dem Azure-Verwaltungsportal hinzufügen und diesen später entfernen, nachdem das Zertifikat wieder hinzugefügt wurde.
Ansehen der Erweiterungsprotokolle auf dem virtuellen Computer
Wenn die vorherigen Schritte nicht funktioniert haben und sich Ihre Erweiterung weiterhin in einem fehlerhaften Zustand befindet, besteht der nächste Schritt darin, die zugehörigen Protokolle auf dem virtuellen Computer anzuzeigen.
Auf einer Windows-VM befinden sich die Erweiterungsprotokolle in der Regel in
C:\WindowsAzure\Logs\Plugins
Die Erweiterungseinstellungen und Statusdateien befinden sich in
C:\Packages\Plugins
Auf einer Linux-VM befinden sich die Erweiterungsprotokolle in der Regel in
/var/log/azure/
Die Erweiterungseinstellungen und Statusdateien befinden sich in
/var/lib/waagent/
Jede Erweiterung ist anders, aber sie folgen in der Regel ähnlichen Prinzipien:
Erweiterungspakete und Binärdateien werden auf den virtuellen Computer heruntergeladen (z. B. „/var/lib/waagent/custom-script/download/1“ für Linux oder „C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\Downloads\0“ für Windows).
Ihre Konfiguration und Einstellungen werden über den VM-Agent von der Azure-Plattform an den Erweiterungsbehandler übergeben (z. B. „/var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.3/config“ für Linux oder „C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\RuntimeSettings“ für Windows).
Erweiterungsbehandler innerhalb des virtuellen Computers schreiben in eine Statusdatei (z. B. „/var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.3/status/1.status“ für Linux oder „C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\Status“ für Windows), die dann an die Azure-Plattform gemeldet wird. Dieser Status wird über PowerShell, die CLI oder auf dem Blatt „Erweiterung“ des virtuellen Computers im Azure-Portal gemeldet.
Außerdem schreiben sie detaillierte Protokolle ihrer Ausführung (z. B. „/var/log/azure/custom-script/handler.log“ für Linux oder „C:\WindowsAzure\Logs\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\CustomScriptHandler.log“ für Windows).
Wenn der virtuelle Computer von einem vorhandenen virtuellen Computer neu erstellt wird
Es kann vorkommen, dass Sie eine Azure-VM erstellen, die auf einem spezialisierten Datenträger basiert, der von einem anderen virtuellen Azure-Computer stammt. In diesem Fall ist es möglich, dass die alte VM Erweiterungen enthält und daher Binärdateien, Protokolle und Statusdateien übrig bleiben. Das neue VM-Modell erkennt die Erweiterungsstatus der vorherigen VM nicht und meldet möglicherweise einen falschen Status für diese Erweiterungen. Es wird dringend empfohlen, die Erweiterungen von der alten VM vor dem Erstellen der neuen VM zu entfernen und diese Erweiterungen neu zu installieren, nachdem die neue VM erstellt wurde. Dasselbe kann passieren, wenn Sie ein generalisiertes Image aus einer vorhandenen Azure-VM erstellen. Sie sollten Erweiterungen entfernen, um inkonsistente Status aus den Erweiterungen zu vermeiden.
Bekannte Probleme
PowerShell wird nicht als interner oder externer Befehl erkannt
Sie stellen die folgenden Fehlereinträge in der Ausgabe der RunCommand-Erweiterung fest:
RunCommandExtension failed with "'powershell' isn't recognized as an internal or external command,"
Analyse
Erweiterungen werden unter dem lokalen Systemkonto ausgeführt. Daher ist es sehr gut möglich, dass „powershell.exe“ beim Aufruf der VM per RDP ordnungsgemäß funktioniert, aber bei Ausführung mit der Skriptausführung fehlschlägt.
Lösung
- Überprüfen Sie, ob PowerShell in der PATH-Umgebungsvariable ordnungsgemäß aufgeführt ist:
- Systemsteuerung öffnen
- System und Sicherheit
- System
- Registerkarte „Erweitert“ > „Umgebungsvariablen“
- Klicken Sie unter „Systemvariablen“ auf „Bearbeiten“, und stellen Sie sicher, dass PowerShell sich in der PATH-Umgebungsvariable befindet (in der Regel „C:\Windows\Windows\System32\WindowsPowerShell\v1.0“).
- Starten Sie die VM neu, oder starten Sie den WindowsAzureGuestAgent-Dienst neu. Führen Sie dann die Skriptausführung erneut aus.
PowerShell wird nicht als interner oder externer Befehl erkannt
In der Datei „C:\WindowsAzure\Logs\Plugins<Erweiterungsname><Version>\CommandExecution.log“ finden Sie Folgendes:
Execution Error: '<command>' isn't recognized as an internal or external command, operable program or batch file.
Analyse
Erweiterungen werden unter dem lokalen Systemkonto ausgeführt. Daher ist es sehr gut möglich, dass „powershell.exe“ beim Aufruf der VM per RDP ordnungsgemäß funktioniert, aber bei Ausführung mit der Skriptausführung fehlschlägt.
Lösung
- Öffnen Sie eine Eingabeaufforderung in der VM, und führen Sie einen Befehl aus, um den Fehler zu reproduzieren. Der VM-Agent verwendet „cmd.exe“ mit Administratorrechten, und möglicherweise haben Sie einen Befehl vorkonfiguriert, der bei jedem Start von cmd ausgeführt wird.
- Es ist außerdem wahrscheinlich, dass Ihre PATH-Variable falsch konfiguriert ist, aber dies hängt von dem Befehl ab, bei dem das Problem auftritt.
VMAccessAgent verursacht den Fehler „Remotedesktop-Verbindungseinstellungen können für Administratorkonto nicht aktualisiert werden“. Fehler: System.Runtime.InteropServices.COMException (0x800706D9): Von der Endpunktzuordnung sind keine weiteren Endpunkte verfügbar.
Im Status der Erweiterung wird Folgendes angezeigt:
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
Dieser Fehler kann auftreten, wenn der Windows-Firewalldienst nicht ausgeführt wird.
Lösung
Überprüfen Sie, ob der Windows-Firewalldienst aktiviert ist und ausgeführt wird. Wenn dies nicht der Fall ist, aktivieren und starten Sie ihn, und versuchen Sie dann erneut, den VMAccessAgent auszuführen.
Das Remotezertifikat ist laut Validierungsverfahren ungültig.
In „WaAppAgent.log“ wird Folgendes angezeigt.
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
Ihrer VM fehlt wahrscheinlich das Baltimore CyberTrust Root-Zertifikat unter „Vertrauenswürdige Stammzertifizierungsstellen“.
Lösung
Öffnen Sie die Zertifikatkonsole über „certmgr.msc“, und überprüfen Sie, ob das Zertifikat vorhanden ist.
Ein weiteres mögliches Problem besteht darin, dass die Zertifikatkette von einem Drittanbieter-SSL-Inspektionstool wie ZScaler unterbrochen wird. Diese Art von Tool sollte so konfiguriert werden, dass die SSL-Inspektion umgangen wird.