Debuggen von PowerShell-Skripts, die von der benutzerdefinierten Skripterweiterung oder dem Befehl "Ausführen" ausgeführt werden

Gilt für: Windows ✔️ VMs

Zusammenfassung

In diesem Artikel wird erläutert, wie Sie einen Fehler in einem PowerShell-Skript testen und korrigieren, das das Feature "Custom Script Extension" oder "Run Command" verwendet.

Von Bedeutung

Neu! Probieren Sie VM-Unterstützung aus, um die wichtigsten Probleme zu beheben. Es wird empfohlen, VM-Hilfsprogramm für Windows oder VM-Hilfsprogramm für Linux auszuführen. Diese skriptbasierten Diagnosetools helfen Ihnen, häufige Probleme zu identifizieren, die sich auf den Azure VM-Gast-Agent und die allgemeine VM-Integrität auswirken.

Wenn Leistungsprobleme auf virtuellen Computern auftreten, führen Sie diese Tools zuerst aus, bevor Sie sich an Microsoft-Support wenden.

Voraussetzungen

Azure PowerShell
Das PsExec-Tool

Übersicht

Gehen Sie davon aus, dass Sie die Funktion "Benutzerdefinierte Skripterweiterung" oder "Befehl ausführen" verwendet haben, um ein PowerShell-Skript auszuführen. Was tun Sie, wenn das Skript fehlschlägt? Sie haben mehrere verfügbare Methoden, um die Ursache des Fehlers zu ermitteln.

PowerShell verfügt über mehrere Ausgabedatenströme. Protokolle für benutzerdefinierte Skripterweiterungen und Run Command-Skripts senden den Erfolgsdatenstrom an den StdOut Unterstatus und den Fehlerdatenstrom an den StdErr Unterstatus. Diese Unterstatus gehören zu der Erweiterung, die zum Ausführen des Custom Script Extension-Skripts oder des Run Command-Skripts verwendet wurde.

Die StdOut Und StdErr Unterstatus befinden sich in der CRP-Instanzansicht (Certificate Registration Point) für den virtuellen Computer (VM). Diese Unterstatuse sind an mehreren Orten gemäß der folgenden Tabelle sichtbar.

Schnittstelle	So zeigen Sie den Unterstatus an
Azure Portal	Suchen Sie nach Virtuelle Computer, und wählen Sie diese Option aus. Wählen Sie Ihren virtuellen Computer in der Liste aus. Wählen Sie auf der Seite "VM-Übersicht" die Option "Erweiterungen + Anwendungserweiterungen>" aus. Wählen Sie die Erweiterung aus, die zum Ausführen des Befehls verwendet wurde. (Er wird entweder CustomScriptExtension oder RunCommand benannt.) Wählen Sie "Detaillierten Status anzeigen" aus.
Azure PowerShell	Geben Sie das Cmdlet Get-AzVM ein, um die Eigenschaften einer Azure VM wie folgt abzurufen: `Get-AzVM -ResourceGroupName <resource-group-name> -Name <vm-name> -Status`
Azure CLI	Geben Sie den Befehl az vm get-instance-view ein, um Instanzinformationen zu einer Azure VM abzurufen: `az vm get-instance-view --resource-group <resource-group-name> --name <vm-name> --query instanceView.extensions`

Der Fehler, der normalerweise dazu führt, dass das Skript fehlschlägt, wird im StdErr Unterstatus angezeigt. Skripts können jedoch auch fehlschlagen, ohne einen schwerwiegenden Fehlereintrag in diesem Unterstatus zu protokollieren.

Manuelles Testen des Skripts und mithilfe von PsExec

Stellen Sie manuell sicher, dass das Skript erfolgreich über eine Administrative PowerShell-Konsole auf dem virtuellen Computer ausgeführt wird.

Wenn das Skript manuell funktioniert, verwenden Sie PsExec, um das Skript mithilfe des lokalen Systemkontos auszuführen. Für die benutzerdefinierte Skripterweiterung und den Befehl „Ausführen“ werden Skripte unter Verwendung dieses Kontos ausgeführt. Durch Eingabe psexec -s können Sie das Skript mithilfe des lokalen Systemkontos testen, ohne dabei die benutzerdefinierte Skripterweiterung oder den Ausführen-Befehl zu verwenden. Wenn der Fehler mit psexec -s reproduziert wird, sind die benutzerdefinierte Skripterweiterung und der Run Command nicht die Ursache des Problems.

