Gestire i moduli in Automazione di Azure

Automazione di Azure usa alcuni moduli di PowerShell per abilitare i cmdlet nei runbook e nelle risorse DSC nelle configurazioni DSC. I moduli supportati includono:

• Az.Automation di Azure PowerShell.
• AzureRM.Automation di Azure PowerShell.
• Altri moduli di PowerShell.
• Modulo Orchestrator.AssetManagement.Cmdlets interno.
• Moduli Python 2.
• Moduli personalizzati creati dall'utente.

Quando si crea un account di Automazione, Automazione di Azure importa alcuni moduli per impostazione predefinita. Vedere Moduli predefiniti.

Sandbox

Quando Automazione esegue runbook e processi di compilazione DSC, carica i moduli in sandbox in cui è possibile eseguire i runbook e la compilazione di configurazioni DSC. Automazione inserisce automaticamente anche eventuali risorse DSC nei moduli nel server di pull DSC. I computer possono effettuare il pull delle risorse quando applicano le configurazioni DSC.

La sandbox cloud supporta un massimo di 48 chiamate di sistema e limita tutte le altre chiamate per motivi di sicurezza. Altre funzionalità, ad esempio la gestione delle credenziali e alcune funzionalità di rete, non sono supportate nella sandbox cloud.

A causa del numero di moduli e cmdlet inclusi, è difficile sapere in anticipo quale dei cmdlet eseguirà chiamate non supportate. In genere si sono riscontrati problemi con i cmdlet che richiedono l'accesso con privilegi elevati, richiedono credenziali come parametro o cmdlet correlati alla rete. Tutti i cmdlet che eseguono operazioni di rete full stack non sono supportati nella sandbox, inclusi Connessione-AipService dal modulo PowerShell AIPService e Resolve-DnsName dal modulo DNSClient.

Si tratta di limitazioni note con la sandbox. La soluzione alternativa consigliata consiste nel distribuire un ruolo di lavoro ibrido per runbook o usare Funzioni di Azure.

Importante

Non includere la parola chiave "AzureRm" in uno script progettato per l'esecuzione con il modulo Az. L'inclusione della parola chiave, anche in un commento, può causare il caricamento di AzureRm e quindi il conflitto con il modulo Az.

Moduli predefiniti

Tutti i nuovi account di Automazione hanno la versione più recente del modulo Az di PowerShell importato per impostazione predefinita. Il modulo Az sostituisce AzureRM ed è il modulo consigliato da usare con Azure. I moduli predefiniti nel nuovo account di Automazione includono i moduli AzureRM esistenti e 60 moduli Az esistenti.

È disponibile un'opzione nativa per aggiornare i moduli al modulo Az più recente dall'utente per gli account di Automazione. L'operazione gestirà tutte le dipendenze del modulo nel back-end, eliminando così i problemi di aggiornamento manuale dei moduli o eseguendo il runbook per aggiornare i moduli di Azure.

Se l'account di Automazione esistente include solo moduli AzureRM, l'opzione Aggiorna moduli Az aggiornerà l'account di Automazione con la versione selezionata dall'utente del modulo Az.

Se l'account di Automazione esistente include AzureRM e alcuni moduli Az, l'opzione importerà i moduli Az rimanenti nell'account di Automazione. I moduli Az esistenti avranno la preferenza e l'operazione di aggiornamento non aggiornerà tali moduli. Ciò consente di assicurarsi che l'operazione del modulo di aggiornamento non comporti alcun errore di esecuzione del runbook aggiornando inavvertitamente un modulo usato da un runbook. Il modo consigliato per questo scenario consiste innanzitutto nell'eliminare i moduli Az esistenti e quindi eseguire le operazioni di aggiornamento per ottenere l'ultima importazione del modulo Az nell'account di Automazione. Tali tipi di modulo, non importati per impostazione predefinita, sono denominati Custom. I moduli personalizzati avranno sempre la preferenza rispetto ai moduli predefiniti .

