Azure Automation-runbooktyper

Funktionen Azure Automation Process Automation stöder flera typer av runbooks enligt definitionen i följande tabell. Mer information om processautomatiseringsmiljön finns i Runbook-körning i Azure Automation.

Typ	Beskrivning
PowerShell	Text runbook baserat på Windows PowerShell-skript. De versioner som stöds för närvarande är: PowerShell 7.2 (GA) och PowerShell 5.1 (GA). Eftersom PowerShell 7.1 inte längre stöds av den överordnade produkten PowerShell rekommenderar vi att du skapar runbooks i den version av PowerShell 7.2 som stöds på lång sikt
PowerShell-arbetsflöde	Text runbook baserat på Skript för Windows PowerShell-arbetsflöde.
Python	Text runbook baserat på Python-skript. De versioner som stöds för närvarande är: Python 3.8 (GA) och Python 3.10 (förhandsversion). Eftersom Python 2.7 inte längre stöds av den överordnade produkten Python rekommenderar vi att du skapar runbooks i versioner som stöds på lång sikt.
Grafisk	Grafisk runbook baserad på Windows PowerShell och skapad och redigerad helt i den grafiska redigeraren i Azure-portalen.
Grafiskt PowerShell-arbetsflöde	Grafisk runbook baserad på Windows PowerShell-arbetsflöde och skapad och redigerad helt i den grafiska redigeraren i Azure-portalen.

Kommentar

Azure Automation följer supportlivscykeln för PowerShell- och Python-språkversioner i enlighet med tidslinjerna som publicerats av de överordnade produkterna PowerShellrespektive Python . Vi rekommenderar att du använder runbooks med språkversioner som stöds.

Ta hänsyn till följande när du avgör vilken typ som ska användas för en viss runbook.

• Du kan inte konvertera runbooks från grafisk till texttyp eller tvärtom.
• Det finns begränsningar när du använder runbooks av olika typer som underordnade runbooks. Mer information finns i Underordnade runbooks i Azure Automation.

PowerShell-runbooks

PowerShell-runbooks baseras på Windows PowerShell. Du redigerar runbookens kod direkt med hjälp av textredigeraren i Azure-portalen. Du kan också använda valfri offlinetextredigerare och importera runbooken till Azure Automation.

PowerShell-versionen bestäms av den angivna Runtime-versionen (som är version 7.2, 7.1 (förhandsversion) eller 5.1).

Samma Sandbox-miljö i Azure och Hybrid Runbook Worker kan köra flera PowerShell-runbooks för olika körningsversioner sida vid sida.

Kommentar

• För närvarande stöds PowerShell 7.2-körningsversionen för både moln- och hybridjobb i alla offentliga regioner utom centrala Indien, Förenade Arabemiraten, Centrala, Israel, centrala, Italien, norra, Tyskland, norra och Gov-moln.
• Om du väljer Körningsversion som 7.2 används PowerShell-moduler som är avsedda för 7.2-körningsversion vid körning och om du väljer Körningsversion som 5.1 används PowerShell-moduler som är avsedda för 5.1-körningsversion. Detta gäller för PowerShell 7.1-moduler (förhandsversion) och runbooks.

Se till att du väljer rätt Körningsversion för moduler.

Om du till exempel kör en runbook för ett SharePoint-automatiseringsscenario i Runtime version7.1 (förhandsversion), importerar du modulen i Runtime version7.1 (förhandsversion); om du kör en runbook för ett SharePoint-automatiseringsscenario i Körningsversion5.1 importerar du modulen i Körningsversion5.1. I det här fallet skulle du se två poster för modulen, en för Runtime Version7.1(förhandsversion) och en annan för 5.1.

Kommentar

För närvarande stöds PowerShell 5.1, PowerShell 7.1 (förhandsversion) och PowerShell 7.2.

Fördelar

• Implementera all komplex logik med PowerShell-kod utan andra komplexiteter i PowerShell-arbetsflödet.
• Starta snabbare än PowerShell-arbetsflödesrunbooks eftersom de inte behöver kompileras innan de körs.
• Kör i Azure och på Hybrid Runbook Workers för både Windows och Linux.

Begränsningar och kända problem

Följande är de aktuella begränsningarna och kända problem med PowerShell-runbooks:

PowerShell 7.2

Begränsningar

Kommentar