Testen mithilfe von PsExec

Sie können PsExec verwenden, um ein PowerShell-Testskript remote auszuführen. Öffnen Sie ein Administrator-Eingabeaufforderungsfenster, und geben Sie dann den folgenden PsExec-Befehl ein. Ersetzen Sie den Platzhalter durch den vollqualifizierten Namen des PowerShell-Skripts:

psexec -accepteula -nobanner -s powershell.exe -NoLogo -NoProfile -File <C:\path\script-name.ps1>

Alternativ können Sie PsExec interaktiv verwenden. Im folgenden Beispiel geben Sie den Whoami-Befehl ein, um anzuzeigen, dass PowerShell unter dem Lokalen Systemkonto (NT AUTHORITY\SYSTEM) ausgeführt wird:

C:\>psexec -accepteula -nobanner -s powershell.exe -NoLogo -NoProfile

PS C:\Windows\system32> whoami
nt authority\system

Aktivieren der Protokollierung der PowerShell-Skriptausführung

Wenn der StdErr Unterstatus die Ursache des Problems nicht anzeigt, können Sie mehrere Protokollierungstypen aktivieren, um den Skriptinhalt und die Ausgabe zusammen anzuzeigen. Diese Protokollierung zeigt, was das Skript zu erreichen versucht, und das Ergebnis der Ausführung des Skripts.

Um unterschiedliche Protokollierungsarten zu aktivieren, folgen Sie den Schritten in den nächsten Abschnitten.

Warnung

Einige der Anweisungen umfassen das Ändern der Windows Registrierung. Schwerwiegende Probleme können auftreten, wenn die Registrierung mit dem Registrierungs-Editor oder einer anderen Methode unsachgemäß bearbeitet wird. Aufgrund dieser Probleme kann eine Neuinstallation des Betriebssystems erforderlich sein. Microsoft können nicht garantieren, dass diese Probleme gelöst werden können. Sichern Sie zuerst Ihre vorhandenen Registrierungseinträge , und ändern Sie dann die Registrierung auf eigene Gefahr.

Erhöhen der maximalen Größe der Ereignisprotokolle

Eine große Anzahl von Ereignissen kann sowohl im Sicherheitsprotokoll als auch im Microsoft-Windows-PowerShell/Operational-Ereignisprotokoll generiert werden. Um den Verlust dieser protokollierten Ereignisse zu verhindern, erhöhen Sie die maximale Größe der Protokolle. Wenn jedoch eines dieser Protokolle maximal 100 MB oder größer ist (ein maxSize Wert von 104.857.600 oder mehr), behalten Sie die maximale Größeneinstellung bei.

Verwenden Sie das Kommando wevtutil und die get-log-Option, um Informationen über die maximale Größe von Ereignisprotokollen abzurufen.

wevtutil get-log "Security"
wevtutil get-log "Microsoft-Windows-PowerShell/Operational"

Es wird eine Ausgabe angezeigt, die dem folgenden Text ähnelt. In diesen Fällen beträgt die maximale Protokollgröße viel weniger als 100 MB.

name: Security
enabled: true
type: Admin
owningPublisher:
isolation: Custom
channelAccess: O:BAG:SYD:(A;;CCLCSDRCWDWO;;;SY)(A;;CCLC;;;BA)(A;;CC;;;ER)(A;;CC;;;NS)
logging:
  logFileName: %SystemRoot%\System32\Winevt\Logs\Security.evtx
  retention: false
  autoBackup: false
  maxSize: 20971520
publishing:
  fileMax: 1

name: Microsoft-Windows-PowerShell/Operational
enabled: true
type: Operational
owningPublisher: Microsoft-Windows-PowerShell
isolation: Application
channelAccess: O:BAG:SYD:(A;;0x2;;;S-1-15-2-1)(A;;0x2;;;S-1-15-3-1024-3153509613-960666767-3724611135-2725662640-12138253-543910227-1950414635-4190290187)(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)(A;;0x3;;;S-1-5-33)(A;;0x1;;;S-1-5-32-573)
logging:
  logFileName: %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-PowerShell%4Operational.evtx
  retention: false
  autoBackup: false
  maxSize: 15728640
publishing:
  fileMax: 1

Um die maximale Größe des Sicherheitsprotokolls oder des Microsoft-Windows-PowerShell/Operational-Ereignisprotokolls auf 100 MB zu erhöhen, führen Sie wevtutil zusammen mit der Option set-log aus:

wevtutil set-log "Security" /ms:104857600
wevtutil set-log "Microsoft-Windows-PowerShell/Operational" /ms:104857600

Aktivieren Sie die Prozesserstellungsüberwachung

Verwenden Sie den folgenden Befehl, um die Prozesserstellungsüberwachung zu aktivieren:

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v "ProcessCreationIncludeCmdLine_Enabled" /t REG_DWORD /d 1 /f

Aktivieren der PowerShell-Transkription

reg add "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\Transcription" /v "EnableTranscripting" /t REG_DWORD /d 1 /f
reg add "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\Transcription" /v "EnableInvocationHeader" /t REG_DWORD /d 1 /f
reg add "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\Transcription" /v "OutputDirectory" /t REG_SZ /d C:\Transcripts /f

Aktivieren der PowerShell-Modulprotokollierung

reg add "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging" /v "EnableModuleLogging" /t REG_DWORD /d 1 /f
reg add "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames" /v "*" /t REG_SZ /d *

Aktivieren Sie die PowerShell-Skriptblockprotokollierung

reg add "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v "EnableScriptBlockLogging" /t REG_DWORD /d 1 /f

Die Ausgabe verstehen

Die Überwachung der Prozesserstellung schreibt ereignis-ID 4688 und Ereignis-ID 4689 in das Sicherheitsereignisprotokoll. Ereignis-ID 4688 ist für die Erstellung von Prozessen vorgesehen und enthält die Befehlszeile des Prozesses. Die Ereignis-ID 4689 ist für die Beendigung des Prozesses vorgesehen.

Die Transkription erstellt eine Textdatei im Verzeichnis "C:\Transcripts\<output-date> ". Das Verzeichnis wird automatisch erstellt, wenn es noch nicht vorhanden ist.

Zum Beispiel:

C:\transcripts\20201211\PowerShell_transcript.<vm-name>.a+BWp8CT.20201211034929.txt

Die Modulprotokollierung protokolliert die Ereignis-ID 4103 im Microsoft-Windows-PowerShell/Operational-Ereignisprotokoll. Das Ereignis "4103" enthält den Cmdlet-Namen und die Ausgabe.

Wenn Sie Write-Host $Env:ComputerName ausführen, wird oben in der Ereignis-ID 4013 der folgende Text angezeigt, wobei value="<vm-name>" angibt, dass die Ausgabe des Befehls der Name Ihrer VM war:

CommandInvocation(Write-Host): "Write-Host"
ParameterBinding(Write-Host): name="Object"; value="<vm-name>"

Die Skriptblockprotokollierung protokolliert die Ereignis-ID 4104 im Ereignisprotokoll Microsoft-Windows-PowerShell/Operational. Die "4104"-Ereignisse enthalten den Inhalt des Skripts. Skripts, die die maximale Nachrichtengröße eines Ereignisses überschreiten, werden als mehrere "4104"-Ereignisse protokolliert.

Nachdem Sie die Protokollierung aktiviert und den Skriptfehler reproduziert haben, führen Sie das folgende Skript aus, um die relevanten Ereignisse in eine CSV-Datei (Kommagetrennte Werte) zu exportieren. Die folgende Abfrage untersucht die vorherigen 24 Stunden (86.400.000 Millisekunden) von Daten. Geben Sie den Wert 3600000 ein , um nur die letzte Stunde abzurufen. Der Wert 6048000000 ruft die letzte Woche ab.

$path = "PSEvents_$($env:COMPUTERNAME)_$(Get-Date ((Get-Date).ToUniversalTime()) -Format yyyyMMddHHmmss).csv"

$hours = 1 # Increase this to have it query more than just the last 1 hour
$now = Get-Date
$startTimeUtc = Get-Date ($now.AddHours(-$hours).ToUniversalTime()) -Format 'yyyy-MM-ddTHH:mm:ssZ'
$endTimeUtc = Get-Date ($now.ToUniversalTime()) -Format 'yyyy-MM-ddTHH:mm:ssZ'

