Använda moduler i Azure Automation

  • Artikel

Azure Automation använder ett antal PowerShell-moduler för att aktivera cmdletar i runbooks och DSC-resurser i DSC-konfigurationer. Moduler som stöds är:

När du skapar ett Automation-konto importerar Azure Automation vissa moduler som standard. Se Standardmoduler.

Sandbox-miljöer

När Automation kör runbook- och DSC-kompileringsjobb läses modulerna in i sandbox-miljöer där runbooks kan köras och DSC-konfigurationerna kan kompileras. Automation placerar även automatiskt alla DSC-resurser i moduler på DSC-hämtningsservern. Datorer kan hämta resurserna när de tillämpar DSC-konfigurationerna.

Sandbox-miljön i molnet stöder högst 48 systemanrop och begränsar alla andra anrop av säkerhetsskäl. Andra funktioner som hantering av autentiseringsuppgifter och vissa nätverk stöds inte i sandbox-miljön i molnet.

På grund av antalet moduler och cmdletar som ingår är det svårt att i förväg veta vilken av cmdletarna som kommer att göra anrop som inte stöds. I allmänhet har vi sett problem med cmdletar som kräver förhöjd åtkomst, kräver en autentiseringsuppgift som en parameter eller cmdletar som är relaterade till nätverk. Cmdletar som utför fullständiga stacknätverksåtgärder stöds inte i sandbox-miljön, inklusive Anslut-AipService från AIPService PowerShell-modulen och Resolve-DnsName från DNSClient-modulen.

Det här är kända begränsningar i sandbox-miljön. Den rekommenderade lösningen är att distribuera en Hybrid Runbook Worker eller använda Azure Functions.

Viktigt!

Inkludera inte nyckelordet "AzureRm" i något skript som är utformat för att köras med Az-modulen. Inkludering av nyckelordet, även i en kommentar, kan leda till att AzureRm läses in och sedan är i konflikt med Az-modulen.

Standardmoduler

Alla nya Automation-konton har den senaste versionen av PowerShell Az-modulen importerad som standard. Az-modulen ersätter AzureRM och är den rekommenderade modulen som ska användas med Azure. Standardmoduler i det nya Automation-kontot innehåller de befintliga 24 AzureRM-modulerna och 60+ Az-modulerna.

Det finns ett internt alternativ för att uppdatera moduler till den senaste Az-modulen av användaren för Automation-konton. Åtgärden hanterar alla modulberoenden på serverdelen, vilket tar bort besväret med att uppdatera modulerna manuellt eller köra runbooken för att uppdatera Azure-moduler.

Om det befintliga Automation-kontot bara har AzureRM-moduler uppdaterar alternativet Uppdatera Az-moduler Automation-kontot med den användar valda versionen av Az-modulen.

Om det befintliga Automation-kontot har AzureRM och vissa Az-moduler importeras de återstående Az-modulerna till Automation-kontot. De befintliga Az-modulerna prioriteras och uppdateringsåtgärden uppdaterar inte dessa moduler. Det här är för att säkerställa att åtgärden för uppdateringsmodulen inte leder till något runbook-körningsfel genom att oavsiktligt uppdatera en modul som används av en runbook. Det rekommenderade sättet för det här scenariot är att först ta bort befintliga Az-moduler och sedan utföra uppdateringsåtgärderna för att få den senaste Az-modulen importerad i Automation-kontot. Sådana modultyper, som inte importeras som standard, kallas anpassade. Anpassade moduler har alltid företräde framför standardmoduler .

Till exempel: Om du redan har modulen Az.Aks importerad med version 2.3.0 som tillhandahålls av Az-modulen 6.3.0 och du försöker uppdatera Az-modulen till den senaste versionen av 6.4.0. Uppdateringsåtgärden importerar alla Az-moduler från 6.4.0-paketet, förutom Az.Aks. Om du vill ha den senaste versionen av Az.Akstar du först bort den befintliga modulen och utför sedan uppdateringsåtgärden, eller så kan du även uppdatera den här modulen separat enligt beskrivningen i Importera Az-moduler för att importera en annan version av en specifik modul.

I följande tabell visas de moduler som Azure Automation importerar som standard när du skapar ditt Automation-konto. Automation kan importera nyare versioner av dessa moduler. Du kan dock inte ta bort den ursprungliga versionen från ditt Automation-konto, även om du tar bort en nyare version.