För närvarande stöds PowerShell 7.2-körningsversionen för både moln- och hybridjobb i alla offentliga regioner utom centrala Indien, Förenade Arabemiraten, Centrala, Israel, centrala, Italien, norra, Tyskland, norra och Gov-moln.

• För PowerShell 7.2-körningsversionen extraheras inte modulaktiviteterna för de importerade modulerna. Använd Azure Automation-tillägget för VS-kod för att förenkla körningen av runbook-redigering.
• PowerShell 7.x stöder inte arbetsflöden. Mer information finns i PowerShell-arbetsflödet för mer information.
• PowerShell 7.x stöder för närvarande inte signerade runbooks.
• Källkontrollintegrering stöder inte PowerShell 7.2. Dessutom skapas PowerShell 7.2-runbooks i källkontrollen i Automation-kontot som Runtime 5.1.
• Az-modulen 8.3.0 är installerad som standard. Den fullständiga listan över komponentmoduler i den valda Az-modulversionen visas när Az-versionen har konfigurerats igen med hjälp av Azure-portalen eller API:et.
• Den importerade PowerShell 7.2-modulen verifieras under jobbkörningen. Kontrollera att alla beroenden för den valda modulen också importeras för lyckad jobbkörning.
• Azure Runbook stöder Start-Job inte med -credential.
• Azure stöder inte alla PowerShell-indataparametrar. Läs mer.

Kända problem

• Runbooks som är beroende av interna filsökvägar, till exempel C:\modules kan misslyckas på grund av ändringar i tjänstens serverdelsinfrastruktur. Ändra runbook-kod för att säkerställa att det inte finns några beroenden för interna filsökvägar och använd Get-ChildItem för att hämta nödvändig modulinformation.

• Get-AzStorageAccount cmdleten kan misslyckas med ett fel: Kommandot Get-AzStorageAccount hittades i modulen Az.Storage, men modulen kunde inte läsas in.

• Det går inte att köra underordnade skript med hjälp av.\child-runbook.ps1.
  Lösning: Använd Start-AutomationRunbook (intern cmdlet) eller Start-AzAutomationRunbook (från Az.Automation-modulen) för att starta en annan runbook från den överordnade runbooken.

• När du använder ExchangeOnlineManagement-modulversion : 3.0.0 eller senare kan det uppstå fel. Lös problemet genom att se till att du uttryckligen laddar upp PowerShellGet - och PackageManagement-moduler .

• När du använder cmdleten New-AzAutomationVariable i Az.Automation-modulen för att ladda upp en variabel av typen objekt fungerar inte åtgärden som förväntat.

  Lösning: Konvertera objektet till en JSON-sträng med hjälp av cmdleten ConvertTo-Json och ladda sedan upp variabeln med JSON-strängen som dess värde. Den här lösningen säkerställer korrekt hantering av variabeln i Azure Automation-miljön som en JSON-sträng.

  Exempel – Skapa ett PowerShell-objekt som har lagrad information runt virtuella Azure-datorer

    # Retrieve Azure virtual machines with status information for the 'northeurope' region 
    $AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"} 
  
    $VMstopatch = @($AzVM).Id 
    # Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch 
  
    # Convert the object to a JSON string 
    $jsonString = $VMstopatch | ConvertTo-Json 
  
    # Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString 
  

PowerShell 5.1

Begränsningar

• Runbooks kan inte använda parallell bearbetning för att köra flera åtgärder parallellt.
• Runbooks kan inte använda kontrollpunkter för att återuppta runbooken om det uppstår ett fel.
• Du kan bara inkludera PowerShell, PowerShell Workflow-runbooks och grafiska runbooks som underordnade runbooks med hjälp av cmdleten Start-AzAutomationRunbook , som skapar ett nytt jobb.
• Runbooks kan inte använda PowerShell -#Requires-instruktionen , den stöds inte i Azure-sandbox-miljön eller i Hybrid Runbook Workers och kan leda till att jobbet misslyckas.
• Azure Runbook stöder Start-Job inte med -credential.
• Azure stöder inte alla PowerShell-indataparametrar. Läs mer.

Kända problem

