Verwalten von Modulen in Azure Automation

Azure Automation verwendet eine Reihe von PowerShell-Modulen, um Cmdlets in Runbooks und DSC-Ressourcen in DSC-Konfigurationen zu aktivieren. Zu den unterstützten Modulen gehören:

• Azure PowerShell Az modules.
• Weitere PowerShell-Module.
• Internes Orchestrator.AssetManagement.Cmdlets Modul (nicht für einen Linux Hybrid Runbook Worker verfügbar).
• Python 2 und Python 3 Module.
• Selbst erstellte benutzerdefinierte Module.

Wenn Sie ein Automatisierungskonto erstellen, importiert Azure Automation standardmäßig einige Module. Weitere Informationen finden Sie unter Standardmodule.

Sandkästen

Wenn Automation Runbook- und DSC-Kompilierungsaufträge ausführt, werden die Module in Sandboxes geladen, in denen die Runbooks ausgeführt und die DSC-Konfigurationen kompiliert werden können. DSC-Ressourcen in Modulen werden ebenfalls automatisch auf dem DSC-Pullserver platziert. Computer können die Ressourcen beim Anwenden von DSC-Konfigurationen per Pull abrufen.

Eine Cloudsandbox unterstützt maximal 48 Systemaufrufe und schränkt alle anderen Aufrufe aus Sicherheitsgründen ein. Andere Funktionen wie die Verwaltung von Anmeldeinformationen und einige Netzwerke werden in der Cloud-Sandbox nicht unterstützt.

Aufgrund der Anzahl der enthaltenen Module und Cmdlets ist es schwierig, vorab zu wissen, welche der Cmdlets nicht unterstützte Aufrufe durchführen. Im Allgemeinen treten Probleme bei Cmdlets auf, für die erhöhte Zugriffsrechte erforderlich sind oder die Anmeldeinformationen als Parameter erfordern, oder bei Cmdlets für Netzwerkfunktionen. Alle Cmdlets, die vollständige Stapelnetzwerkvorgänge ausführen, werden im Sandkasten nicht unterstützt, einschließlich Connect-AipService aus dem AIPService PowerShell-Modul und Resolve-DnsName aus dem DNSClient-Modul .

Dabei handelt es sich um bekannte Einschränkungen bei einer Sandbox. Die empfohlene Problemumgehung besteht darin, einen Hybrid Runbook Worker bereitzustellen oder Azure Functions zu verwenden.

Standardmodule

In allen neuen Automation-Konten wird standardmäßig die neueste Version des PowerShell-Az-Moduls importiert. Das Az-Modul ersetzt AzureRM und ist das empfohlene Modul für die Verwendung mit Azure. Zu den Standardmodulen im neuen Automation-Konto gehören die vorhandenen 24 AzureRM-Module und mehr als 60 Az-Module.

Es gibt eine native Option für Benutzer, um Module in Automatisierungskonten auf das neueste Az-Modul zu aktualisieren. Der Vorgang behandelt alle Modulabhängigkeiten im Back-End und entfernt dadurch die Probleme beim Aktualisieren der Module manual oder ausführen des Runbook auf Update Azure Module.

Wenn das vorhandene Automation-Konto ausschließlich über AzureRM-Module verfügt, wird mit der Option Az-Module aktualisieren das Automation-Konto mit der ausgewählten Version des Az-Moduls aktualisiert.

Wenn das vorhandene Automation-Konto über AzureRM-Module und einige Az-Module verfügt, werden mit dieser Option die verbleibenden Az-Module in das Automation-Konto importiert. Die vorhandenen Az-Module werden bevorzugt, und der Aktualisierungsvorgang aktualisiert diese Module nicht. Damit wird sichergestellt, dass der Updatevorgang für die Module nicht zu Ausführungsfehlern bei Runbooks führt, indem versehentlich ein Modul aktualisiert wird, das von einem Runbook verwendet wird. Für dieses Szenario wird empfohlen, zuerst die vorhandenen Az-Module zu löschen und dann die Updatevorgänge durchzuführen, um das neueste Az-Modul in das Automation-Konto zu importieren. Modultypen, die nicht standardmäßig importiert werden, werden als benutzerdefiniert bezeichnet. Benutzerdefinierte Module haben immer Vorrang gegenüber Standardmodulen.