Ad esempio: se il Az.Aks modulo è già stato importato con la versione 2.3.0 fornita dal modulo Az 6.3.0 e si prova ad aggiornare il modulo Az alla versione 6.4.0 più recente. L'operazione di aggiornamento importerà tutti i moduli Az dal pacchetto 6.4.0, ad eccezione di Az.Aks. Per avere la versione più recente di Az.Aks, eliminare prima il modulo esistente e quindi eseguire l'operazione di aggiornamento oppure è anche possibile aggiornare questo modulo separatamente come descritto in Importare moduli Az per importare una versione diversa di un modulo specifico.

La tabella seguente elenca i moduli che Automazione di Azure importa per impostazione predefinita quando si crea l'account di Automazione. Automazione può importare versioni più recenti di questi moduli. Non è tuttavia possibile rimuovere la versione originale dall'account di Automazione, anche se si elimina la versione più recente.

I moduli predefiniti sono noti anche come moduli globali. Nella portale di Azure la proprietà Global module sarà vera quando si visualizza un modulo importato al momento della creazione dell'account.

Nota

Si sconsiglia di modificare moduli e runbook negli account di Automazione usati per la distribuzione della funzionalità Avvio/Arresto di macchine virtuali durante gli orari di minore attività.

Nome del modulo	Versione
Az.*	Vedere l'elenco completo in Dettagli pacchetto in PowerShell Gallery
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

Cmdlet interni

Automazione di Azure supporta i cmdlet interni disponibili solo quando si eseguono runbook nell'ambiente sandbox di Azure o in un ruolo di lavoro ibrido per runbook di Windows. Il modulo Orchestrator.AssetManagement.Cmdlets interno viene installato per impostazione predefinita nell'account di Automazione e quando il ruolo di lavoro ibrido per runbook di Windows è installato nel computer.

La tabella seguente definisce i cmdlet interni. Questi cmdlet sono progettati per essere usati al posto dei cmdlet di Azure PowerShell per interagire con le risorse dell'account di Automazione. Possono recuperare i segreti da variabili crittografate, credenziali e connessioni crittografate.

Nome	Descrizione
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>]

Si noti che i cmdlet interni differiscono per denominazione dai cmdlet Az e AzureRM. I nomi dei cmdlet interni non contengono parole come Azure o Az, ma usano la parola Automation. È consigliabile usare i cmdlet Az o AzureRM durante l'esecuzione del runbook in una sandbox di Azure o in un ruolo di lavoro ibrido per runbook di Windows perché richiedono un minor numero di parametri ed essere eseguiti nel contesto del processo durante l'esecuzione.

Usare i cmdlet Az o AzureRM per modificare le risorse di Automazione al di fuori del contesto di un runbook.

Moduli Python

È possibile creare runbook Python 2 in Automazione di Azure. Per informazioni sui moduli Python, vedere Gestire pacchetti Python 2 in Automazione di Azure.

Moduli personalizzati

Automazione di Azure supporta moduli di PowerShell personalizzati creati per l'uso con i runbook e le configurazioni DSC. Un tipo di modulo personalizzato è un modulo di integrazione che contiene facoltativamente un file di metadati per definire la funzionalità personalizzata per i cmdlet del modulo. Un esempio di uso di un modulo di integrazione è disponibile in Aggiungere un tipo di connessione.

Automazione di Azure può importare un modulo personalizzato per rendere disponibili i relativi cmdlet. Dietro le quinte, archivia il modulo e lo usa nelle sandbox di Azure, proprio come gli altri moduli.

Eseguire la migrazione a moduli Az

Questa sezione illustra come eseguire la migrazione ai moduli Az in Automazione. Per altre informazioni, vedere Eseguire la migrazione di Azure PowerShell da AzureRM ad Az.