Standardmodulerna kallas även globala moduler. I Azure-portalen är egenskapen Global modul sann när du visar en modul som importerades när kontot skapades.

Screenshot of global module property in Azure Portal

Kommentar

Vi rekommenderar inte att du ändrar moduler och runbooks i Automation-konton som används för distribution av de virtuella start-/stoppdatorerna under lågtimmarsfunktionen .

Modulnamn Version:
Az.* Se en fullständig lista under Paketinformation på PowerShell-galleriet
AuditPolicyDsc 1.1.0.0
Azure 1.0.3
Azure.Storage 1.0.3
AzureRM.Automation 1.0.3
AzureRM.Compute 1.2.1
AzureRM.Profile 1.0.3
AzureRM.Resources 1.0.3
AzureRM.Sql 1.0.3
AzureRM.Storage 1.0.3
ComputerManagementDsc 5.0.0.0
GPRegistryPolicyParser 0.2
Microsoft.PowerShell.Core 0
Microsoft.PowerShell.Diagnostics
Microsoft.PowerShell.Management
Microsoft.PowerShell.Security
Microsoft.PowerShell.Utility
Microsoft.WSMan.Management
Orchestrator.AssetManagement.Cmdlets 1
PSDscResources 2.9.0.0
SecurityPolicyDsc 2.1.0.0
StateConfigCompositeResources 1
xDSCDomainjoin 1,1
xPowerShellExecutionPolicy 1.1.0.0
xRemoteDesktopAdmin 1.1.0.0

Interna cmdletar

Azure Automation stöder interna cmdletar som endast är tillgängliga när du kör runbooks i Azure-sandbox-miljön eller på en Windows Hybrid Runbook Worker. Den interna modulen Orchestrator.AssetManagement.Cmdlets installeras som standard i ditt Automation-konto och när Windows Hybrid Runbook Worker-rollen är installerad på datorn.

I följande tabell definieras de interna cmdletarna. Dessa cmdletar är utformade för att användas i stället för Azure PowerShell cmdletar för att interagera med dina kontoresurser för Automation. De kan hämta hemligheter från krypterade variabler, autentiseringsuppgifter och krypterade anslutningar.

Namn Beskrivning
Get-AutomationCertificate Get-AutomationCertificate [-Name] <string> [<CommonParameters>]
Get-Automation Anslut ion Get-AutomationConnection [-Name] <string> [-DoNotDecrypt] [<CommonParameters>]
Get-AutomationPSCredential Get-AutomationPSCredential [-Name] <string> [<CommonParameters>]
Get-AutomationVariable Get-AutomationVariable [-Name] <string> [-DoNotDecrypt] [<CommonParameters>]
Set-AutomationVariable Set-AutomationVariable [-Name] <string> -Value <Object> [<CommonParameters>]
Start-AutomationRunbook Start-AutomationRunbook [-Name] <string> [-Parameters <IDictionary>] [-RunOn <string>] [-JobId <guid>] [<CommonParameters>]
Wait-AutomationJob Wait-AutomationJob -Id <guid[]> [-TimeoutInMinutes <int>] [-DelayInSeconds <int>] [-OutputJobsTransitionedToRunning] [<CommonParameters>]

Observera att de interna cmdletarna skiljer sig från az- och AzureRM-cmdletarna. Interna cmdlet-namn innehåller inte ord som Azure eller Az i substantivet, men använder ordet Automation. Vi rekommenderar att de används för användning av Az- eller AzureRM-cmdletar under runbookkörning i en Azure-sandbox-miljö eller i en Windows Hybrid Runbook Worker eftersom de kräver färre parametrar och körs i kontexten för ditt jobb under körningen.

Använd Az- eller AzureRM-cmdletar för att manipulera Automation-resurser utanför kontexten för en runbook.

Python-moduler

Du kan skapa Python 2-runbooks i Azure Automation. Information om Python-modulen finns i Hantera Python 2-paket i Azure Automation.

Anpassade moduler

Azure Automation stöder anpassade PowerShell-moduler som du skapar för användning med dina runbooks och DSC-konfigurationer. En typ av anpassad modul är en integreringsmodul som eventuellt innehåller en fil med metadata för att definiera de anpassade funktionerna för modul-cmdletarna. Ett exempel på användning av en integreringsmodul finns i Lägg till en anslutningstyp.