Beispiel: Sie haben bereits das Modul Az.Aks in Version 2.3.0 importiert, die vom Az-Modul 6.3.0 bereitgestellt wird, und versuchen, das Az-Modul auf die neueste Version 6.4.0 zu aktualisieren. Beim Updatevorgang werden alle Az-Module aus dem Paket 6.4.0 mit Ausnahme von Az.Aks importiert. Um die neueste Version von Az.Aks zu erhalten, löschen Sie zunächst das vorhandene Modul und führen dann den Updatevorgang aus. Sie können dieses Modul auch separat aktualisieren, wie unter Importieren von Az-Modulen beschrieben, um eine andere Version eines bestimmten Moduls zu importieren.

In der folgenden Tabelle sind die Module aufgeführt, die standardmäßig importiert Azure Automation, wenn Sie Ihr Automatisierungskonto erstellen. Automation kann neuere Versionen dieser Module importieren. Sie können jedoch die ursprüngliche Version nicht aus Ihrem Automation-Konto entfernen, selbst wenn Sie eine neuere Version löschen.

Die Standardmodule werden auch als globale Module bezeichnet. Im Azure-Portal wird die Eigenschaft des Moduls Global auf true gesetzt sein, wenn ein Modul angezeigt wird, das beim Erstellen des Kontos importiert wurde.

Interne Cmdlets

Azure Automation stellt interne Cmdlets bereit, die exklusiv verfügbar sind, wenn Runbooks in der Azure Sandkastenumgebung oder in einem Windows Hybrid Runbook Worker ausgeführt werden. Das Modul Orchestrator.AssetManagement.Cmdlets, das diese internen Cmdlets enthält, wird standardmäßig in Ihrem Automatisierungskonto installiert und insbesondere, wenn die Rolle Windows Hybrid Runbook Worker auf einem Windows-Computer installiert ist.

In der folgenden Tabelle werden die internen Cmdlets definiert. Diese Cmdlets sind so konzipiert, dass sie anstelle von Azure PowerShell Cmdlets für die Interaktion mit Ihren Automatisierungskontoressourcen verwendet werden. Sie können Geheimnisse aus verschlüsselten Variablen, Anmeldeinformationen und verschlüsselten Verbindungen abrufen.

Beachten Sie, dass sich die internen Cmdlets bei der Benennung von den Az- und AzureRM-Cmdlets unterscheiden. Interne Cmdlet-Namen enthalten keine Wörter wie Azure oder Az im Substantiv, aber verwenden Sie das Wort Automation. Es wird empfohlen, Az- oder AzureRM-Cmdlets während der Ausführung von Runbooks in einer Azure-Sandbox oder auf einem Windows Hybrid Runbook Worker zu verwenden, da sie weniger Parameter erfordern und im Kontext Ihres Auftrags ausgeführt werden.

Verwenden Sie Az- oder AzureRM-Cmdlets zum Bearbeiten von Automation-Ressourcen außerhalb des Kontexts eines Runbooks.

Python-Module

Sie können Python 2 Runbooks in Azure Automation erstellen. Informationen zu Python Moduls finden Sie unter Manage Python 2 Pakete in Azure Automation.

Benutzerdefinierte Module

Azure Automation unterstützt benutzerdefinierte PowerShell-Module, die Sie für die Verwendung mit Ihren Runbooks und DSC-Konfigurationen erstellen. Eine Art benutzerdefiniertes Modul ist ein Integrationsmodul, das optional eine Datei mit Metadaten enthalten kann, um die benutzerdefinierte Funktionalität für die Cmdlets des Moduls zu definieren. Ein Beispiel für die Verwendung eines Integrationsmoduls wird unter Hinzufügen eines Verbindungstyps veranschaulicht.

Azure Automation kann ein benutzerdefiniertes Modul importieren, um seine Cmdlets zur Verfügung zu stellen. Hinter den Kulissen speichert es das Modul und verwendet es in den Azure-Sandkästen, ähnlich wie bei anderen Modulen.

Migrieren zu Az-Modulen

In diesem Abschnitt erfahren Sie, wie Sie zu den Az-Modulen in Automation migrieren. Weitere Informationen finden Sie unter Migrate Azure PowerShell von AzureRM zu Az.