• Runbooks som är beroende av interna filsökvägar, till exempel C:\modules kan misslyckas på grund av ändringar i tjänstens serverdelsinfrastruktur. Ändra runbook-kod för att säkerställa att det inte finns några beroenden för interna filsökvägar och använd Get-ChildItem för att hämta nödvändig modulinformation.

  Exempelskript

  
  # Get information about module "Microsoft.Graph.Authentication"
  $ModuleName = "Microsoft.Graph.Authentication"
  
  $NewPath = "C:\usr\src\PSModules\$ModuleName"
  $OldPath = "C:\Modules\User\$ModuleName"
  
  if (Test-Path -Path $NewPath -PathType Container) {
      Get-ChildItem -Path $NewPath
  } elseif (Test-Path -Path $OldPath -PathType Container) {
      Get-ChildItem -Path $OldPath
  } else {
      Write-Output "Module $ModuleName not present."
  }
  # Getting the path to the Temp folder, if needed.
  $tmp = $env:TEMP
  
  

• Get-AzStorageAccount cmdleten kan misslyckas med ett fel: Kommandot Get-AzStorageAccount hittades i modulen Az.Storage, men modulen kunde inte läsas in.

• PowerShell-runbooks kan inte hämta en okrypterad variabeltillgång med ett null-värde.

• PowerShell-runbooks kan inte hämta en variabeltillgång med *~* i namnet.

• En Get-Process-åtgärd i en loop i en PowerShell-runbook kan krascha efter cirka 80 iterationer.

• En PowerShell-runbook kan misslyckas om den försöker skriva en stor mängd data till utdataströmmen samtidigt. Du kan vanligtvis kringgå det här problemet genom att se till att din runbook bara matar ut data för den information som behövs för att arbeta med stora objekt. I stället för att använda Get-Process utan begränsningar kan du till exempel ha cmdlet-utdata bara de obligatoriska parametrarna som i Get-Process | Select ProcessName, CPU.

• När du använder ExchangeOnlineManagement-modulversion : 3.0.0 eller senare kan det uppstå fel. Lös problemet genom att se till att du uttryckligen laddar upp PowerShellGet - och PackageManagement-moduler .

• Om du importerar modulen Az.Accounts med version 2.12.3 eller senare kontrollerar du att du importerar Modulen Newtonsoft.Json v10 explicit om PowerShell 5.1-runbooks har ett beroende av den här versionen av modulen. Lösningen på det här problemet är att använda PowerShell 7.2-runbooks.

• När du använder cmdleten New-AzAutomationVariable i Az.Automation-modulen för att ladda upp en variabel av typen objekt fungerar inte åtgärden som förväntat.

  Lösning: Konvertera objektet till en JSON-sträng med hjälp av cmdleten ConvertTo-Json och ladda sedan upp variabeln med JSON-strängen som dess värde. Den här lösningen säkerställer korrekt hantering av variabeln i Azure Automation-miljön som en JSON-sträng.

  Exempel – Skapa ett PowerShell-objekt som har lagrad information runt virtuella Azure-datorer

    # Retrieve Azure virtual machines with status information for the 'northeurope' region 
    $AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"} 
  
    $VMstopatch = @($AzVM).Id 
    # Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch 
  
    # Convert the object to a JSON string 
    $jsonString = $VMstopatch | ConvertTo-Json 
  
    # Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString 
  

PowerShell 7.1

Begränsningar

• PowerShell 7.1 stöds inte längre av den överordnade produkten PowerShell. Vi rekommenderar att du skapar nya runbooks i PowerShell 7.2 för långsiktig support och uppdaterar inaktuella runbooks.
• De interna PowerShell-cmdletarna i Azure Automation stöds inte i en Linux Hybrid Runbook Worker. Du måste importera modulen automationassets i början av PowerShell-runbooken för att få åtkomst till funktionerna för delade resurser (tillgångar) för Automation-kontot.
• För PowerShell 7-körningsversionen extraheras inte modulaktiviteterna för de importerade modulerna.
• Parametertypen PSCredential runbook stöds inte i PowerShell 7-körningsversionen.
• PowerShell 7.x stöder inte arbetsflöden. Mer information finns i PowerShell-arbetsflödet för mer information.
• PowerShell 7.x stöder för närvarande inte signerade runbooks.
• Källkontrollintegrering stöder inte PowerShell 7.1 (förhandsversion) Dessutom skapas PowerShell 7.1-runbooks (förhandsversion) i källkontrollen i Automation-kontot som Runtime 5.1.
• PowerShell 7.1-modulhantering stöds inte via Get-AzAutomationModule-cmdletar.
• Runbook misslyckas utan loggspårning om indatavärdet innehåller tecknet .
• Azure Runbook stöder Start-Job inte med -credential.
• Azure stöder inte alla PowerShell-indataparametrar. Läs mer.