Azure Automation kan importera en anpassad modul för att göra sina cmdletar tillgängliga. I bakgrunden lagrar den modulen och använder den i Azure-sandbox-miljön, precis som i andra moduler.

Migrera till Az-moduler

Det här avsnittet beskriver hur du migrerar till Az-modulerna i Automation. Mer information finns i Migrera Azure PowerShell från AzureRM till Az.

Vi rekommenderar inte att du kör AzureRM-moduler och Az-moduler på samma Automation-konto. När du är säker på att du vill migrera från AzureRM till Az är det bäst att genomföra en fullständig migrering. Sandbox-miljöer återanvänds ofta i Automation-kontot för att spara på starttider. Om du inte gör en fullständig modulmigrering kan du starta ett jobb som bara använder AzureRM-moduler och sedan starta ett annat jobb som bara använder Az-moduler. Sandbox-miljön kommer då snart att krascha och du får ett felmeddelande om att modulerna inte är kompatibla. Det här leder till slumpmässiga krascher för en viss runbook eller konfiguration.

Kommentar

När du skapar ett nytt Automation-konto, även efter migreringen till Az-moduler, installerar Automation fortfarande AzureRM-modulerna som standard.

Testa dina runbooks och DSC-konfigurationer före modulmigrering

Se till att testa alla runbooks och DSC-konfigurationer noggrant i ett separat Automation-konto innan du migrerar till Az-modulerna.

Stoppa och ta bort schemaläggningen av alla runbookflöden som använder AzureRM-moduler

Stoppa och ta bort schemaläggningen av alla berörda runbookflöden och konfigurationer så att du inte råkar köra några befintliga runbookflöden eller DSC-konfigurationer som använder AzureRM-moduler. Se först till att granska varje runbook- eller DSC-konfiguration och dess scheman separat så att du kan schemalägga objektet på nytt i framtiden om det behövs.

När du är redo att ta bort dina scheman kan du antingen använda Azure-portalen eller cmdleten Remove-AzureRmAutomationSchedule . Se Ta bort ett schema.

Ta bort AzureRM-moduler

Det går att ta bort AzureRM-modulerna innan du importerar Az-modulerna. Men om du gör det kan synkroniseringen av källkontroll avbrytas vilket kan leda till att det inte går att köra eventuella schemalagda skript. Om du bestämmer dig för att ta bort modulerna läser du Avinstallera AzureRM.

Importera Az-moduler

När du importerar en Az-modul till ditt Automation-konto importeras inte modulen automatiskt till den PowerShell-session som runbookflöden använder. Moduler importeras till PowerShell-sessionen i följande situationer:

  • När en runbook anropar en cmdlet från en modul.
  • När en runbook importerar modulen explicit med cmdleten Import-Module .
  • När en runbook importerar modulen explicit med instruktionen using module . Instruktionen using stöds från och med Windows PowerShell 5.0 och stöder import av klasser och uppräkningstyp.
  • När en runbook importerar en annan beroende modul.

Du kan importera Az-modulerna till Automation-kontot från Azure Portal. Eftersom Az.Accounts är ett beroende för de andra Az-modulerna bör du importera den här modulen före andra.

Kommentar

Med introduktionen av PowerShell 7.1 (förhandsversion) har alternativet Bläddra galleri uppdaterats med följande ändringar:

  • Bläddreringsgalleriet är tillgängligt på bladet ProcessAutomatiseringsmoduler>.
  • Sidan Moduler visar två nya kolumner – modulversion och Körningsversion

  1. Logga in på Azure-portalen.

  2. Sök efter och välj Automation-konton.

  3. På sidan Automation-konton väljer du ditt Automation-konto i listan.

  4. Från ditt Automation-konto går du till Delade resurser och väljer Moduler.

  5. Välj Lägg till en modul. På sidan Lägg till en modul kan du välja något av följande alternativ:

    1. Bläddra efter fil – väljer en fil från den lokala datorn.
    2. Bläddra från galleriet – du kan bläddra och välja en befintlig modul från galleriet.

  6. Klicka på Välj för att välja en modul.

  7. Välj Körningsversion och klicka på Importera.

    Screenshot of importing modules into your Automation account.

  8. På sidan Moduler kan du visa den importerade modulen under Automation-kontot.

Du kan också göra den här importen via PowerShell-galleriet genom att söka efter modulen som ska importeras. När du hittar modulen väljer du den och väljer fliken Azure Automation . Välj Distribuera till Azure Automation.