$filterXML = @"
<QueryList>
    <Query Id="0" Path="Security">
        <Select Path="Security">
            Event
            [
                System
                [
                    (EventID = '4688' or EventID = '4689')
                    and
                    TimeCreated
                    [
                        @SystemTime &gt;= '$startTimeUtc'
                        and
                        @SystemTime &lt;= '$endTimeUtc'
                    ]
                ]
                and
                EventData
                [
                    Data[@Name="SubjectUserSid"] = "S-1-5-18"
                ]
            ]
        </Select>
    </Query>
    <Query Id="1" Path="Microsoft-Windows-PowerShell/Operational">
        <Select Path="Microsoft-Windows-PowerShell/Operational">
            Event
            [
                System
                [
                    (EventID ='4103' or EventID ='4104')
                    and
                    Security
                    [
                        @UserID ='S-1-5-18'
                    ]
                    and
                    TimeCreated
                    [
                        @SystemTime &gt;= '$startTimeUtc'
                        and
                        @SystemTime &lt;= '$endTimeUtc'
                    ]
                ]
            ]
        </Select>
    </Query>
</QueryList>
"@

$events = Get-WinEvent -FilterXml $filterXML | Sort-Object -Property RecordId
$events = $events | Select-Object -Property RecordId,
    TimeCreated, Id, MachineName, LogName, TaskDisplayName, Message
$events | Export-Csv -Path $path -NoTypeInformation

Deaktivieren der Protokollierung der PowerShell-Skriptausführung

Führen Sie die folgenden Schritte aus, um die von Ihnen vorgenommenen Änderungen rückgängig zu machen, um die Protokollierung von PowerShell-Skripts auf Ihrem virtuellen Computer zu aktivieren:

Wenn Sie zuvor die maximale Größe des Sicherheitsprotokolls oder des Microsoft-Windows-PowerShell/Operational-Protokolls erhöht haben, stellen Sie diese Werte auf die standardmäßigen maximalen Größen zurück:
```
wevtutil set-log "Security" /ms:20971520
wevtutil set-log "Microsoft-Windows-PowerShell/Operational" /ms:15728640
```

Prozesserstellungsüberwachung deaktivieren:

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v "ProcessCreationIncludeCmdLine_Enabled" /t REG_DWORD /d 0 /f

Transkription deaktivieren:

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription" /v "EnableTranscripting" /t REG_DWORD /d 0 /f
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription" /v "EnableInvocationHeader" /t REG_DWORD /d 0 /f
reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription" /v "OutputDirectory"

Modulprotokollierung deaktivieren:

reg add "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging" /v "EnableModuleLogging" /t REG_DWORD /d 0 /f
reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames" /v "*"

Skriptblockprotokollierung deaktivieren:

reg add "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v "EnableScriptBlockLogging" /t REG_DWORD /d 0 /f

Entfernen Sie den Transkriptionsordner:

Remove-Item -Path 'C:\Transcripts' -Force -Recurse

Entweder sichern und löschen Sie das Sicherheitsprotokoll und das Microsoft-Windows-PowerShell/Betriebsprotokoll:

wevtutil clear-log Security /bu:Security.evtx
wevtutil clear-log Microsoft-Windows-PowerShell/Operational /bu:Microsoft-Windows-PowerShell_Operational.evtx

Oder löschen Sie das Sicherheitsprotokoll und das Microsoft-Windows-PowerShell/Betriebsprotokoll, ohne sie zu sichern:

wevtutil clear-log Security
wevtutil clear-log Microsoft-Windows-PowerShell/Operational

Testen Sie die Ausführungsprotokollierung auf Ihrem VM

Laden Sie das Testskript Test-CustomScriptExtension.ps1 in das aktuelle lokale Verzeichnis herunter. Führen Sie dann das Skript auf Ihrem virtuellen Computer mithilfe des Cmdlets Invoke-AzVMRunCommand aus . Verwenden Sie die Eigenschaften Ihres virtuellen Computers, um die Platzhalter für den Ressourcengruppennamen und vm-Namen zu ersetzen.

$scriptUri = 'https://raw.githubusercontent.com/Azure/azure-support-scripts/blob/users/GitHubPolicyService/6294a303-e34d-4bad-b6cd-5ed54245f020/Images_Extensions/PowerShell/Test-CustomScriptExtension.ps1'
$localFileLocation = "$PWD\Test-CustomScriptExtension.ps1"
(New-Object System.Net.WebClient).DownloadFile($scriptUri, $localFileLocation)

$commandSettings = @{
    ResourceGroupName = '<resource-group-name>'
    VMName = '<vm-name>'
    CommandId = 'RunPowerShellScript'
    ScriptPath = $localFileLocation
}
Invoke-AzVMRunCommand @commandSettings

Testen der Protokollierung der benutzerdefinierten Skripterweiterung auf Ihrem virtuellen Computer