Kända problem

• Runbooks som är beroende av interna filsökvägar, till exempel C:\modules kan misslyckas på grund av ändringar i tjänstens serverdelsinfrastruktur. Ändra runbook-kod för att säkerställa att det inte finns några beroenden för interna filsökvägar och använd Get-ChildItem för att hämta nödvändig modulinformation.

  Exempelskript

  
  # Get information about module "Microsoft.Graph.Authentication"
  $ModuleName = "Microsoft.Graph.Authentication"
  
  $NewPath = "C:\usr\src\PSModules\$ModuleName"
  $OldPath = "C:\Modules\User\$ModuleName"
  
  if (Test-Path -Path $NewPath -PathType Container) {
      Get-ChildItem -Path $NewPath
  } elseif (Test-Path -Path $OldPath -PathType Container) {
      Get-ChildItem -Path $OldPath
  } else {
      Write-Output "Module $ModuleName not present."
  }
  # Getting the path to the Temp folder, if needed.
  $tmp = $env:TEMP
  
  

• Get-AzStorageAccount cmdleten kan misslyckas med ett fel: Kommandot Get-AzStorageAccount hittades i modulen Az.Storage, men modulen kunde inte läsas in.

• Körning av underordnade skript med hjälp av .\child-runbook.ps1 stöds inte i den här förhandsversionen. Lösning: Använd Start-AutomationRunbook (intern cmdlet) eller Start-AzAutomationRunbook (från Az.Automation modulen) för att starta en annan runbook från den överordnade runbooken.

• Runbook-egenskaper som definierar loggningsinställningar stöds inte i PowerShell 7-körningsversionen. Lösning: Ange uttryckligen inställningen i början av runbooken enligt följande -

      $VerbosePreference = "Continue"
  
      $ProgressPreference = "Continue"
  

• Undvik att Az.Accounts importera modulen till version 2.4.0 för PowerShell 7-körning eftersom det kan uppstå ett oväntat beteende med den här versionen i Azure Automation.

• Du kan stöta på formateringsproblem med felutdataströmmar för jobbet som körs i PowerShell 7-körning.

• När du importerar en PowerShell 7.1-modul som är beroende av andra moduler kan det hända att importknappen är grå även när PowerShell 7.1-versionen av den beroende modulen är installerad. Till exempel Az PowerShell-modulen. Beräkningsversion 4.20.0 är beroende av att Az.Accounts är >= 2.6.0. Det här problemet uppstår när en motsvarande beroende modul i PowerShell 5.1 inte uppfyller versionskraven. Till exempel var < 5.1-versionen av Az.Accounts 2.6.0.

• När du startar PowerShell 7-runbooken med webhooken konverterar den automatiskt indataparametern webhook till en ogiltig JSON.

• Vi rekommenderar att du använder ExchangeOnlineManagement-modulversion : 3.0.0 eller lägre eftersom version: 3.0.0 eller senare kan leda till jobbfel.

• Om du importerar modulen Az.Accounts med version 2.12.3 eller senare kontrollerar du att du importerar Modulen Newtonsoft.Json v10 explicit om PowerShell 7.1-runbooks har ett beroende av den här versionen av modulen. Lösningen på det här problemet är att använda PowerShell 7.2-runbooks.

• När du använder cmdleten New-AzAutomationVariable i Az.Automation-modulen för att ladda upp en variabel av typen objekt fungerar inte åtgärden som förväntat.

  Lösning: Konvertera objektet till en JSON-sträng med hjälp av cmdleten ConvertTo-Json och ladda sedan upp variabeln med JSON-strängen som dess värde. Den här lösningen säkerställer korrekt hantering av variabeln i Azure Automation-miljön som en JSON-sträng.

  Exempel – Skapa ett PowerShell-objekt som har lagrad information runt virtuella Azure-datorer

    # Retrieve Azure virtual machines with status information for the 'northeurope' region 
    $AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"} 
  
    $VMstopatch = @($AzVM).Id 
    # Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch 
  
    # Convert the object to a JSON string 
    $jsonString = $VMstopatch | ConvertTo-Json 
  
    # Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString 
  

PowerShell-arbetsflödesrunbooks