Die Ausführung von AzureRM-Modulen und Az-Modulen im selben Automation-Konto wird nicht empfohlen. Wenn Sie sicher sind, dass Sie von AzureRM zu Az migrieren möchten, ist es am besten, sich in vollem Umfang zu einer vollständige Migration zu entschließen. Automation-Sandboxes werden häufig im Automation-Konto wiederverwendet, um die Startzeiten zu verkürzen. Wenn Sie keine vollständige Modulmigration durchführen, starten Sie möglicherweise einen Auftrag, der ausschließlich AzureRM-Module nutzt, und dann einen anderen Auftrag nur mit Az-Modulen. Die Sandbox stürzt dann bald ab, und Sie erhalten einen schwerwiegenden Fehler, da die Module nicht kompatibel sind. Diese Situation führt zu zufällig auftretenden Abstürzen bei beliebigen Runbooks oder Konfigurationen.

Testen Ihrer Runbooks und DSC-Konfigurationen vor der Modulmigration

Stellen Sie sicher, dass Sie alle Runbooks und DSC-Konfigurationen sorgfältig in einem separaten Automation-Konto testen, bevor Sie zu den Az-Modulen migrieren.

Anhalten und Aufheben des Zeitplans aller Runbooks, die AzureRM-Module verwenden

Um sicherzustellen, dass Sie keine vorhandenen Runbooks oder DSC-Konfigurationen ausführen, die AzureRM-Module verwenden, müssen Sie alle betroffenen Runbooks und Konfigurationen beenden und aufheben. Stellen Sie zunächst sicher, dass Sie jedes Runbook oder jede DSC-Konfiguration und deren zugehörige Zeitpläne gesondert überprüfen, um zu gewährleisten, dass Sie das Element ggf. in Zukunft neu planen können.

Wenn Sie bereit sind, Ihre Zeitpläne zu entfernen, können Sie entweder das Azure Portal oder das Cmdlet Remove-AzAutomationSchedule verwenden. Weitere Informationen finden Sie unter Entfernen eines Zeitplans.

Entfernen der AzureRM-Module

Es ist möglich, die AzureRM-Module zu entfernen, bevor Sie die Az-Module importieren. Dadurch kann jedoch die Synchronisierung der Quellcodeverwaltung unterbrochen werden, und es kann dazu führen, dass alle noch geplanten Skripts mit Fehlern beendet werden. Wenn Sie sich zum Entfernen der Module entschließen, finden Sie Informationen hierzu unter Deinstallieren von AzureRM.

Importieren von Az-Modulen

Beim Importieren eines Az-Moduls in Ihr Automation-Konto wird das Modul nicht automatisch in die PowerShell-Sitzung importiert, die von Runbooks verwendet wird. Module werden in den folgenden Situationen in die PowerShell-Sitzung importiert:

• Wenn ein Runbook ein Cmdlet in einem Modul aufruft
• Wenn ein Runbook das Modul explizit mit dem Cmdlet Import-Module importiert.
• Wenn ein Runbook das Modul explizit mit der using module-Anweisung importiert. Die Using-Anweisung wird ab Windows PowerShell 5.0 unterstützt und ermöglicht den Import von Klassen und Enum-Typen.
• Wenn ein Runbook ein anderes abhängiges Modul importiert.

Sie können die Az-Module aus dem Azure Portal in das Automatisierungskonto importieren. Da Az.Accounts eine Abhängigkeit für die anderen Az-Module darstellt, muss dieses Modul vor den anderen Modulen importiert werden.

• Die Option Katalog durchsuchen ist auf dem Blatt Prozessautomatisierung>Module verfügbar.
• Auf der Seite Module werden zwei neue Spalten angezeigt: Modulversion und Runtimeversion

1. Melden Sie sich beim Azure portal an.

2. Suchen Sie nach Automation-Konten, und wählen Sie diese Option aus.

3. Wählen Sie auf der Seite Automation-Konten in der entsprechenden Liste Ihr Automation-Konto aus.

4. Wählen Sie in Ihrem Automation-Konto unter Freigegebene Ressourcen die Option Module aus.