Si sconsiglia di eseguire i moduli AzureRM e i moduli Az nello stesso account di Automazione. Quando si è sicuri di voler eseguire la migrazione da AzureRM ad Az, è consigliabile effettuare una migrazione completa. Automazione riutilizza spesso sandbox all'interno dell'account di Automazione per ridurre i tempi di avvio. Se non si esegue la migrazione completa dei moduli, è possibile che si avvii un processo che usa solo moduli AzureRM e quindi un altro che usa solo moduli Az. La sandbox si arresta presto in modo anomalo e viene visualizzato un errore che informa che i moduli non sono compatibili. Questa situazione comporta arresti anomali casuali per un runbook o una configurazione particolare.

Nota

Quando si crea un nuovo account di Automazione, anche dopo la migrazione ai moduli Az, Automazione installerà comunque i moduli AzureRM per impostazione predefinita.

Testare i runbook e le configurazioni DSC prima della migrazione dei moduli

Assicurarsi di testare attentamente tutti i runbook e le configurazioni DSC in un account di Automazione separato prima di eseguire la migrazione ai moduli Az.

Arrestare e annullare la pianificazione di tutti i runbook che usano moduli AzureRM

Per assicurarsi di non eseguire runbook o configurazioni DSC esistenti che usano moduli AzureRM, è necessario arrestare e annullare la pianificazione di ogni runbook e configurazione interessati. Assicurarsi prima di tutto di esaminare ogni runbook o configurazione DSC e le relative pianificazioni separatamente, per verificare che sia possibile ripianificare l'elemento in futuro, se necessario.

Quando si è pronti per rimuovere le pianificazioni, è possibile usare il portale di Azure o il cmdlet Remove-AzureRmAutomationSchedule. Vedere Rimuovere una pianificazione.

Rimuovere i moduli AzureRM

È possibile rimuovere i moduli AzureRM prima di importare i moduli Az. Se tuttavia si esegue questa operazione, è possibile interrompere la sincronizzazione del controllo del codice sorgente e causare la mancata esecuzione di script ancora pianificati. Se si decide di rimuovere i moduli, vedere Disinstallare AzureRM.

Importare moduli Az

L'importazione di un modulo Az nell'account di Automazione non comporta automaticamente l'importazione del modulo nella sessione di PowerShell usata dai runbook. I moduli vengono importati nella sessione di PowerShell nelle situazioni seguenti:

• Quando un runbook richiama un cmdlet da un modulo.
• Quando un runbook importa il modulo in modo esplicito con il cmdlet Import-Module.
• Quando un runbook importa il modulo in modo esplicito con l'istruzione using module . L'istruzione using è supportata a partire da Windows PowerShell 5.0 e supporta le classi e l'importazione dei tipi di enumerazione.
• Quando un runbook importa un altro modulo dipendente.

È possibile importare i moduli Az nell'account di Automazione dal portale di Azure. Az.Accounts è una dipendenza per gli altri moduli Az, quindi assicurarsi di importare questo modulo prima di qualsiasi altro.

Nota

Con l'introduzione del supporto di PowerShell 7.1 (anteprima), l'opzione Sfoglia raccolta è stata aggiornata con le modifiche seguenti:

• Esplora raccolta è disponibile nel pannello Moduli di automazione>dei processi.
• Nella pagina Moduli vengono visualizzate due nuove colonne: versione del modulo e versione di runtime

1. Accedi al portale di Azure.

2. Cercare e selezionare Account di Automazione.

3. Nella pagina Account di automazione selezionare l'account di Automazione dall'elenco.

4. Dall'account di Automazione selezionare Moduli in Risorse condivise.

5. Selezionare Aggiungere un modulo. Nella pagina Aggiungi un modulo è possibile selezionare una delle opzioni seguenti:

   1. Cerca file : seleziona un file dal computer locale.
   2. Sfoglia da Raccolta : è possibile esplorare e selezionare un modulo esistente dalla raccolta.

6. Fare clic su Seleziona per selezionare un modulo.

7. Selezionare Versione di runtime e fare clic su Importa.

   

8. Nella pagina Moduli è possibile visualizzare il modulo importato nell'account di Automazione.