PowerShell-arbetsflödesrunbooks är läroböcker baserade på Windows PowerShell-arbetsflöde. Du redigerar runbookens kod direkt med hjälp av textredigeraren i Azure-portalen. Du kan också använda valfri offlinetextredigerare och importera runbooken till Azure Automation.

Kommentar

PowerShell 7.1 (förhandsversion) och PowerShell 7.2 stöder inte arbetsflödesrunbooks.

Fördelar

• Implementera all komplex logik med PowerShell-arbetsflödeskod.
• Använd kontrollpunkter för att återuppta åtgärden om det finns ett fel.
• Använd parallell bearbetning för att utföra flera åtgärder parallellt.
• Kan innehålla andra grafiska runbooks och PowerShell-arbetsflödesrunbooks som underordnade runbooks för att skapa arbetsflöden på hög nivå.

Begränsningar

• PowerShell-arbetsflödet stöds inte i PowerShell 7+-versioner. Därför kan inte inaktuella runbooks uppgraderas.
• Ineffektiv hantering av parallell körning jämfört med nyare PowerShell 7+-versioner.
• PowerShell-arbetsflödet fungerar internt med flera processer. Därför kanske moduler som är tillgängliga i en process inte är tillgängliga i en annan och orsakar undantag som att kommandot inte hittades.
• Runbooks måste hantera den ytterligare komplexiteten i PowerShell-arbetsflödet, till exempel deserialiserade objekt.
• Runbooks tar längre tid att starta än PowerShell-runbooks eftersom de måste kompileras innan de körs.
• Du kan bara inkludera PowerShell-runbooks som underordnade runbooks med hjälp av cmdleten Start-AzAutomationRunbook .
• Runbooks kan inte köras på en Linux Hybrid Runbook Worker.

Python-runbooks

Python-runbooks kompileras under Python 2.7(GA), Python 3.8 (GA) och Python 3.10 (förhandsversion). Du kan redigera runbookens kod direkt med hjälp av textredigeraren i Azure-portalen. Du kan också använda en offline-textredigerare och importera runbooken till Azure Automation.

För närvarande stöds Python 3.10-körningsversionen (förhandsversion) för både moln- och hybridjobb i alla offentliga regioner utom Australien, centrala2, Sydkorea, södra, Sverige, södra, Jio Indien, centrala, Brasilien, Södra Indien, centrala Indien, Indien, västra, Centrala Förenade Arabemiraten och Gov-moln.

Fördelar

Kommentar

Det kan ta flera minuter att importera ett Python-paket.

• Använder robusta Python-bibliotek.
• Kan köras i Azure eller på Hybrid Runbook Workers.
• För Python 2.7 stöds Windows Hybrid Runbook Workers med Python 2.7 installerat.
• Python 3.8-versionen stöds för Python 3.8-molnjobb. Skript och paket från valfri 3.x-version kan fungera om koden är kompatibel mellan olika versioner.
• För Python 3.8 Hybrid-jobb på Windows-datorer kan du välja att installera valfri 3.x-version som du kanske vill använda.
• För Python 3.8 Hybrid-jobb på Linux-datorer är vi beroende av python 3-versionen som är installerad på datorn för att köra DSC OMSConfig och Linux Hybrid Worker. Olika versioner bör fungera om det inte finns några icke-bakåtkompatibla ändringar i metodsignaturer eller kontrakt mellan versioner av Python 3.

Begränsningar

Följande är begränsningarna i Python-runbooks

Python 3.10 (förhandsversion)

• För Python 3.10-moduler (förhandsversion) stöds för närvarande endast hjulfilerna som riktar sig mot cp310 Linux OS. Läs mer
• Källkontrollintegrering stöds inte.
• Anpassade paket för Python 3.10 (förhandsversion) verifieras endast under jobbkörningen. Jobbet förväntas misslyckas om paketet inte är kompatibelt under körningen eller om nödvändiga beroenden för paket inte importeras till automationskontot.
• För närvarande stöds Python 3.10-runbooks (förhandsversion) endast från Azure-portalen. Rest API och PowerShell stöds inte.

Python 3.8 (GA)

