Använda moduler i Azure Automation

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 veta i förväg vilken av cmdletarna som gör 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. Alla cmdletar som utför fullständiga stacknätverksåtgärder stöds inte i sandbox-miljön, inklusive Connect-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 skript som är utformade för att köras med Az-modulen. Om nyckelordet inkluderas, även i en kommentar, kan AzureRm läsas in och sedan komma 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ändarvald version av Az-modulen.

Om det befintliga Automation-kontot har AzureRM och vissa Az-moduler importerar alternativet de återstående Az-modulerna till Automation-kontot. De befintliga Az-modulerna prioriteras och uppdateringsåtgärden uppdaterar inte dessa moduler. Detta är för att säkerställa att åtgärden för uppdateringsmodulen inte leder till körningsfel i runbooken 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 prioriterar alltid standardmoduler .

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 6.4.0-versionen. 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 importeras 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 Portal är egenskapen Global modulsann när du visar en modul som importerades när kontot skapades.

Skärmbild av egenskapen global modul i Azure-portalen

Anteckning

Vi rekommenderar inte att du ändrar moduler och runbooks i Automation-konton som används för distribution av de virtuella Start-/Stop-datorerna under off-hours-funktionen .

Modulnamn Version
Az.* Se en fullständig lista under PaketinformationPowerShell-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 bara ä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 Rollen Windows Hybrid Runbook Worker ä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 Automation-kontoresurser. De kan hämta hemligheter från krypterade variabler, autentiseringsuppgifter och krypterade anslutningar.

Name Beskrivning
Get-AutomationCertificate Get-AutomationCertificate [-Name] <string> [<CommonParameters>]
Get-AutomationConnection 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 på en Windows Hybrid Runbook Worker eftersom de kräver färre parametrar och körs i kontexten för jobbet 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 att använda 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 dess 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 i samma Automation-konto. När du är säker på att du vill migrera från AzureRM till Az är det bäst att helt genomföra en fullständig migrering. Automation återanvänder ofta sandbox-miljöer 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 kraschar snart och du får ett felmeddelande om att modulerna inte är kompatibla. Den här situationen resulterar i slumpmässiga krascher för en viss runbook eller konfiguration.

Anteckning

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 modulmigreringen

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

Stoppa och avplanera alla runbooks som använder AzureRM-moduler

För att säkerställa att du inte kör några befintliga runbooks eller DSC-konfigurationer som använder AzureRM-moduler måste du stoppa och avplanera alla berörda runbooks och konfigurationer. Kontrollera först att du granskar varje runbook- eller DSC-konfiguration och dess scheman separat för att säkerställa att du kan schemalägga om objektet i framtiden om det behövs.

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

Ta bort AzureRM-moduler

Du kan ta bort AzureRM-modulerna innan du importerar Az-modulerna. Men om du gör det kan du avbryta synkroniseringen av källkontroll och orsaka skript som fortfarande är schemalagda att misslyckas. 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 runbooks 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 klasser och import av 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.

Anteckning

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

  • Bläddra i galleriet finns på bladet ProcessAutomatiseringsmoduler>.
  • Sidan Moduler visar två nya kolumner – modulversion och Körningsversion
  1. Logga in på Azure Portal.

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

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

  4. Välj Moduler under Delade resurser från ditt Automation-konto.

  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 galleri – 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.

    Skärmbild av hur du importerar moduler till ditt Automation-konto.

  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 för att Azure Automation.

Skärmbild av att importera moduler direkt från PowerShell-galleriet.

Testa dina runbooks

När du har importerat Az-modulerna till Automation-kontot kan du börja redigera 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. Om du vill förbereda modulen för import måste du skapa minst en .psd1-, .psm1- eller PowerShell-modul .dll fil med samma namn som modulmappen. Sedan zippar du modulmappen så att Azure Automation kan importera den som en enda fil. Det.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 versioneringen av PowerShell-moduler 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 bara fungerar mot en viss version av en PowerShell-modul, men andra skript kräver en nyare version av samma PowerShell-modul.

Skapa PowerShell-moduler så att de innehåller flera versioner genom att skapa modulmappen och sedan skapa 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-modulen.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.

Automation stöder moduler som innehåller versioner sida vid sida i samma paket, men det stöder inte användning av flera versioner av en modul över 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 vill att alla versioner – 1, 2, 3 och 4 ska vara tillgängliga ska den .zip filen som importen ska innehålla version 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 runbooken 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 sades 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 sammanfattning, 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 Portal.

Skärmbild av hjälpen för integreringsmoduler

Anslutningstyp

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.

Använda en anpassad anslutning i Azure Portal

I följande runbook-exempel används en Contoso-anslutningstillgång som anropas ContosoConnection för att få åtkomst till 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 att skicka anslutningsobjektet direkt 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 var och en, så att en användare som inte använder Automation kan anropa dina cmdletar utan att skapa en hash-tabell som fungerar som anslutningsobjekt. Parameteruppsättningen UserAccount används för att skicka egenskaperna för anslutningsfältet. ConnectionObject gör att du kan skicka anslutningen rakt igenom.

Utdatatyp

Definiera utdatatypen för alla cmdletar i modulen. Genom att definiera en utdatatyp för en cmdlet kan IntelliSense designtid för att fastställa utdataegenskaperna för cmdleten under redigeringen. 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>
}

Skärmbild av grafisk runbook-utdatatyp

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

Skärmbild av 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 Sandbox-miljöer för Automation 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 få det att fungera som vanligt när det importeras till en annan värds PowerShell-miljö. För att detta ska ske kontrollerar du att modulen inte är beroende av några filer utanför modulmappen som är komprimerad 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 till modulfiler

Kontrollera att alla filer i modulen har sökvägar med färre än 140 tecken. Sökvägar över 140 tecken 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 Portal

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

  1. I portalen söker du efter och väljer Automation-konton.
  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 importera processen.

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 en modul .zip paket.

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 hämta 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 för att Azure Automation. Den här åtgärden öppnar Azure Portal.
  3. På sidan Importera väljer du ditt Automation-konto och sedan OK.

Skärmbild av modulen PowerShell-galleriet import

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

  1. I portalen söker du efter och väljer Automation-konton.
  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 importen.

Skärmbild av import av en PowerShell-galleriet modul från 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. I portalen söker du efter och väljer Automation-konton.
  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å sidan Modul 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

Om du vill ta bort en modul via PowerShell kör du följande kommando:

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

Nästa steg