Führen Sie das Testskript Test-CustomScriptExtension.ps1 auf Ihrem virtuellen Computer mithilfe des Cmdlets Set-AzVMCustomScriptExtension aus. Verwenden Sie die Eigenschaften Ihres virtuellen Computers, um die Platzhalter für den Ressourcengruppennamen, den VM-Namen und den Speicherort zu ersetzen.

$commandSettings = @{
    ResourceGroupName = '<resource-group-name>'
    VMName = '<vm-name>'
    Name = 'CustomScriptExtension'
    FileUri = 'https://raw.githubusercontent.com/Azure/azure-support-scripts/blob/users/GitHubPolicyService/6294a303-e34d-4bad-b6cd-5ed54245f020/Images_Extensions/PowerShell/Test-CustomScriptExtension.ps1'
    Run = 'Test-CustomScriptExtension.ps1'
    Location = '<azure-region-name-or-code>'
    ForceRerun = (Get-Date).Ticks
}
Set-AzVMCustomScriptExtension @commandSettings

Alternativ können Sie dieses Testskript auf Ihrem virtuellen Computer mithilfe des Cmdlets Set-AzVMExtension ausführen. Sie müssen einen ExtensionType Parameter CustomScriptExtension zusammen mit mehreren anderen Parameteränderungen angeben. Verwenden Sie die Eigenschaften Ihres virtuellen Computers, um die Platzhalter für den Ressourcengruppennamen, den VM-Namen und den Speicherort zu ersetzen.

$publicConfigSettings = @{
    'fileUris' = @('https://raw.githubusercontent.com/Azure/azure-support-scripts/blob/users/GitHubPolicyService/6294a303-e34d-4bad-b6cd-5ed54245f020/Images_Extensions/PowerShell/Test-CustomScriptExtension.ps1')
    'commandToExecute' = 'powershell -File Test-CustomScriptExtension.ps1 -ExecutionPolicy Unrestricted'
}
$commandSettings = @{
    Publisher = 'Microsoft.Compute'
    ExtensionType = 'CustomScriptExtension'
    Settings = $publicConfigSettings
    ResourceGroupName = '<resource-group-name>'
    VMName = '<vm-name>'
    Name = 'CustomScriptExtension'
    TypeHandlerVersion = '1.10'
    Location = '<azure-region-name-or-code>'
}
Set-AzVMExtension @commandSettings

Häufige Fehler im Testskript für benutzerdefinierte Skripterweiterungen

Nonzero-Exitcode: Nachdem Sie das Skript "Test-CustomScriptExtension.ps1 " ausgeführt haben, wird erwartet, dass die folgende Fehlermeldung angezeigt wird:

Fehler beim Vorgang mit langer Ausführungszeit mit dem Status ‚Fehler‘.
Zusätzliche Informationen: VM hat beim Verarbeiten der Erweiterung "CustomScriptExtension" einen Fehler gemeldet.
Fehlermeldung: "Befehlsausführung abgeschlossen, aber fehlgeschlagen, weil sie einen Nicht-Null-Exitcode von: '2'" zurückgegeben hat.

Das Testskript führt den Exit 2 Befehl aus, und die Custom Script Extension soll designbedingt fehlschlagen, wenn das Skript einen Ausgangscode ungleich Null zurückgibt. (In diesem Beispiel ist 2 der Nichtzero-Ausgangscode.) In diesem Beispiel wird gezeigt, wie ein Fehler in der zusätzlichen PowerShell-Protokollierung angezeigt wird, die Sie aktiviert haben.
Change steht in Konflikt: Dieser Fehler gibt an, dass die VM bereits die benutzerdefinierte Skripterweiterung als Ressourcenname Microsoft installiert hat. Compute.CustomScriptExtension, aber Sie geben einen anderen Ressourcennamen von CustomScriptExtension für die aktuelle Ausführung an:

Die handlerVersion oder autoUpgradeMinorVersion der VM-Erweiterung 'CustomScriptExtension' kann nicht aktualisiert werden.
Änderungen stehen in Konflikt mit anderen Erweiterungen unter dem Handler 'Microsoft. Compute.CustomScriptExtension", mit typeHandler-Version "1.10" und autoUpgradeMinorVersion "True".
ErrorCode: Operation nicht erlaubt
ErrorMessage: handlerVersion oder autoUpgradeMinorVersion für VM-Erweiterung 'CustomScriptExtension' kann nicht aktualisiert werden.
Änderungen stehen in Konflikt mit anderen Erweiterungen unter dem Handler 'Microsoft. Compute.CustomScriptExtension", mit typeHandler-Version "1.10" und autoUpgradeMinorVersion "True".
ErrorTarget:
StatusCode: 409
ReasonPhrase: Konflikt