5. Wählen Sie Modul hinzufügen aus. Auf der Seite Modul hinzufügen können Sie eine der folgenden Optionen auswählen:

   1. Nach Datei suchen: Wählt eine Datei auf Ihrem lokalen Computer aus.
   2. Aus Katalog durchsuchen: Sie können ein vorhandenes Modul im Katalog suchen und auswählen.

6. Klicken Sie auf Auswählen, um ein Modul auszuwählen.

7. Wählen Sie Runtimeversion aus, und klicken Sie auf Importieren.

   

8. Auf der Seite Module können Sie das importierte Modul unter dem Automation-Konto anzeigen.

Sie können diesen Import auch über die PowerShell-Katalog durchführen, indem Sie nach dem zu importierenden Modul suchen. Wenn Sie das Modul gefunden haben, wählen Sie es aus, und wählen Sie die Registerkarte Azure Automation aus. Wählen Sie Deploy to Azure Automation aus.

Testen Ihres Runbooks

Nachdem Sie die Az-Module in das Automation-Konto importiert haben, können Sie beginnen, Ihre Runbooks und DSC-Konfigurationen so zu bearbeiten, dass sie die neuen Module verwenden. Eine Möglichkeit zum Testen der Änderung eines Runbooks zur Verwendung der neuen Cmdlets besteht darin, den Befehl Enable-AzureRmAlias -Scope Process am Anfang des Runbooks anzugeben. Wenn Sie diesen Befehl Ihrem Runbook hinzufügen, kann das Skript ohne Änderungen ausgeführt werden.

Erstellen von Modulen

Es wird empfohlen, die Überlegungen in diesem Abschnitt zu befolgen, wenn Sie ein benutzerdefiniertes PowerShell-Modul für die Verwendung in Azure Automation erstellen. Sie müssen zumindest eine PSD1-, PSM1- oder PowerShell-Modul-DLL-Datei mit dem gleichen Namen wie der Modulordner erstellen, um Ihr Modul für den Importvorgang vorzubereiten. Anschließend zippen Sie den Modulordner, sodass Azure Automation ihn als einzelne Datei importieren kann. Das ZIP-Paket sollte den gleichen Namen wie der enthaltene Modulordner aufweisen.

Weitere Informationen zum Erstellen eines PowerShell-Moduls finden Sie unter Schreiben eines PowerShell-Skriptmoduls.

Versionsordner

Mit der parallelen PowerShell-Modulversionsverwaltung können Sie mehr als eine Version eines Moduls innerhalb von PowerShell verwenden. Dies kann hilfreich sein, wenn Sie ältere Skripts haben, die getestet wurden und nur mit einer bestimmten Version eines PowerShell-Moduls funktionieren, während andere Skripts aber eine neuere Version desselben PowerShell-Moduls benötigen.

Um PowerShell-Module zu erstellen, sodass Sie mehrere Versionen enthalten, erstellen Sie den Modulordner, und erstellen Sie dann einen Ordner in diesem Modulordner für jede Version des Moduls, das verwendbar sein soll. Im folgenden Beispiel stellt ein Modul namens TestModule zwei Versionen bereit, 1.0.0 und 2.0.0.

TestModule
   1.0.0
   2.0.0

Kopieren Sie in jedem der Versionsordner Ihre PowerShell-PSM1-, PSD1- oder PowerShell-Modul-DLL-Dateien, aus denen ein Modul besteht, in den jeweiligen Versionsordner. Zippen Sie den Modulordner, damit Azure Automation ihn als einzelne .zip Datei importieren kann. Die Automatisierung zeigt zwar nur eine der importierten Versionen des Moduls an, wenn das Modulpaket parallele Versionen des Moduls enthält, sie sind jedoch alle für die Verwendung in Ihren Runbooks- oder DSC-Konfigurationen verfügbar.

Während Die Automatisierung Module unterstützt, die parallele Versionen innerhalb desselben Pakets enthalten, wird die Verwendung mehrerer Versionen eines Moduls über Modulpaketimporte hinweg nicht unterstützt. Angenommen, Sie importieren beispielsweise Modul A, das die Versionen 1 und 2 enthält, in Ihr Automation-Konto. Später aktualisieren Sie das Modul A, um die Versionen 3 und 4 aufzunehmen. Wenn Sie es nun in Ihr Automation-Konto importieren, können nur die Versionen 3 und 4 in allen Runbooks oder DSC-Konfigurationen verwendet werden. Wenn alle Versionen (1, 2, 3 und 4) verfügbar sein müssen, sollte die ZIP-Datei, die Sie importieren, die Versionen 1, 2, 3 und 4 enthalten.