Screenshot of importing modules directly from PowerShell Gallery.

Testa dina runbooks

När du har importerat Az-modulerna till Automation-kontot kan du börja redigera dina runbooks och DSC-konfigurationer för att använda de nya modulerna. Ett sätt att testa ändringen av en runbook för att använda de nya cmdletarna är att använda Enable-AzureRmAlias -Scope Process kommandot i början av runbooken. Genom att lägga till det här kommandot i din runbook kan skriptet köras utan ändringar.

Skapa moduler

Vi rekommenderar att du följer övervägandena i det här avsnittet när du skapar en anpassad PowerShell-modul för användning i Azure Automation. För att förbereda modulen för import måste du skapa minst en .psd1-, .psm1- eller PowerShell-moduls DLL-fil med samma namn som modulmappen. Sedan zippar du modulmappen så att Azure Automation kan importera den som en enda fil. .zip-paketet ska ha samma namn som den inneslutna modulmappen.

Mer information om hur du redigerar en PowerShell-modul finns i Skriva en PowerShell-skriptmodul.

Versionsmapp

Med powershell-modulversionering sida vid sida kan du använda mer än en version av en modul i PowerShell. Detta kan vara användbart om du har äldre skript som har testats och endast fungerar mot en viss version av en PowerShell-modul, men andra skript kräver en nyare version av samma PowerShell-modul.

Om du vill skapa PowerShell-moduler så att de innehåller flera versioner skapar du modulmappen och skapar sedan en mapp i den här modulmappen för varje version av modulen som du vill ska kunna användas. I följande exempel innehåller en modul med namnet TestModule två versioner, 1.0.0 och 2.0.0.

TestModule
   1.0.0
   2.0.0

I var och en av versionsmapparna kopierar du powerShell .psm1-, .psd1- eller PowerShell-modulens .dll-filer som utgör en modul till respektive versionsmapp. Zippa upp modulmappen så att Azure Automation kan importera den som en enda .zip-fil. Automation visar bara den högsta versionen av modulen som importerats, men om modulpaketet innehåller sida vid sida-versioner av modulen är de alla tillgängliga för användning i dina runbooks eller DSC-konfigurationer.

Även om Automation stöder moduler som innehåller sida vid sida-versioner i samma paket, stöder det inte användning av flera versioner av en modul i modulpaketimporter. Du kan till exempel importera modul A, som innehåller version 1 och 2 till ditt Automation-konto. Senare uppdaterar du modul A för att inkludera version 3 och 4, när du importerar till ditt Automation-konto kan endast version 3 och 4 användas i alla runbooks eller DSC-konfigurationer. Om du kräver att alla versioner – 1, 2, 3 och 4 ska vara tillgängliga ska zip-filen som din import innehåller versionerna 1, 2, 3 och 4.

Om du ska använda olika versioner av samma modul mellan runbooks bör du alltid deklarera den version som du vill använda i din runbook med hjälp av cmdleten Import-Module och inkludera parametern -RequiredVersion <version>. Även om den version som du vill använda är den senaste versionen. Det beror på att runbook-jobb kan köras i samma sandbox-miljö. Om sandbox-miljön redan uttryckligen har läst in en modul med ett visst versionsnummer, eftersom ett tidigare jobb i sandbox-miljön sägs göra det, läser framtida jobb i sandbox-miljön inte automatiskt in den senaste versionen av modulen. Det beror på att någon version av den redan har lästs in i sandbox-miljön.

För en DSC-resurs använder du följande kommando för att ange en viss version:

Import-DscResource -ModuleName <ModuleName> -ModuleVersion <version>

Hjälpinformation

Inkludera en synopsis, beskrivning och hjälp-URI för varje cmdlet i modulen. I PowerShell kan du definiera hjälpinformation för cmdletar med hjälp av cmdleten Get-Help . I följande exempel visas hur du definierar en synopsis och hjälp-URI i en .psm1-modulfil .

<#
     .SYNOPSIS
      Gets a Contoso User account