Sie können den gewünschten Ressourcennamen angeben. Wenn Sie jedoch bereits die benutzerdefinierte Skripterweiterung installiert haben, müssen Sie eine der folgenden Aktionen ausführen:
- Verwenden Sie denselben Namen für nachfolgende Ausführungen.
- Entfernen Sie zuerst diese Erweiterungsressource, bevor Sie einen anderen Ressourcennamen verwenden.
Ungültige Datei-URI-Konfiguration: Dieser Fehler gibt an, dass die benutzerdefinierte Skripterweiterung ursprünglich zusammen mit Datei-URIs installiert wurde, die in geschützten Einstellungen angegeben sind, aber jetzt in öffentlichen Einstellungen angegeben sind (oder umgekehrt):

Fehler bei lang andauerndem Vorgang mit dem Status ‚Gescheitert‘.
Zusätzliche Informationen: VM hat beim Verarbeiten der Erweiterung "CustomScriptExtension" einen Fehler gemeldet.
Fehlermeldung: "Ungültige Konfiguration – FileUris ist sowohl im geschützten als auch im öffentlichen Konfigurationsabschnitt vorhanden; sie darf nur in einem Abschnitt angegeben werden."

Lösungen für häufige Fehler im Testskript für benutzerdefinierte Skripterweiterungen

Um den Fehler "Änderung ist in Konflikt" zu beheben, versuchen Sie Set-AzVMCustomScriptExtension oder Set-AzVMExtension erneut auszuführen, setzen Sie jedoch den Parameter -Name auf den Ressourcennamen der Ressource "Benutzerdefinierte Skripterweiterung", die bereits auf dem virtuellen Computer installiert ist. Geben Sie beim Entfernen der Erweiterung für den Beispielfehler einen -Name-Parameter von Microsoft.Compute.CustomScriptExtension an. Aber der -Name Parameter muss genau den Ressourcennamen der Erweiterungsressource entsprechen, die bereits auf dem virtuellen Computer installiert ist.

Der Name, der für -Name verwendet wird, ist der Ressourcenname in diesem Teil des Fehlers: "Änderung steht in Konflikt mit anderen Erweiterungen unter dem Handler '<Ressourcenname>'."

Sie können auch den richtigen Ressourcennamen überprüfen, der verwendet werden soll, indem Sie ihn aus dem VM-Status abrufen. Geben Sie das Cmdlet "Get-AzVM " wie folgt ein:
```
$status = Get-AzVM -ResourceGroupName <resource-group> -Name <vm-name> -Status
$status.Extensions |
Where-Object Type -EQ 'Microsoft.Compute.CustomScriptExtension' |
Select-Object Name
```

Um den Fehler "Änderung ist in Konflikt" und den Fehler "FileUris" zu beheben, können Sie die vorhandene Custom Script Extension entfernen, indem Sie das Remove-AzVMCustomScriptExtension Cmdlet eingeben:

$params = @{
    ResourceGroupName = '<resourceGroupName>'
    VMName = '<vm-name>'
    Name = '<extension-resource-name>'
    Force = $True
}
Remove-AzVMCustomScriptExtension @params

Wenn Sie den falschen Ressourcennamen angeben, lautet der zurückgegebene Wert NoContent: StatusCode

RequestId IsSuccessStatusCode StatusCode ReasonPhrase
--------- ------------------- ---------- ------------
                         True  NoContent No Content

Wenn Sie den richtigen Ressourcennamen angeben, lautet der zurückgegebene Wert StatusCodeOK:

RequestId IsSuccessStatusCode StatusCode ReasonPhrase
--------- ------------------- ---------- ------------
                         True         OK OK

Quellenangaben

Haftungsausschluss für Kontaktinformationen von Drittanbietern

Microsoft enthält Kontaktinformationen von Drittanbietern, die Ihnen bei der Suche nach zusätzlichen Informationen zu diesem Thema helfen. Diese Kontaktinformationen können ohne vorherige Ankündigung geändert werden. Microsoft garantiert nicht die Genauigkeit von Kontaktinformationen von Drittanbietern.

Feedback

War diese Seite hilfreich?

Last updated on 2026-04-16