Questa operazione può anche essere eseguita tramite PowerShell Gallery, cercando il modulo da importare. Quando si trova il modulo, selezionarlo e scegliere la scheda Automazione di Azure. Selezionare Distribuisci in Automazione di Azure.

Testare i runbook

Dopo aver importato i moduli Az nell'account di Automazione, è possibile iniziare a modificare i runbook e le configurazioni DSC per l'uso dei nuovi moduli. Un modo per testare la modifica di un runbook per l'uso dei nuovi cmdlet consiste nell'usare il comando Enable-AzureRmAlias -Scope Process all'inizio del runbook. Aggiungendo questo comando al runbook, lo script può essere eseguito senza modifiche.

Creare moduli

Si consiglia di seguire le considerazioni in questa sezione quando si crea un modulo PowerShell personalizzato da usare in Automazione di Azure. Per preparare il modulo per l'importazione, è necessario creare almeno un file con estensione psd1, psm1 o dll del modulo di PowerShell con lo stesso nome della cartella del modulo. Comprimere quindi la cartella del modulo in modo che Automazione di Azure possa importarlo come singolo file. Il pacchetto ZIP deve avere lo stesso nome della cartella del modulo contenuta.

Per altre informazioni sulla creazione di un modulo di PowerShell, vedere Come scrivere un modulo di script di PowerShell.

Cartella delle versioni

Il controllo delle versioni side-by-side di PowerShell consente di usare più versioni di un modulo in PowerShell. Ciò può essere utile se si dispone di script meno recenti testati e che funzionano solo con una determinata versione di un modulo di PowerShell, ma altri script richiedono una versione più recente dello stesso modulo di PowerShell.

Per costruire moduli di PowerShell in modo che contengano più versioni, creare la cartella del modulo e quindi creare una cartella all'interno di questa cartella del modulo per ogni versione del modulo che si vuole usare. Nell'esempio seguente un modulo denominato TestModule fornisce due versioni, 1.0.0 e 2.0.0.

TestModule
   1.0.0
   2.0.0

All'interno di ognuna delle cartelle delle versioni copiare i file DLL del modulo powerShell con estensione psm1, psd1 o PowerShell che costituiscono un modulo nella rispettiva cartella della versione. Comprimere la cartella del modulo in modo che Automazione di Azure possa importarla come singolo file ZIP. Anche se Automazione mostra solo la versione più recente del modulo importato, se il pacchetto del modulo contiene versioni side-by-side del modulo, sono tutti disponibili per l'uso nei runbook o nelle configurazioni DSC.

Anche se Automazione supporta moduli contenenti versioni side-by-side all'interno dello stesso pacchetto, non supporta l'uso di più versioni di un modulo tra le importazioni di pacchetti di moduli. Ad esempio, si importa il modulo A, che contiene le versioni 1 e 2 nell'account di Automazione. Successivamente si aggiorna il modulo A per includere le versioni 3 e 4, quando si importa nell'account di Automazione, solo le versioni 3 e 4 sono utilizzabili all'interno di runbook o configurazioni DSC. Se è necessario che tutte le versioni - 1, 2, 3 e 4 siano disponibili, il file ZIP che l'importazione deve contenere versioni 1, 2, 3 e 4.

Se si intende usare versioni diverse dello stesso modulo tra runbook, è necessario dichiarare sempre la versione che si vuole usare nel runbook usando il Import-Module cmdlet e includere il parametro -RequiredVersion <version>. Anche se la versione da usare è la versione più recente. Ciò è dovuto al fatto che i processi runbook possono essere eseguiti nella stessa sandbox. Se la sandbox ha già caricato in modo esplicito un modulo di un determinato numero di versione, perché un processo precedente in tale sandbox ha detto di farlo, i processi futuri in tale sandbox non caricheranno automaticamente la versione più recente di tale modulo. Ciò è dovuto al fatto che alcune versioni di sono già caricate nella sandbox.

Per una risorsa DSC, usare il comando seguente per specificare una versione specifica:

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

Informazioni della Guida