Wenn Sie unterschiedliche Versionen desselben Moduls zwischen Runbooks verwenden möchten, sollten Sie immer die Version deklarieren, die Sie in Ihrem Runbook verwenden möchten, indem Sie das Cmdlet Import-Module verwenden und den Parameter -RequiredVersion <version> einschließen. Selbst wenn es sich bei der zu verwendenden Version um die neueste Version handelt. Dies liegt daran, dass Runbookaufträge in derselben Sandbox ausgeführt werden können. Wenn die Sandbox bereits explizit ein Modul mit einer bestimmten Versionsnummer geladen hat, weil ein vorheriger Auftrag in dieser Sandbox dies angewiesen hatte, laden zukünftige Aufträge in dieser Sandbox nicht automatisch die neueste Version dieses Moduls. Dies liegt daran, dass einige Versionen davon bereits in der Sandbox geladen sind.

Verwenden Sie für eine DSC-Ressource den folgenden Befehl, um eine bestimmte Version anzugeben:

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

Hilfeinformationen

Fügen Sie eine Zusammenfassung, eine Beschreibung und einen Hilfe-URI für jedes Cmdlet in Ihrem Modul ein. In PowerShell können Sie mithilfe des Cmdlets Get-Help Hilfeinformationen für Cmdlets definieren. Im folgenden Beispiel sehen Sie, wie Sie eine Zusammenfassung und einen Hilfe-URI für eine Moduldatei vom Typ .psm1 erstellen.

<#
     .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
  }
}
}

Bei Angabe dieser Informationen wird Hilfetext über das Cmdlet Get-Help in der PowerShell-Konsole angezeigt. Dieser Text wird auch im Azure Portal angezeigt.

Verbindungstyp

Wenn das Modul eine Verbindung mit einem externen Dienst herstellt, definieren Sie einen Verbindungstyp mithilfe eines benutzerdefinierten Integrationsmoduls. Jedes Cmdlet im Modul muss eine Instanz dieses Verbindungstyps (ein Verbindungsobjekt) als Parameter akzeptieren. Benutzende ordnen Parameter des Verbindungsobjekts bei jedem Aufruf eines Cmdlets den entsprechenden Parametern des Cmdlets zu.

Im folgenden Runbookbeispiel wird eine Contoso-Verbindungsressource namens ContosoConnection verwenden, um auf Contoso-Ressourcen zuzugreifen und Daten vom externen Dienst zurückzugeben. In diesem Beispiel werden die Felder den Eigenschaften UserName und Password eines Objekts vom Typ PSCredential zugeordnet und dann an das Cmdlet übergeben.

$contosoConnection = Get-AutomationConnection -Name 'ContosoConnection'

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

Eine einfachere und bessere Herangehensweise für dieses Verhalten besteht jedoch darin, das Verbindungsobjekt direkt an das Cmdlet zu übergeben:

$contosoConnection = Get-AutomationConnection -Name 'ContosoConnection'

Connect-Contoso -Connection $contosoConnection
}

Sie können ein solches Verhalten für Ihre Cmdlets aktivieren, indem Sie zulassen, dass ein Verbindungsobjekt direkt als Parameter akzeptiert wird, und nicht nur Verbindungsfelder für Parameter. In der Regel empfiehlt sich jeweils ein Parametersatz, damit ein Benutzer, der Automation nicht verwendet, Ihre Cmdlets aufrufen kann, ohne eine Hashtabelle erstellen zu müssen, die als Verbindungsobjekt dient. Mit dem Parametersatz UserAccount werden die Eigenschaften des Verbindungsfelds übergeben. Mit ConnectionObject können Sie die Verbindung direkt übergeben.

Ausgabetyp

Definieren Sie den Ausgabetyp für alle Cmdlets in Ihrem Modul. Wenn Sie einen Ausgabetyp für ein Cmdlet definieren, können Sie bei der Erstellung mithilfe von IntelliSense die Ausgabeeigenschaften des Cmdlets bestimmen. Diese Vorgehensweise ist insbesondere bei der Erstellung von grafischen Runbooks hilfreich, da Kenntnisse zum Zeitpunkt des Entwurfs für die Benutzerfreundlichkeit Ihres Moduls von zentraler Bedeutung sind.