• Du måste känna till Python-skript.
• Källkontrollintegrering stöds inte.
• För Python 3.8-moduler använder du hjulfiler som riktar sig till cp38-amd64.
• Om du vill använda bibliotek från tredje part måste du importera paketen till Automation-kontot.
• Att använda Start-AutomationRunbook-cmdlet i PowerShell/PowerShell-arbetsflödet för att starta en Python 3.8-runbook fungerar inte. Du kan använda cmdleten Start-AzAutomationRunbook från Az.Automation-modulen eller cmdleten Start-AzureRmAutomationRunbook från AzureRm.Automation för att kringgå den här begränsningen. 
• Azure Automation stöder inte sys.stderr.
• Python automationassets-paketet är inte tillgängligt på pypi.org, så det är inte tillgängligt för import till en Windows-dator.

Python 2.7

• Python 2.7 stöds inte längre av den överordnade produkten Python. Vi rekommenderar att du skapar nya runbooks i de versioner som stöds och uppdaterar inaktuella runbooks.
• Du måste känna till Python-skript.
• För Python 2.7.12-moduler använder du hjulfilerna cp27-amd6.
• Om du vill använda bibliotek från tredje part måste du importera paketen till Automation-kontot.
• Azure Automation stöder inte sys.stderr.
• Python automationassets-paketet är inte tillgängligt på pypi.org, så det är inte tillgängligt för import till en Windows-dator.

Flera Python-versioner

Det gäller för Windows Hybrid-arbetare. För en Windows Runbook Worker letar den först efter miljövariabeln PYTHON_2_PATH när du kör en Python 2-runbook och kontrollerar om den pekar på en giltig körbar fil. Om installationsmappen till exempel är C:\Python2kontrollerar den om C:\Python2\python.exe det är en giltig sökväg. Om det inte hittas söker den efter miljövariabeln för PATH att göra en liknande kontroll.

För Python 3 letar den PYTHON_3_PATH först efter env-variabeln och återgår sedan till PATH miljövariabeln.

När du bara använder en version av Python kan du lägga till installationssökvägen i variabeln PATH . Om du vill använda båda versionerna i Runbook Worker anger du PYTHON_2_PATH och PYTHON_3_PATH till platsen för modulen för dessa versioner.

Kända problem

För molnjobb misslyckas Python 3.8-jobb ibland med ett undantagsmeddelande invalid interpreter executable path. Du kan se det här undantaget om jobbet är försenat, startar mer än 10 minuter eller använder Start-AutomationRunbook för att starta Python 3.8-runbooks. Om jobbet fördröjs bör det vara tillräckligt att starta om runbooken.

Grafiska runbooks

Du kan skapa och redigera grafiska och grafiska PowerShell-arbetsflödesrunbooks med hjälp av den grafiska redigeraren i Azure-portalen. Du kan dock inte skapa eller redigera den här typen av runbook med ett annat verktyg. Huvudfunktioner i grafiska runbooks:

• Exporterades till filer i ditt Automation-konto och importerades sedan till ett annat Automation-konto.
• Generera PowerShell-kod.
• Konverteras till eller från grafiska PowerShell-arbetsflödesrunbooks under importen.

Fördelar

• Använd den visuella redigeringsmodellen insert-link-configure.
• Fokusera på hur data flödar genom processen.
• Representerar hanteringsprocesser visuellt.
• Inkludera andra runbooks som underordnade runbooks för att skapa arbetsflöden på hög nivå.
• Uppmuntra modulär programmering.

Begränsningar

• Det går inte att skapa eller redigera utanför Azure-portalen.
• Kan kräva en kodaktivitet som innehåller PowerShell-kod för att köra komplex logik.
• Det går inte att konvertera till något av textformaten och du kan inte heller konvertera en text runbook till grafiskt format.
• Det går inte att visa eller redigera PowerShell-kod direkt som det grafiska arbetsflödet skapar. Du kan visa koden som du skapar i alla kodaktiviteter.
• Det går inte att köra runbooks på en Linux Hybrid Runbook Worker. Se Automatisera resurser i ditt datacenter eller moln med hjälp av Hybrid Runbook Worker.
• Grafiska runbooks kan inte signeras digitalt.

Nästa steg

• Mer information om PowerShell-runbooks finns i Självstudie: Skapa en PowerShell-runbook.
• Mer information om PowerShell-arbetsflödesrunbooks finns i Självstudie: Skapa en PowerShell Workflow-runbook.
• Mer information om grafiska runbooks finns i Självstudie: Skapa en grafisk runbook.
• Mer information om Python-runbooks finns i Självstudie: Skapa en Python-runbook.