Includere un riepilogo, una descrizione e un URI della Guida per ogni cmdlet del modulo. In PowerShell è possibile definire le informazioni della Guida per i cmdlet usando il cmdlet Get-Help. L'esempio seguente illustra come definire un riepilogo e un URI della Guida in un file di modulo con estensione psm1.

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

Fornendo queste informazioni viene visualizzato il testo della Guida tramite il cmdlet Get-Help nella console di PowerShell. Questo testo viene visualizzato anche nel portale di Azure.

Connection type

Se il modulo si connette a un servizio esterno, definire un tipo di connessione usando un modulo di integrazione personalizzato. Ogni cmdlet del modulo deve accettare un'istanza del tipo di connessione (oggetto di connessione) come parametro. Gli utenti eseguono il mapping dei parametri dell'asset della connessione ai parametri del cmdlet corrispondenti ogni volta che chiamano un cmdlet.

Nell'esempio di runbook seguente si usa un asset di connessione Contoso denominato ContosoConnection per accedere alle risorse di Contoso e restituire i dati dal servizio esterno. In questo esempio, i campi vengono mappati alle proprietà UserName e Password di un oggetto PSCredential e quindi passati al cmdlet.

$contosoConnection = Get-AutomationConnection -Name 'ContosoConnection'

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

Un approccio più semplice ed efficiente a questo comportamento consiste nel passare direttamente l'oggetto connessione al cmdlet:

$contosoConnection = Get-AutomationConnection -Name 'ContosoConnection'

Connect-Contoso -Connection $contosoConnection
}

È possibile abilitare un comportamento simile per i cmdlet consentendo loro di accettare direttamente un oggetto di connessione come parametro, anziché soltanto i campi di connessione per i parametri. È in genere consigliabile che sia presente un set di parametri per ognuno, in modo che un utente che non usa Automazione possa chiamare i cmdlet senza costruire una tabella hash che funga da oggetto di connessione. Il set di parametri UserAccount viene usato per passare le proprietà dei campi di connessione. ConnectionObject consente di passare direttamente la connessione.

Tipo di output

Definire il tipo di output per tutti i cmdlet nel modulo. Definendo un tipo di output per un cmdlet, IntelliSense in fase di progettazione consente di determinare le proprietà di output del cmdlet durante la creazione. Questa prassi è particolarmente utile durante la creazione di runbook grafici, in cui la conoscenza in fase di progettazione è essenziale per semplificare l'esperienza dell'utente con il modulo.

Aggiungere [OutputType([<MyOutputType>])], dove MyOutputType è un tipo valido. Per altre informazioni su OutputType, vedere Informazioni sulle funzioni OutputTypeAttribute. Il codice seguente è un esempio di aggiunta di OutputType a un cmdlet:

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

Questo comportamento è simile alla funzionalità di "completamento automatico" dell'output di un cmdlet nell'ambiente del servizio di integrazione PowerShell, senza che sia necessario eseguirlo.

Stato del cmdlet

Assicurarsi che tutti i cmdlet del modulo siano senza stato. Più processi Runbook possono essere eseguiti contemporaneamente nello stesso AppDomain, nello stesso processo e nella stessa sandbox. Se è presente uno stato condiviso in questi livelli, i processi possono interferire tra loro. Questo comportamento può causare problemi intermittenti e difficili da diagnosticare. Di seguito è riportato un esempio della soluzione da non adottare:

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

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

   $output
}

Dipendenza del modulo

Verificare che il modulo sia completamente contenuto in un pacchetto che può essere copiato tramite xcopy. I moduli di Automazione vengono distribuiti nelle sandbox di Automazione quando vengono eseguiti i runbook. I moduli devono funzionare indipendentemente dall'host che li esegue.

Dovrebbe essere possibile comprimere un pacchetto del modulo e spostarlo, facendo in modo che funzioni normalmente dopo l'importazione nell'ambiente PowerShell di un altro host. A questo scopo, verificare che il modulo non dipenda da file esterni alla cartella del modulo compresso quando il modulo viene importato in Automazione.