Fügen Sie [OutputType([<MyOutputType>])] hinzu, wobei MyOutputType ein gültiger Typ ist. Weitere Informationen zu OutputType finden Sie unter Informationen zu Functions: OutputTypeAttribute. Der folgende Code ist ein Beispiel, wie Sie OutputType einem Cmdlet hinzufügen:

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

Dieses Verhalten ähnelt der Textvervollständigung der Ausgabe eines Cmdlets in der PowerShell ISE (Integrationsdienstumgebung), ohne dass diese ausgeführt werden muss.

Cmdlet-Status

Legen Sie alle Cmdlets in Ihrem Modul als statusfrei fest. Mehrere Runbookaufträge können gleichzeitig in derselben AppDomain, im gleichen Prozess und in der gleichen Sandbox ausgeführt werden. Wenn auf diesen Ebenen ein Zustand geteilt wird, können sich Jobs gegenseitig beeinflussen. Dieses Verhalten kann zu vorübergehenden und schwierig zu diagnostizierenden Problemen führen. Hier ist ein Beispiel dafür, was nicht zu tun ist:

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

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

   $output
}

Modulabhängigkeit

Stellen Sie sicher, dass das Modul vollständig in einem Paket enthalten ist, das mithilfe von xcopy kopiert werden kann. Automation-Module werden an die Automation-Sandboxes verteilt, wenn Runbooks ausgeführt werden. Die Module müssen unabhängig vom Host funktionieren, auf dem Sie ausgeführt werden.

Es muss daher möglich sein, ein Modulpaket zu komprimieren, zu verschieben und nach dem Import in die PowerShell-Umgebung eines anderen Hosts ganz normal zu verwenden. Stellen Sie dazu sicher, dass das Modul nicht von Dateien außerhalb des Modulordners abhängt, der beim Importieren des Moduls in Automation komprimiert wird.

Das Modul darf nicht von konkreten Registrierungseinstellungen auf einem Host abhängen. Beispiele hierfür sind die Einstellungen, die beim Installieren eines Produkts festgelegt werden.

Moduldateipfade

Stellen Sie sicher, dass alle Dateien im Modul Pfade mit einer Länge von weniger als 140 Zeichen aufweisen. Bei Pfaden mit mehr als 140 Zeichen treten Probleme auf, wenn Runbooks importiert werden. Automation kann keine Datei mit einer Pfadlänge über 140 Zeichen in die PowerShell-Sitzung mit Import-Module importieren.

Importieren von Modulen

In diesem Abschnitt sind verschiedene Methoden beschrieben, um ein Modul in Ihr Automation-Konto zu importieren.

Importieren von Modulen im Azure-Portal

So importieren Sie ein Modul im Azure-Portal:

1. Suchen Sie im Portal nach Automation-Konten, und wählen Sie diese Option aus.
2. Wählen Sie auf der Seite Automation-Konten in der entsprechenden Liste Ihr Automation-Konto aus.
3. Wählen Sie unter Freigegebene Ressourcen die Option Module aus.
4. Wählen Sie Modul hinzufügen aus.
5. Wählen Sie die ZIP-Datei aus, die Ihr Modul enthält.
6. Wählen Sie OK aus, um den Importvorgang zu starten.

Importieren von Modulen mithilfe von PowerShell

Sie können das Cmdlet New-AzAutomationModule zum Importieren von Modulen in Ihr Automation-Konto verwenden. Das Cmdlet benötigt eine URL für ein Modul-ZIP-Paket.

$moduleName = "<ModuleName>"
$contentLinkUri = "<ModuleUri>"
$runtimeVersion = "<RuntimeVersion>" # 5.1 or 7.2
$resourceGroupName = "<ResourceGroupName>"
$automationAccountName = "<AutomationAccountName>"
New-AzAutomationModule -Name $moduleName -RuntimeVersion $runtimeVersion -ContentLinkUri $contentLinkUri -ResourceGroupName $resourceGroupName -AutomationAccountName $automationAccountName