#>
function Get-ContosoUser {
[CmdletBinding](DefaultParameterSetName='UseConnectionObject', `
HelpUri='https://www.contoso.com/docs/information')]
[OutputType([String])]
param(
   [Parameter(ParameterSetName='UserAccount', Mandatory=true)]
   [ValidateNotNullOrEmpty()]
   [string]
   $UserName,

   [Parameter(ParameterSetName='UserAccount', Mandatory=true)]
   [ValidateNotNullOrEmpty()]
   [string]
   $Password,

   [Parameter(ParameterSetName='ConnectionObject', Mandatory=true)]
   [ValidateNotNullOrEmpty()]
   [Hashtable]
   $Connection
)

switch ($PSCmdlet.ParameterSetName) {
   "UserAccount" {
      $cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $UserName, $Password
      Connect-Contoso -Credential $cred
   }
   "ConnectionObject" {
      Connect-Contoso -Connection $Connection
  }
}
}

Om du anger den här informationen visas hjälptext via cmdleten Get-Help i PowerShell-konsolen. Den här texten visas också i Azure-portalen.

Screenshot of integration module help

Connection type

Om modulen ansluter till en extern tjänst definierar du en anslutningstyp med hjälp av en anpassad integreringsmodul. Varje cmdlet i modulen bör acceptera en instans av den anslutningstypen (anslutningsobjektet) som en parameter. Användare mappar parametrar för anslutningstillgången till cmdletens motsvarande parametrar varje gång de anropar en cmdlet.

Use a custom connection in the Azure portal

I följande runbook-exempel används en Contoso-anslutningstillgång som anropas ContosoConnection för att komma åt Contoso-resurser och returnera data från den externa tjänsten. I det här exemplet mappas fälten UserName till egenskaperna och Password för ett PSCredential objekt och skickas sedan till cmdleten.

$contosoConnection = Get-AutomationConnection -Name 'ContosoConnection'

$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $contosoConnection.UserName, $contosoConnection.Password
Connect-Contoso -Credential $cred
}

Ett enklare och bättre sätt att hantera det här beteendet är genom att direkt skicka anslutningsobjektet till cmdleten:

$contosoConnection = Get-AutomationConnection -Name 'ContosoConnection'

Connect-Contoso -Connection $contosoConnection
}

Du kan aktivera liknande beteende för dina cmdletar genom att låta dem acceptera ett anslutningsobjekt direkt som en parameter, i stället för bara anslutningsfält för parametrar. Vanligtvis vill du ha en parameteruppsättning för varje, så att en användare som inte använder Automation kan anropa dina cmdletar utan att skapa en hashtable för att fungera som anslutningsobjekt. Parameteruppsättningen UserAccount används för att skicka egenskaperna för anslutningsfältet. ConnectionObject låter dig skicka anslutningen rakt igenom.

Utdatatyp

Definiera utdatatypen för alla cmdletar i modulen. Genom att definiera en utdatatyp för en cmdlet kan IntelliSense under redigeringen fastställa utdataegenskaperna för cmdleten. Den här metoden är särskilt användbar vid grafisk runbook-redigering, där designtidskunskaper är nyckeln till en enkel användarupplevelse med din modul.

Lägg till [OutputType([<MyOutputType>])], där MyOutputType är en giltig typ. Mer information om OutputTypefinns i Om Functions OutputTypeAttribute. Följande kod är ett exempel på hur du lägger OutputType till i en cmdlet:

function Get-ContosoUser {
[OutputType([String])]
param(
   [string]
   $Parameter1
)
# <script location here>
}

Screenshot of graphical runbook output type

Det här beteendet liknar funktionen "type ahead" i en cmdlets utdata i PowerShell-integrationstjänstmiljön, utan att behöva köra den.

Screenshot of POSH IntelliSense

Cmdlet-tillstånd

Gör alla cmdletar i modulen tillståndslösa. Flera runbook-jobb kan köras samtidigt i samma AppDomain och samma process och sandbox-miljö. Om det finns något tillstånd som delas på dessa nivåer kan jobb påverka varandra. Det här beteendet kan leda till tillfälliga och svårdiagnostiserade problem. Här är ett exempel på vad du inte ska göra:

$globalNum = 0
function Set-GlobalNum {
   param(
       [int] $num
   )

   $globalNum = $num
}
function Get-GlobalNumTimesTwo {
   $output = $globalNum * 2

   $output
}

Modulberoende

Kontrollera att modulen är helt innesluten i ett paket som kan kopieras med hjälp av xcopy. Automation-moduler distribueras till Automation-sandbox-miljön när runbooks körs. Modulerna måste fungera oberoende av värden som kör dem.

Du bör kunna zippa upp och flytta ett modulpaket och låta det fungera som vanligt när det importeras till en annan värds PowerShell-miljö. Se till att modulen inte är beroende av filer utanför modulmappen som zippads upp när modulen importeras till Automation.

Modulen bör inte vara beroende av några unika registerinställningar på en värd. Exempel är de inställningar som görs när en produkt installeras.

Sökvägar för modulfiler

Kontrollera att alla filer i modulen har sökvägar med färre än 140 tecken. Sökvägar över 140 tecken i längd orsakar problem med att importera runbooks. Automation kan inte importera en fil med sökvägsstorlek över 140 tecken till PowerShell-sessionen med Import-Module.

Importera moduler

Det här avsnittet definierar flera sätt att importera en modul till ditt Automation-konto.

Importera moduler i Azure-portalen

Så här importerar du en modul i Azure Portal:

  1. Sök efter och väljer Automation-konton i portalen.
  2. På sidan Automation-konton väljer du ditt Automation-konto i listan.
  3. Under Delade resurser väljer du Moduler.
  4. Välj Lägg till en modul.
  5. Välj den .zip-fil som innehåller modulen.
  6. Välj OK för att börja importprocessen.

Importera moduler med hjälp av PowerShell

Du kan använda cmdleten New-AzAutomationModule för att importera en modul till ditt Automation-konto. Cmdleten tar en URL för ett .zip-modulpaket.

New-AzAutomationModule -Name <ModuleName> -ContentLinkUri <ModuleUri> -ResourceGroupName <ResourceGroupName> -AutomationAccountName <AutomationAccountName>

Du kan också använda samma cmdlet för att importera en modul från PowerShell-galleriet direkt. Se till att ta ModuleName och ModuleVersion från PowerShell-galleriet.

$moduleName = <ModuleName>
$moduleVersion = <ModuleVersion>
New-AzAutomationModule -AutomationAccountName <AutomationAccountName> -ResourceGroupName <ResourceGroupName> -Name $moduleName -ContentLinkUri "https://www.powershellgallery.com/api/v2/package/$moduleName/$moduleVersion"

Du kan importera PowerShell-galleriet moduler antingen direkt från galleriet eller från ditt Automation-konto.

Så här importerar du en modul direkt från PowerShell-galleriet:

  1. Gå till https://www.powershellgallery.com och sök efter modulen som ska importeras.
  2. Under Installationsalternativ går du till fliken Azure Automation och väljer Distribuera till Azure Automation. Den här åtgärden öppnar Azure-portalen.
  3. På sidan Importera väljer du ditt Automation-konto och väljer OK.

Screenshot of the PowerShell Gallery import module

Så här importerar du en PowerShell-galleriet modul direkt från ditt Automation-konto:

  1. Sök efter och väljer Automation-konton i portalen.
  2. På sidan Automation-konton väljer du ditt Automation-konto i listan.
  3. Under Delade resurser väljer du Moduler.
  4. Välj Bläddra i galleriet och sök sedan efter en modul i galleriet.
  5. Välj den modul som ska importeras och välj Importera.
  6. Välj OK för att starta importprocessen.

Screenshot of importing a PowerShell Gallery module from the Azure portal

Ta bort moduler

Om du har problem med en modul eller om du behöver återställa till en tidigare version av en modul kan du ta bort den från ditt Automation-konto. Du kan inte ta bort de ursprungliga versionerna av standardmodulerna som importeras när du skapar ett Automation-konto. Om modulen som ska tas bort är en nyare version av en av standardmodulerna återställs den till den version som installerades med ditt Automation-konto. Annars tas alla moduler som du tar bort från ditt Automation-konto bort.

Ta bort moduler i Azure Portal

Så här tar du bort en modul i Azure Portal:

  1. Sök efter och väljer Automation-konton i portalen.
  2. På sidan Automation-konton väljer du ditt Automation-konto i listan.
  3. Under Delade resurser väljer du Moduler.
  4. Välj den modul som du vill ta bort.
  5. På Modulens sida väljer du Ta bort. Om den här modulen är en av standardmodulerna återställs den till den version som fanns när Automation-kontot skapades.

Ta bort moduler med hjälp av PowerShell

Kör följande kommando för att ta bort en modul via PowerShell:

Remove-AzAutomationModule -Name <moduleName> -AutomationAccountName <automationAccountName> -ResourceGroupName <resourceGroupName>

Nästa steg