Felsök runbook-problem
I den här artikeln beskrivs runbook-problem som kan uppstå och hur du löser dem. Allmän information finns i Runbook-körning i Azure Automation.
Det går inte längre att använda cmdletar från importerade icke-standardmoduler i grafiska PowerShell-runbooks
Problem
När du importerar en PowerShell-modul kan du inte använda dess cmdletar i grafiska PowerShell-runbooks.
Orsak
För att förbättra säkerhetsstatusen för PowerShell-runbooks bearbetar tjänsten inte längre modulmanifestfilen för att exportera cmdletar och funktioner. Det innebär att de inte kan användas vid redigering av grafiska PowerShell-runbooks.
Åtgärd
Körningen av befintliga runbooks påverkas inte. För nya runbooks som använder PowerShell-moduler som inte är standard rekommenderar vi att du använder textbaserade runbooks i stället för grafiska PowerShell-runbooks för att lösa problemet. Du kan använda Azure Automation-tillägget för VScode för redigering och redigering av PowerShell-runbooks, som använder GitHub Copilot för att förenkla runbook-redigeringsupplevelsen.
Start-AzAutomationRunbook misslyckas med felmeddelandet "runbookName matchar inte förväntat mönster"
Problem
När du kör Start-AzAutomationRunbook
för att starta specifika runbooks:
start-azautomationRunbook -Name "Test_2" -AutomationAccountName "AutomationParent" -ResourceGroupName "AutomationAccount"
Det misslyckas med följande fel:
Start-AzAutomationRunbook: "runbookname" does not match expected pattern '^[a-zA-Z]*-*[a-zA-Z0-9]*$'
Orsak
Kod som introducerades i 1.9.0-versionen av Az.Automation-modulen verifierar namnen på runbooks att starta och felaktigt flaggar runbooks med flera "-" tecken eller med ett "_" tecken i namnet som ogiltigt.
Lösning
Vi rekommenderar att du återgår till 1.8.0-versionen av modulen.
Åtgärd
För närvarande arbetar vi med att distribuera en korrigering för att åtgärda problemet.
Diagnostisera runbook-problem
När du får fel vid runbook-körning i Azure Automation kan du använda följande steg för att diagnostisera problemen:
Kontrollera att det går att köra runbook-skriptet utan fel på den lokala datorn.
Information om språkreferens och inlärningsmoduler finns i PowerShell Docs eller Python Docs. Om du kör skriptet lokalt kan du identifiera och lösa vanliga fel, till exempel:
- Moduler saknas
- Syntaxfel
- Logikfel
Undersöka felströmmar i runbook.
Titta på de här strömmarna för specifika meddelanden och jämför dem med de fel som beskrivs i den här artikeln.
Kontrollera att noderna och Automation-arbetsytan har de moduler som krävs.
Om din runbook importerar några moduler kontrollerar du att de är tillgängliga för ditt Automation-konto med hjälp av stegen i Importera moduler. Uppdatera dina PowerShell-moduler till den senaste versionen genom att följa anvisningarna i Uppdatera Azure PowerShell-moduler i Azure Automation. Mer felsökningsinformation finns i Felsöka moduler.
Om din runbook pausas eller misslyckas oväntat:
- Förnya webhooken om du försöker använda en utgången webhook för att starta din runbook.
- Kontrollera jobbstatus för att fastställa aktuell runbook-status och möjliga orsaker till problemet.
- Lägg till ytterligare utdata i din runbook för att identifiera vad som händer innan runbooken pausas.
- Hantera eventuella undantag som jobbet utlöser.
Utför det här steget om runbook-jobbet eller miljön på Hybrid Runbook Worker inte svarar.
Om du kör jobb med en Hybrid Runbook Worker istället för i Azure Automation kanske du behöver felsöka själva Hybrid Worker.
Scenario: Det går inte att skapa ett nytt Automation-jobb i regionen Europa, västra
Problem
När du skapar nya Automation-jobb kan det uppstå en fördröjning, eller så kan det hända att det inte går att skapa jobb. Schemalagda jobb dras tillbaka automatiskt och jobb som körs via portalen kan dras tillbaka om du ser ett fel.
Orsak
Detta beror på den höga belastningen från kundernas runbooks med hjälp av Automation-tjänsten i regionen Europa, västra.
Åtgärd
Utför följande åtgärd om det är möjligt enligt dina krav och din miljö för att minska risken för fel:
- Om du använder den övre delen av timmen för att skapa jobbet (kl. 12:00, 1:00, 2:00 och så vidare.), vanligtvis på timmen eller halvtimmen, rekommenderar vi att du flyttar starttiden för jobbet till fem minuter före eller efter timmen/halvtimmen. Detta beror på att de flesta kunder använder början av timmen för jobbkörning, vilket drastiskt ökar belastningen på tjänsten, medan belastningen är relativt låg vid de andra tidsintervallen.
Scenario: Runbook misslyckas med "this. Client.SubscriptionId får inte vara null." felmeddelande
Problem
Din runbook med hjälp av en hanterad identitet Connect-AzAccount -Identity som försöker hantera Azure-objekt, misslyckas med att fungera och loggar följande fel – this.Client.SubscriptionId cannot be null.
get-azvm : 'this.Client.SubscriptionId' cannot be null. At line:5 char:1 + get-azvm + ~~~~~~~~ + CategoryInfo : CloseError: (:) [Get-AzVM], ValidationException + FullyQualifiedErrorId : Microsoft.Azure.Commands.Compute.GetAzureVMCommand
Orsak
Detta kan inträffa när den hanterade identiteten (eller något annat konto som används i runbooken) inte har beviljats några behörigheter för att komma åt prenumerationen.
Åtgärd
Ge den hanterade identiteten (eller annat konto som används i runbooken) ett lämpligt rollmedlemskap i prenumerationen. Läs mer
Scenario: Blockerad åtkomst till Azure Storage, Azure Key Vault eller Azure SQL
I det här scenariot används Azure Storage som exempel. Informationen är dock lika tillämplig för Azure Key Vault och Azure SQL.
Problem
Försök att komma åt Azure Storage från en Runbook resulterar i ett fel som liknar följande meddelande: The remote server returned an error: (403) Forbidden. HTTP Status Code: 403 - HTTP Error Message: This request is not authorized to perform this operation.
Orsak
Azure Firewall på Azure Storage är aktiverat.
Åtgärd
Om du aktiverar Azure Firewall i Azure Storage, Azure Key Vault eller Azure SQL blockeras åtkomst från Azure Automation-runbooks för dessa tjänster. Åtkomst blockeras även när brandväggsfelet för att tillåta betrodda Microsoft-tjänster är aktiverat, eftersom Automation inte ingår i listan över betrodda tjänster. Med en aktiverad brandvägg kan åtkomst endast göras med hjälp av en Hybrid Runbook Worker och en tjänstslutpunkt för virtuellt nätverk.
Scenario: Runbook misslyckas med felet Ingen behörighet eller 403 Tillåts inte
Problem
Din runbook misslyckas med felet Ingen behörighet eller Förbjuden 403 eller motsvarande.
Orsak
Kör som-konton kanske inte har samma behörigheter mot Azure-resurser som ditt aktuella Automation-konto.
Åtgärd
Se till att kör som-kontot har behörighet att komma åt alla resurser som används i skriptet.
Scenario: Inloggningen till Azure-kontot misslyckades
Problem
Du får något av följande fel när du arbetar med cmdleten Connect-AzAccount
:
Unknown_user_type: Unknown User Type
No certificate was found in the certificate store with thumbprint
Orsak
De här felen uppstår om namnet på autentiseringsuppgiftstillgången inte är giltigt. De kan också inträffa om du inte använde ett giltigt användarnamn och lösenord för att konfigurera Automation-autentiseringstillgången.
Åtgärd
Följ dessa steg för att avgöra vad som är fel:
Kontrollera att du inte har några specialtecken. Dessa tecken innehåller tecknet
\@
i namnet för autentiseringsuppgiftens tillgång i Automation som du använder för att ansluta till Azure.Kontrollera om du kan använda användarnamnet och lösenordet som lagras i Azure Automation autentiseringsuppgifter i din lokala PowerShell ISE-redigerare. Kör följande cmdletar i PowerShell ISE.
$Cred = Get-Credential #Using Azure Service Management Add-AzureAccount -Credential $Cred #Using Azure Resource Manager Connect-AzAccount -Credential $Cred
Om autentiseringen misslyckas lokalt har du inte konfigurerat dina Microsoft Entra-autentiseringsuppgifter korrekt. Information om hur du konfigurerar Microsoft Entra-kontot på rätt sätt finns i artikeln Autentisera till Azure med hjälp av Microsoft Entra ID.
Om felet verkar vara tillfälligt kan du prova att lägga till logik för omprövning i din autentiseringsrutin för att göra autentiseringen mer robust.
$logonAttempt = 0 $logonResult = $False while(!($connectionResult) -And ($logonAttempt -le 10)) { $LogonAttempt++ #Logging in to Azure... $connectionResult = Connect-AzAccount ` Start-Sleep -Seconds 30 if($connectionResult) { $logonResult = $True } }
Scenario: Kör Login-AzureRmAccount för att logga in
Problem
Du får följande fel när du kör en runbook:
Run Login-AzureRMAccount to login.
Orsak
Det här felet kan inträffa när du inte använder ett Kör som-konto eller om Kör som-kontot har upphört att gälla.
Det finns två primära orsaker till det här problemet:
- AzureRM- och Az-modulen har olika versioner.
- Du försöker komma åt resurser i en separat prenumeration.
Åtgärd
Om du får det här felet när du har uppdaterat en AzureRM- eller Az-modul uppdaterar du alla moduler till samma version.
Om du försöker komma åt resurser i en annan prenumeration följer du de här stegen för att konfigurera behörigheter:
Gå till Automation Kör som-kontot och kopiera program-ID och tumavtryck.
Gå till prenumerationens åtkomstkontroll där Automation-kontot inte finns och lägg till en ny rolltilldelning.
Lägg till program-ID som samlats in tidigare. Välj Deltagarbehörigheter .
Kopiera namnet på prenumerationen.
Du kan nu använda följande runbook-kod för att testa behörigheterna från ditt Automation-konto till den andra prenumerationen. Ersätt
<CertificateThumbprint>
med värdet som kopieras i steg 1. Ersätt"<SubscriptionName>"
med värdet som kopieras i steg 4.$Conn = Get-AutomationConnection -Name AzureRunAsConnection Connect-AzAccount -ServicePrincipal -Tenant $Conn.TenantID -ApplicationId $Conn.ApplicationID -CertificateThumbprint "<CertificateThumbprint>" #Select the subscription you want to work with Select-AzSubscription -SubscriptionName '<YourSubscriptionNameGoesHere>' #Test and get outputs of the subscriptions you granted access. $subscriptions = Get-AzSubscription foreach($subscription in $subscriptions) { Set-AzContext $subscription Write-Output $subscription.Name }
Scenario: Det gick inte att hitta Azure-prenumerationen
Problem
Du får följande fel när du arbetar med cmdleten Select-AzureSubscription
, Select-AzureRMSubscription
eller Select-AzSubscription
:
The subscription named <subscription name> cannot be found.
Fel
Det här felet kan inträffa om:
- Prenumerationsnamnet är inte giltigt.
- Den Microsoft Entra-användare som försöker hämta prenumerationsinformationen har inte konfigurerats som administratör för prenumerationen.
- Cmdleten är inte tillgänglig.
- Kontextväxling har inträffat.
Åtgärd
Sammanhangsväxling finns i Kontextväxling i Azure Automation.
Scenario: Runbooks misslyckas när du hanterar flera prenumerationer
Problem
När du kör runbooks kan runbooken inte hantera Azure-resurser.
Orsak
Runbooken använder inte rätt kontext när den körs. Det kan bero på att runbooken av misstag försöker komma åt den felaktiga prenumerationen.
Du kan se fel som den här:
Get-AzVM : The client '<client-id>' with object id '<object-id> does not have authorization to perform action 'Microsoft.Compute/virtualMachines/read' over scope '/subscriptions/<subcriptionIdOfSubscriptionWichDoesntContainTheVM>/resourceGroups/REsourceGroupName/providers/Microsoft.Compute/virtualMachines/VMName '.
ErrorCode: AuthorizationFailed
StatusCode: 403
ReasonPhrase: Forbidden Operation
ID : <AGuidRepresentingTheOperation> At line:51 char:7 + $vm = Get-AzVM -ResourceGroupName $ResourceGroupName -Name $UNBV... +
eller så här:
Get-AzureRmResource : Resource group "SomeResourceGroupName" could not be found.
... resources = Get-AzResource -ResourceGroupName $group.ResourceGro ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (:) [Get-AzResource], CloudException
+ FullyQualifiedErrorId : Microsoft.Azure.Commands.ResourceManager.Cmdlets.Implementation.GetAzureResourceCmdlet
Åtgärd
Information om hur du undviker att oavsiktligt försöka komma åt den felaktiga prenumerationen finns i Kontextväxling i Azure Automation.
Scenario: Autentisering till Azure misslyckas eftersom multifaktorautentisering är aktiverat
Problem
Du får följande fel när du autentiserar till Azure med ditt Användarnamn och lösenord för Azure:
Add-AzureAccount: AADSTS50079: Strong authentication enrollment (proof-up) is required
Orsak
Om du har multifaktorautentisering på ditt Azure-konto kan du inte använda en Microsoft Entra-användare för att autentisera till Azure. Då behöver du i stället använda ett certifikat eller ett huvudnamn för tjänsten för autentiseringen.
Åtgärd
Information om hur du använder tjänstens huvudnamn med Azure Resource Manager-cmdletar finns i Skapa tjänstens huvudnamn med Hjälp av Azure-portalen och Autentisera ett huvudnamn för tjänsten med Azure Resource Manager.
Scenario: Runbook misslyckas med felmeddelandet "En aktivitet avbröts"
Problem
Din runbook misslyckas med ett fel som liknar följande exempel:
Exception: A task was cancelled.
Orsak
Det här felet kan orsakas av inaktuella Azure-moduler.
Åtgärd
Du kan lösa det här felet genom att uppdatera dina Azure-moduler till den senaste versionen:
- I ditt Automation-konto väljer du Moduler och sedan Uppdatera Azure-moduler.
- Uppdateringen tar ungefär 15 minuter. När det är klart kör du runbooken som misslyckades igen.
Mer information om hur du uppdaterar dina moduler finns i Uppdatera Azure-moduler i Azure Automation.
Scenario: Termen känns inte igen som namnet på en cmdlet, funktion eller ett skript
Problem
Din runbook misslyckas med ett fel som liknar följande exempel:
The term 'Connect-AzAccount' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if the path was included verify that the path is correct and try again.
Orsak
Det kan bero på följande:
- Modulen som innehåller cmdleten importeras inte till Automation-kontot.
- Modulen som innehåller cmdleten importeras men är inaktuell.
Åtgärd
Utför någon av följande uppgifter för att lösa det här felet:
- En Azure-modul finns i Så här uppdaterar du Azure PowerShell- moduler i Azure Automation för att lära dig hur du uppdaterar dina moduler i ditt Automation-konto.
- För en icke-Azure-modul kontrollerar du att modulen har importerats till ditt Automation-konto.
Scenario: Cmdleten misslyckas i PnP PowerShell-runbooken i Azure Automation
Problem
När en runbook skriver ett PnP PowerShell-genererat objekt till Azure Automation-utdata direkt kan cmdlet-utdata inte strömmas tillbaka till Automation.
Orsak
Det här problemet uppstår oftast när Azure Automation bearbetar runbooks som anropar PnP PowerShell-cmdletar, add-pnplistitem
till exempel , utan att fånga returobjekten.
Åtgärd
Redigera skripten för att tilldela eventuella returvärden till variabler så att cmdletarna inte försöker skriva hela objekt till standardutdata. Ett skript kan omdirigera utdataströmmen till en cmdlet, som du ser här.
$null = add-pnplistitem
Om skriptet parsar cmdlet-utdata måste skriptet lagra utdata i en variabel och ändra variabeln i stället för att bara strömma utdata.
$SomeVariable = add-pnplistitem ....
if ($SomeVariable.someproperty -eq ....
Scenario: Cmdleten känns inte igen när en runbook körs
Problem
Runbookjobbet misslyckas med felet:
<cmdlet name>: The term <cmdlet name> is not recognized as the name of a cmdlet, function, script file, or operable program.
Orsak
Det här felet orsakas när PowerShell-motorn inte hittar den cmdlet som du använder i din runbook. Det är möjligt att modulen som innehåller cmdleten saknas i kontot, att det finns en namnkonflikt med ett runbook-namn eller att cmdleten också finns i en annan modul och att namnet inte kan matchas i Automation.
Åtgärd
Använd någon av följande lösningar för att åtgärda problemet:
- Kontrollera att du har angett cmdlet-namnet korrekt.
- Se till att cmdleten finns i ditt Automation-konto och att det inte finns några konflikter. Om du vill kontrollera om cmdleten finns öppnar du en runbook i redigeringsläge och söker efter den cmdlet som du vill hitta i biblioteket eller kör
Get-Command <CommandName>
. När du har verifierat att cmdleten är tillgänglig för kontot och att det inte finns några namnkonflikter med andra cmdletar eller runbookflöden, lägger du till cmdleten på arbetsytan. Se till att du använder en giltig parameteruppsättning i din runbook. - Om det finns en namnkonflikt och cmdleten är tillgänglig i två olika moduler, kan du lösa problemet genom att använda det fullständigt kvalificerade namnet för cmdleten. Du kan till exempel använda
ModuleName\CmdletName
. - Om du kör runbooken lokalt i en hybridarbetsgrupp kontrollerar du att modulen och cmdleten är installerade på den dator som är värd för hybridarbetaren.
Scenario: Felaktig objektreferens vid anrop till Add-AzAccount
Problem
Du får det här felet när du arbetar med Add-AzAccount
, vilket är ett alias för cmdleten Connect-AzAccount
:
Add-AzAccount : Object reference not set to an instance of an object
Orsak
Det här felet kan inträffa om runbooken inte utför rätt steg innan du anropar Add-AzAccount
för att lägga till Automation-kontot. Ett exempel på ett av de nödvändiga stegen är att logga in med ett Kör som-konto. Rätt åtgärder som ska användas i din runbook finns i Runbook-körning i Azure Automation.
Scenario: Objektreferensen är inte en instans av ett objekt
Problem
Du får följande fel när du anropar en underordnad runbook med parametern Wait
och utdataströmmen innehåller ett objekt:
Object reference not set to an instance of an object
Orsak
Om strömmen innehåller objekt hanterar Start-AzAutomationRunbook
den inte utdataströmmen korrekt.
Åtgärd
Implementera en avsökningslogik och använd cmdleten Get-AzAutomationJobOutput för att hämta utdata. Ett exempel på den här logiken definieras här:
$AutomationAccountName = "ContosoAutomationAccount"
$RunbookName = "ChildRunbookExample"
$ResourceGroupName = "ContosoRG"
function IsJobTerminalState([string]$Status) {
$TerminalStates = @("Completed", "Failed", "Stopped", "Suspended")
return $Status -in $TerminalStates
}
$StartAzAutomationRunbookParameters = @{
Name = $RunbookName
AutomationAccountName = $AutomationAccountName
ResourceGroupName = $ResourceGroupName
}
$Job = Start-AzAutomationRunbook @StartAzAutomationRunBookParameters
$PollingSeconds = 5
$MaxTimeout = New-TimeSpan -Hours 3 | Select-Object -ExpandProperty TotalSeconds
$WaitTime = 0
while(-NOT (IsJobTerminalState $Job.Status) -and $WaitTime -lt $MaxTimeout) {
Start-Sleep -Seconds $PollingSeconds
$WaitTime += $PollingSeconds
$Job = $Job | Get-AzAutomationJob
}
$Job | Get-AzAutomationJobOutput | Get-AzAutomationJobOutputRecord | Select-Object -ExpandProperty Value
Scenario: Runbook misslyckas på grund av deserialiserat objekt
Problem
Runbooken misslyckas med felet:
Cannot bind parameter <ParameterName>.
Cannot convert the <ParameterType> value of type Deserialized <ParameterType> to type <ParameterType>.
Orsak
Om din runbook är ett PowerShell-arbetsflöde lagrar den komplexa objekt i ett deserialiserat format för att bevara runbook-tillståndet om arbetsflödet pausas.
Åtgärd
Använd någon av följande lösningar för att åtgärda problemet:
- Om du skickar vidare komplexa objekt från en cmdlet till en annan i pipeline omsluter du dessa cmdletar i en
InlineScript
-aktivitet. - Skicka det namn eller värde som du behöver från det komplexa objektet i stället för att skicka hela objektet.
- Använd en PowerShell-runbook i stället för en PowerShell Workflow-runbook.
Scenario: Status 400 för felaktig begäran vid anrop av en webhook
Problem
När du försöker anropa en webhook för en Azure Automation-runbook får du följande fel:
400 Bad Request : This webhook has expired or is disabled
Orsak
Den webhook som du försöker anropa är antingen inaktiverad eller har upphört att gälla.
Åtgärd
Om webhooken är inaktiv kan du återaktivera den via Azure-portalen. Om webhooken har upphört att gälla måste du ta bort och sedan skapa den igen. Du kan bara förnya en webhook om den inte redan har upphört att gälla.
Scenario: 429: Begärandefrekvensen är för närvarande för hög
Problem
Du får följande felmeddelande när du kör cmdleten Get-AzAutomationJobOutput
:
429: The request rate is currently too large. Please try again
Orsak
Det här felet kan inträffa när jobbutdata hämtas från en runbook som har många utförliga strömmar.
Åtgärd
Lös det här felet genom att göra något av följande:
- Redigera runbooken och minska antalet jobbströmmar som den genererar.
- Minska antalet strömmar som ska hämtas när du kör cmdleten. För att göra detta kan du ange värdet för parametern
Stream
för cmdleten Get-AzAutomationJobOutput för att endast hämta utdataströmmar.
Scenario: Runbook-jobbet misslyckas eftersom den allokerade kvoten överskreds
Problem
Runbookjobbet misslyckas med felet:
The quota for the monthly total job run time has been reached for this subscription
Orsak
Det här felet uppstår när jobbkörningen överskrider den kostnadsfria kvoten på 500 minuter för ditt konto. Den här kvoten gäller för alla typer av jobbkörningsaktiviteter. Vissa av dessa uppgifter testar ett jobb, startar ett jobb från portalen, kör ett jobb med hjälp av webhooks eller schemalägger ett jobb som ska köras med antingen Azure-portalen eller ditt datacenter. Mer information om priser för Automation finns i Prissättning för Automation.
Åtgärd
Om du vill använda mer än 500 minuters bearbetning per månad ändrar du din prenumeration från den kostnadsfria nivån till Basic-nivån:
- Logga in på din Azure-prenumeration.
- Välj det Automation-konto som ska uppgraderas.
- Välj Inställningar och sedan Prissättning.
- Välj Aktivera på sidan längst ned för att uppgradera ditt konto till Basic-nivån.
Scenario: Runbook-utdataström som är större än 1 MB
Problem
Din runbook som körs i Azure-sandbox-miljön misslyckas med följande fel:
The runbook job failed due to a job stream being larger than 1MB, this is the limit supported by an Azure Automation sandbox.
Orsak
Det här felet beror på att runbooken försökte skriva för mycket undantagsdata till utdataströmmen.
Åtgärd
Det finns en gräns på 1 MB för jobbutdataströmmen. Se till att din runbook omsluter anrop till en körbar eller underprocess med hjälp try
av och catch
block. Om åtgärderna utlöser ett undantag måste koden skriva meddelandet från undantaget till en Automation-variabel. Den här tekniken förhindrar att meddelandet skrivs till jobbutdataströmmen. För Hybrid Runbook Worker-jobb som körs visas utdataströmmen trunkerad till 1 MB utan felmeddelande.
Scenario: Runbooken försökte starta jobbet tre gånger, men misslyckades varje gång
Problem
Din runbook misslyckas med följande fel:
The job was tried three times but it failed
Orsak
Det här felet uppstår på grund av någon av följande orsaker:
Minnesgräns. Ett jobb kan misslyckas om det använder mer än 400 MB minne. De dokumenterade gränserna för minne som allokerats till en sandbox-miljö finns i Gränser för Automation-tjänsten.
Nätverksuttag. Azure-sandbox-miljön är begränsad till 1 000 samtidiga nätverksuttag. Mer information finns i Gränser för Automation-tjänsten.
Modulen är inte kompatibel. Modulberoenden kanske inte är korrekta. I det här fallet returnerar din runbook vanligtvis ett
Command not found
ellerCannot bind parameter
ett meddelande.Ingen autentisering med Active Directory för sandbox-miljön. Din runbook försökte anropa en körbar eller underprocess som körs i en Azure-sandbox-miljö. Det går inte att konfigurera runbooks för att autentisera med Microsoft Entra-ID med hjälp av Azure Active Directory Authentication Library (ADAL).
Åtgärd
Minnesgräns, nätverksuttag. Föreslagna sätt att arbeta inom minnesgränserna är att dela upp arbetsbelastningen mellan flera runbooks, bearbeta mindre data i minnet, undvika att skriva onödiga utdata från dina runbooks och överväga hur många kontrollpunkter som skrivs till dina PowerShell-arbetsflödesrunbooks. Använd clear-metoden, till exempel
$myVar.clear
, för att rensa variabler och använda[GC]::Collect
för att köra skräpinsamling omedelbart. Dessa åtgärder minskar minnesfotavtrycket för din runbook under körningen.Modulen är inte kompatibel. Uppdatera dina Azure-moduler genom att följa stegen i Så här uppdaterar du Azure PowerShell-moduler i Azure Automation.
Ingen autentisering med Active Directory för sandbox-miljön. När du autentiserar dig för Microsoft Entra ID med en runbook ska du kontrollera att Azure AD-modulen är tillgänglig i ditt Automation-konto. Se till att ge Kör som-kontot de behörigheter som krävs för att utföra de uppgifter som runbooken automatiserar.
Om din runbook inte kan anropa en körbar eller underprocess som körs i en Azure-sandbox-miljö använder du runbooken på en Hybrid Runbook Worker. Hybridarbetare begränsas inte av de minnes- och nätverksgränser som Azure-sandbox-miljöerna har.
Scenario: PowerShell-jobbet misslyckas med felmeddelandet "Det går inte att anropa metoden"
Problem
Du får följande felmeddelande när du startar ett PowerShell-jobb i en runbook som körs i Azure:
Exception was thrown - Cannot invoke method. Method invocation is supported only on core types in this language mode.
Orsak
Det här felet kan tyda på att runbooks som körs i en Azure-sandbox-miljö inte kan köras i läget Fullständigt språk.
Åtgärd
Det finns två sätt att lösa det här felet:
- I stället för att använda Start-Job använder du Start-AzAutomationRunbook för att starta runbooken.
- Prova att köra runbooken på en Hybrid Runbook Worker.
Mer information om det här beteendet och andra beteenden i Azure Automation-runbooks finns i Runbook-körning i Azure Automation.
Scenario: En tidskrävande runbook kan inte slutföras
Problem
Din runbook visas i tillståndet Stoppad efter att ha körts i tre timmar. Du kan också få det här felet:
The job was evicted and subsequently reached a Stopped state. The job cannot continue running.
Det här beteendet är avsiktligt i Azure-sandbox-miljö på grund av rättvis delningsövervakning av processer i Azure Automation. Om en process körs längre än tre timmar stoppas en runbook automatiskt av rättvis resurs. Statusen för en runbook som överskrider tidsgränsen för rättvis resurs skiljer sig åt efter runbook-typ. PowerShell- och Python-runbooks är inställda på statusen Stoppad. PowerShell-arbetsflödesrunbooks är inställda på Misslyckades.
Orsak
Runbooken körde över den tretimmarsgräns som tillåts av en rättvis resurs i en Azure-sandbox-miljö.
Åtgärd
En rekommenderad lösning är att köra runbooken på en Hybrid Runbook Worker. Hybridarbetare begränsas inte av den 3-timmars fair share runbook-gräns som Azure-sandbox-miljön har. Runbooks som körs på Hybrid Runbook Workers bör utvecklas för att stödja omstartsbeteenden om det uppstår oväntade problem med lokal infrastruktur.
En annan lösning är att optimera runbooken genom att skapa underordnade runbooks. Om din runbook loopar via samma funktion på flera resurser, till exempel i en databasåtgärd på flera databaser, kan du flytta funktionen till en underordnad runbook. Varje underordnad runbook körs parallellt i en separat process. Det här beteendet minskar den totala tiden för den överordnade runbooken att slutföras.
De PowerShell-cmdletar som aktiverar det underordnade Runbook-scenariot är:
- Start-AzAutomationRunbook. Med den här cmdleten kan du starta en runbook och skicka parametrar till runbooken.
- Get-AzAutomationJob. Om det finns åtgärder som måste utföras när den underordnade runbooken har slutförts kan du med den här cmdleten kontrollera jobbstatusen för varje underordnad.
Scenario: Fel i jobbströmmar för metoden get_SerializationSettings
Problem
Du ser följande fel i dina jobbströmmar för en runbook:
Connect-AzAccount : Method 'get_SerializationSettings' in type
'Microsoft.Azure.Management.Internal.Resources.ResourceManagementClient' from assembly
'Microsoft.Azure.Commands.ResourceManager.Common, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
does not have an implementation.
At line:16 char:1
+ Connect-AzAccount -ServicePrincipal -Tenant $Conn.TenantID -Appl ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Connect-AzAccount], TypeLoadException
+ FullyQualifiedErrorId : System.TypeLoadException,Microsoft.Azure.Commands.Profile.ConnectAzAccountCommand
Orsak
Det här felet orsakas förmodligen av en ofullständig migrering från AzureRM till Az-moduler i din runbook. Den här situationen kan leda till att Azure Automation startar ett runbook-jobb genom att endast använda AzureRM-moduler och sedan starta ett annat jobb med hjälp av endast Az-moduler, vilket leder till en sandbox-krasch.
Åtgärd
Vi rekommenderar inte användning av Az- och AzureRM-cmdletar i samma runbook. Mer information om korrekt användning av modulerna finns i Migrera till Az-moduler.
Scenario: Åtkomst nekad när azure-sandbox-miljön används för runbook eller program
Problem
När din runbook eller ditt program försöker köras i en Azure-sandbox-miljö nekar miljön åtkomst.
Orsak
Det här problemet kan inträffa eftersom Azure-sandbox-miljöer förhindrar åtkomst till alla COM-servrar som inte är i process. Ett begränsat program eller en runbook kan till exempel inte anropa till Windows Management Instrumentation (WMI) eller till Windows Installer-tjänsten (msiserver.exe).
Åtgärd
Mer information om hur du använder Azure-sandbox-miljöer finns i Runbook-körningsmiljön.
Scenario: Ogiltig statuskod för förbjuden när du använder Key Vault i en runbook
Problem
När du försöker komma åt Azure Key Vault via en Azure Automation-runbook får du följande fel:
Operation returned an invalid status code 'Forbidden'
Orsak
Möjliga orsaker till det här problemet är:
- Använder inte ett Kör som-konto.
- Otillräckliga behörigheter.
Åtgärd
Inte använda ett Kör som-konto
Följ steg 5 – Lägg till autentisering för att hantera Azure-resurser för att säkerställa att du använder ett Kör som-konto för att få åtkomst till Key Vault.
Otillräckliga behörigheter
Lägg till behörigheter i Key Vault för att säkerställa att kör som-kontot har tillräcklig behörighet för att få åtkomst till Key Vault.
Scenario: Runbook kan inte köras. Följande fel visas: Parameterlängden har överskridits
Problem
Runbooken använder parametrar och kan inte köras. Följande fel visas:
Total Length of Runbook Parameter names and values exceeds the limit of 30,000 characters. To avoid this issue, use Automation Variables to pass values to runbook.
Orsak
Det finns en gräns för den totala längden på tecken för alla parametrar som kan anges i Python 2.7, Python 3.8 och PowerShell 7.1-runbooks. Den totala längden på alla parameternamn och parametervärden får inte överstiga 30 000 tecken.
Åtgärd
För att lösa det här problemet kan du använda Azure Automation-variabler för att skicka värden till runbook. Du kan också minska antalet tecken i Parameternamn och Parametervärden så att den totala längden inte överskrider 30 000 tecken.
Rekommenderade dokument
Nästa steg
Om du inte ser problemet här eller om du inte kan lösa problemet kan du prova någon av följande kanaler för mer support:
- Få svar från Azure-experter via Azure-forum.
- Anslut med @AzureSupport, det officiella Microsoft Azure-kontot för att förbättra kundupplevelsen. Azure Support ansluter dig till Azure-communityn för svar, support och experter.
- Om du behöver mer hjälp kan du skapa en Azure-supportincident. Gå till Azure-supportwebbplatsen och välj Hämta support.