Il modulo non deve dipendere da impostazioni univoche del Registro di sistema in un host. Esempi sono le impostazioni che vengono eseguite quando si installa un prodotto.

Percorsi dei file del modulo

Verificare che tutti i file del modulo abbiano percorsi con meno di 140 caratteri. Qualsiasi percorso con lunghezza superiore a 140 caratteri provoca problemi di importazione dei runbook. Automazione non può importare nella sessione di PowerShell un file con una dimensione del percorso superiore a 140 caratteri con Import-Module.

Importare i moduli

Questa sezione definisce diversi modi in cui è possibile importare un modulo nell'account di Automazione.

Importare i moduli nel portale di Azure

Per importare un modulo nel portale di Azure:

1. Nel portale cercare e selezionare Account di Automazione.
2. Nella pagina Account di automazione selezionare l'account di Automazione dall'elenco.
3. In Risorse condivise selezionare Moduli.
4. Selezionare Aggiungere un modulo.
5. Selezionare il file ZIP che contiene il modulo.
6. Selezionare OK per iniziare a importare il processo.

Importare i moduli usando PowerShell

È possibile usare il cmdlet New-AzAutomationModule per importare un modulo nell'account di Automazione. Il cmdlet accetta un URL per un pacchetto ZIP del modulo.

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

È anche possibile usare lo stesso cmdlet per importare un modulo direttamente da PowerShell Gallery. Assicurarsi di selezionare ModuleName e ModuleVersion da PowerShell Gallery.

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

Importare moduli da PowerShell Gallery

È possibile importare moduli di PowerShell Gallery direttamente dalla Gallery o dal proprio account di Automazione.

Per importare un modulo direttamente da PowerShell Gallery:

1. Passare a https://www.powershellgallery.com e cercare il modulo da importare.
2. Selezionare Distribuisci in Automazione di Azure nella scheda Automazione di Azure in Opzioni di installazione. Verrà aperto il portale di Azure.
3. Nella pagina Importa selezionare l'account di Automazione e selezionare OK.

Per importare un modulo di PowerShell Gallery direttamente dall'account di Automazione:

1. Nel portale cercare e selezionare Account di Automazione.
2. Nella pagina Account di automazione selezionare l'account di Automazione dall'elenco.
3. In Risorse condivise selezionare Moduli.
4. Selezionare Esplora raccolta, quindi cercare un modulo nella raccolta.
5. Selezionare il modulo da importare e selezionare Importa.
6. Selezionare OK per avviare il processo di importazione.

Eliminare moduli

Se si verificano problemi con un modulo oppure è necessario eseguire il rollback a una versione precedente di un modulo, è possibile eliminare il modulo dall'account di Automazione. Non è possibile eliminare le versioni originali dei moduli predefiniti importati quando si crea un account di Automazione. Se il modulo da eliminare è una versione più recente di uno dei moduli predefiniti, viene eseguito il rollback alla versione installata con l'account di Automazione. In caso contrario viene rimosso qualsiasi modulo eliminato dall'account di Automazione.

Eliminare i moduli nel portale di Azure

Per rimuovere un modulo nel portale di Azure:

1. Nel portale cercare e selezionare Account di Automazione.
2. Nella pagina Account di automazione selezionare l'account di Automazione dall'elenco.
3. In Risorse condivise selezionare Moduli.
4. Selezionare il modulo che si vuole rimuovere.
5. Nella pagina modulo selezionare Elimina. Se questo modulo è uno dei moduli predefiniti, viene eseguito il rollback alla versione esistente al momento della creazione dell'account di Automazione.

Eliminare i moduli usando PowerShell

Per rimuovere un modulo tramite PowerShell, eseguire questo comando:

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

Passaggi successivi

• Per altre informazioni sull'uso dei moduli di Azure PowerShell, vedere Introduzione ad Azure PowerShell.

• Per altre informazioni sulla creazione di moduli di PowerShell, vedere Scrittura di un modulo di Windows PowerShell.