Sie können auch dasselbe Cmdlet verwenden, um ein Modul direkt aus dem PowerShell-Katalog zu importieren. Achten Sie darauf, ModuleName und ModuleVersion aus der PowerShell-Katalog zu ziehen.

$moduleName = "<ModuleName>"
$moduleVersion = "<ModuleVersion>"
$runtimeVersion = "<RuntimeVersion>" # 5.1 or 7.2
$resourceGroupName = "<ResourceGroupName>"
$automationAccountName = "<AutomationAccountName>"
New-AzAutomationModule -AutomationAccountName $automationAccountName -RuntimeVersion $runtimeVersion -ResourceGroupName $resourceGroupName -Name $moduleName -ContentLinkUri "https://www.powershellgallery.com/api/v2/package/$moduleName/$moduleVersion"

Importieren von Modulen aus dem PowerShell-Katalog

Sie können Module PowerShell-Katalog entweder direkt aus der Gallery oder aus Ihrem Automatisierungskonto importieren.

So importieren Sie ein Modul direkt aus dem PowerShell-Katalog:

1. Wechseln Sie zu https://www.powershellgallery.com, und suchen Sie nach dem zu importierenden Modul.
2. Wählen Sie unter Installationsoptionen auf der Registerkarte Azure AutomationDeploy to Azure Automation aus. Diese Aktion öffnet das Azure-Portal.
3. Wählen Sie auf der Seite „Importieren“ Ihr Automation-Konto und dann OK aus.

So importieren Sie ein PowerShell-Katalog Modul direkt aus Ihrem Automatisierungskonto:

1. Suchen Sie im Portal nach Automation-Konten, und wählen Sie diese Option aus.
2. Wählen Sie auf der Seite Automation-Konten in der entsprechenden Liste Ihr Automation-Konto aus.
3. Wählen Sie unter Freigegebene Ressourcen die Option Module aus.
4. Wählen Sie Katalog durchsuchen aus, und durchsuchen Sie dann den Katalog nach einem Modul.
5. Wählen Sie das zu importierende Modul und dann Importieren aus.
6. Wählen Sie OK aus, um den Importvorgang zu starten.

Löschen von Modulen

Wenn Sie Probleme mit einem Modul haben oder ein Rollback auf eine frühere Version eines Moduls ausführen müssen, können Sie es aus Ihrem Automation-Konto löschen. Die ursprünglichen Versionen von Standardmodulen, die beim Erstellen eines Automation-Kontos importiert werden, können nicht gelöscht werden. Wenn das zu löschende Modul eine neuere Version als die Standardmodule aufweist, wird ein Rollback auf die Version durchgeführt, die mit Ihrem Automation-Konto installiert wurde. Andernfalls werden alle Module, die Sie aus Ihrem Automation-Konto löschen, entfernt.

Löschen von Modulen im Azure-Portal

So entfernen Sie ein Modul im Azure Portal:

1. Suchen Sie im Portal nach Automation-Konten, und wählen Sie diese Option aus.
2. Wählen Sie auf der Seite Automation-Konten in der entsprechenden Liste Ihr Automation-Konto aus.
3. Wählen Sie unter Freigegebene Ressourcen die Option Module aus.
4. Wählen Sie das Modul aus, das Sie entfernen möchten.
5. Wählen Sie auf der Seite „Modul“ die Option Löschen aus. Handelt es sich bei dem Modul um eines der Standardmodule, wird ein Rollback auf die Version durchgeführt, die beim Erstellen des Automation-Kontos vorhanden war.

Löschen von Modulen mithilfe von PowerShell

Führen Sie zum Entfernen eines Moduls mithilfe von PowerShell den folgenden Befehl aus:

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

Nächste Schritte

• Weitere Informationen zur Verwendung von Azure PowerShell Modulen finden Sie unter Get started with Azure PowerShell.

• Weitere Informationen zum Erstellen von PowerShell-Modulen finden Sie unter Writing a Windows PowerShell module.

• Informationen zur Problembehandlung bei freigegebenen Ressourcen wie Azure PowerShell, Python, internen Cmdlets und benutzerdefinierten Modulen in Azure Automation finden Sie unter Troubleshoot Azure Automation Probleme mit freigegebenen Ressourcen.