Gerenciar módulos na Automação do Azure

Observação

A partir de 1º de fevereiro de 2025, a Automação do Azure descontinuará a execução de todos os runbooks que usam módulos do AzureRM. A partir de 1º de novembro de 2024, você não poderá criar novos runbooks usando módulos do AzureRM. O módulo AzureRM PowerShell foi oficialmente descontinuado em 29 de fevereiro de 2024. Recomendamos que você migre do módulo AzureRM para o módulo Az PowerShell para garantir suporte e atualizações contínuos. Embora o módulo AzureRM ainda possa funcionar, ele não é mais mantido ou suportado, e o uso continuado do módulo AzureRM é por conta e risco do usuário. Para obter mais informações, consulte recursos de migração para obter diretrizes sobre a transição para o módulo Az.

A Automação do Azure usa vários módulos do PowerShell para habilitar cmdlets em runbooks e recursos DSC em configurações DSC. Os módulos com suporte incluem:

• Az.Automation do Azure PowerShell.
• AzureRM.Automation do Azure PowerShell.
• Outros módulos do PowerShell.
• Módulo Orchestrator.AssetManagement.Cmdlets interno.
• Módulos Python 2.
• Módulos personalizados que você cria.

Quando você cria uma conta de Automação, a Automação do Azure importa alguns módulos por padrão. Consulte Módulos padrão.

Importante

A nova experiência de ambiente do Runtime permite que você gerencie módulos e pacotes, permitindo que você configure o ambiente de execução do trabalho. Na nova experiência, as folhas Módulos e Pacotes não estão disponíveis. Para gerenciar módulos e pacotes, consulte Gerenciar ambiente de Runtime e runbooks associados.

Áreas restritas

Quando a Automação executa trabalhos de runbook e compilação DSC, ela carrega os módulos para áreas restritas em que os runbooks podem ser executados e as configurações DSC podem ser compiladas. A Automação também insere automaticamente recursos DSC em módulos no servidor de pull DSC. Os computadores podem extrair os recursos quando aplicam as configurações DSC.

A área restrita de nuvem dá suporte a no máximo 48 chamadas do sistema e restringe todas as outras chamadas por motivos de segurança. Outras funcionalidades, como gerenciamento de credenciais e algumas redes, não são compatíveis na área restrita de nuvem.

Devido ao número de módulos e cmdlets incluídos, é difícil saber com antecedência quais dos cmdlets farão chamadas sem suporte. Em geral, vimos problemas com cmdlets que exigem acesso elevado, exigem uma credencial como um parâmetro ou cmdlets relacionados à rede. Não há suporte para cmdlets que executam operações de rede de pilha completa na área restrita, incluindo Connect-AipService do módulo AIPService do PowerShell e Resolve-DnsName do módulo DNSClient.

Essas são limitações conhecidas com a área restrita. A solução alternativa recomendada é implantar um Hybrid Runbook Worker ou usar Azure Functions.

Importante

Não inclua a palavra-chave "AzureRm" em nenhum script projetado para ser executado com o módulo Az. A inclusão da palavra-chave, mesmo em um comentário, pode fazer com que o AzureRm seja carregado e entre em conflito com o módulo Az.

Módulos padrão

Todas as novas contas de Automação têm a versão mais recente do módulo Az do PowerShell importada por padrão. O módulo Az substitui o AzureRM, e é o módulo recomendado para se usar com o Azure. Os Módulos padrão na nova conta de Automação incluem os 24 módulos AzureRM existentes e mais de 60 módulos Az.

Há uma opção nativa para o usuário atualizar módulos para o módulo Az para as contas de Automação. A operação manipulará todas as dependências do módulo no back-end, removendo assim os problemas de atualizar os módulos manualmente ou executar o runbook para atualizar os módulos do Azure.

Se a conta de Automação existente tiver apenas módulos AzureRM, a opção Atualizar módulos Az atualizará a conta de Automação com a versão do módulo Az selecionada pelo usuário.

Se a conta de Automação existente tiver o módulo AzureRM e alguns módulos Az, a opção importa os módulos Az restantes para a conta de Automação. Os módulos Az existentes terão preferência e a operação de atualização não atualizará esses módulos. Isso acontece para garantir que a operação de atualização do módulo não leve a nenhuma falha de execução de runbook devido à inadvertida atualização de um módulo que está sendo usado por um runbook. A maneira recomendada para esse cenário é, primeiro, excluir os módulos Az existentes e, em seguida, executar as operações de atualização para importar o módulo Az mais recente para a conta de Automação. Esses tipos de módulo, que não são importados por padrão, são chamados de Personalizados. Os módulos Personalizados sempre terão preferência sobre os módulos padrão.

Por exemplo: se você já tiver o módulo Az.Aksimportado com a versão 2.3.0, que é fornecida pelo módulo Az 6.3.0, e tentar atualizar o módulo Az para a versão 6.4.0 mais recente. A operação de atualização importará todos os módulos Az do pacote 6.4.0, exceto Az.Aks. Para ter a versão mais recente do Az.Aks, primeiro, exclua o módulo existente e, em seguida, execute a operação de atualização, ou você também pode atualizar esse módulo separadamente, conforme descrito em Importar módulos Az para importar uma versão diferente de um módulo específico.

A tabela a seguir lista os módulos que a Automação do Azure importa por padrão quando você cria sua conta de Automação. A Automação pode importar versões mais recentes desses módulos. No entanto, não é possível remover a versão original da sua conta de Automação, mesmo que você exclua uma versão mais recente.

Os módulos padrão também são conhecidos como módulos globais. No portal do Azure, a propriedade Módulo global será verdadeira ao exibir um módulo que foi importado quando a conta foi criada.

Observação

Não recomendamos alterar módulos e runbooks em contas de Automação usadas para a implantação de Iniciar/Parar VMs fora do horário comercial

Nome do módulo	Versão
Az.*	Consulte a lista completa em Detalhes do Pacote na Galeria do PowerShell
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

Cmdlets internos

A Automação do Azure dá suporte a cmdlets internos que só estão disponíveis quando você executa runbooks no ambiente de área restrita do Azure ou em um Hybrid Runbook Worker do Windows. O módulo interno Orchestrator.AssetManagement.Cmdlets é instalado por padrão na sua conta de Automação e quando a função Hybrid Runbook Worker do Windows é instalada no computador.

A tabela a seguir define os cmdlets internos. Esses cmdlets são criados para serem usados em vez de cmdlets do Azure PowerShell para interagir com seus recursos da conta de Automação. Eles podem recuperar segredos de variáveis criptografadas, credenciais e conexões criptografadas.

Nome	Descrição
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>]

Observe que os cmdlets internos diferem na nomenclatura dos cmdlets Az e AzureRM. Os nomes de cmdlet internos não contêm palavras como Azure ou Az no substantivo, mas usam a palavra Automation. Recomendamos usá-los, em vez de cmdlets AZ ou AzureRM, durante a execução do runbook em uma área restrita do Azure ou em um Hybrid Runbook Worker do Windows porque eles exigem menos parâmetros e são executados no contexto de seu trabalho durante a execução.

Use os cmdlets Az ou AzureRM para manipular recursos de Automação fora do contexto de um runbook.

Módulos Python

Você pode criar runbooks Python 2 na Automação do Azure. Para obter informações sobre o módulo Python, confira Gerenciar pacotes Python 2 na Automação do Azure.

Módulos personalizados

A Automação do Azure dá suporte a módulos personalizados do PowerShell que você cria para usar com seus runbooks e configurações DSC. Um tipo de módulo personalizado é um módulo de integração que, opcionalmente, contém um arquivo de metadados para definir a funcionalidade personalizada para os cmdlets do módulo. Um exemplo do uso de um módulo de integração é fornecido em Adicionar um tipo de conexão.

A Automação do Azure pode importar um módulo personalizado para disponibilizar os cmdlets dele. Nos bastidores, ela armazena o módulo e o usa nas áreas restritas do Azure, assim como faz com outros módulos.

Migrar para módulos Az

Esta ação informa como migrar para os módulos Az na Automação. Para obter mais informações, confira Migrar o Azure PowerShell do AzureRM para o Az.

Não recomendamos executar os módulos AzureRM e Az na mesma conta de Automação. Quando você tiver certeza de que deseja migrar do AzureRM para o Az, será melhor fazer commit completo para uma migração completa. A Automação geralmente reutiliza áreas restritas dentro da conta de Automação para economizar nos tempos de inicialização. Se você não fizer uma migração completa de módulo, poderá iniciar um trabalho que usa apenas módulos AzureRM e, em seguida, iniciar outro trabalho que usa apenas módulos Az. A área restrita logo falha e você recebe um erro informando que os módulos não são compatíveis. Essa situação resulta na ocorrência de falhas aleatoriamente para qualquer runbook ou configuração específica.

Observação

Quando você cria uma nova conta de Automação, mesmo após a migração para os módulos Az, a Automação instalará os módulos AzureRM por padrão.

Testar seus runbooks e configurações DSC antes da migração do módulo

Teste todos os runbooks e configurações DSC com cuidado, em uma conta de Automação separada, antes de migrar para os módulos Az.

Parar e desfazer o agendamento de todos os runbooks que usam os módulos AzureRM

Para verificar se você não executa nenhum runbook existente ou nenhuma configuração DSC que usa módulos AzureRM, você deve parar e cancelar o agendamento de todos os runbooks e configurações afetados. Primeiro, examine cada runbook ou configuração DSC e o agendamento separadamente para verificar se você pode reagendar o item no futuro, se necessário.

Quando você estiver pronto para remover seus agendamentos, poderá usar o portal do Azure ou o cmdlet Remove-AzureRmAutomationSchedule. Confira Remover um agendamento.

Remover módulos AzureRM

É possível remover os módulos AzureRM antes de importar os módulos Az. No entanto, se você fizer isso, poderá interromper a sincronização do controle do código-fonte e causar a falha de todos os scripts que ainda estiverem agendados. Se você decidir remover os módulos, confira Desinstalar AzureRM.

Importar módulos Az

Importar um módulo Az para sua conta de Automação não importa automaticamente o módulo para a sessão do PowerShell usada pelos runbooks. Os módulos são importados na sessão do PowerShell nas seguintes situações:

• Quando um runbook invoca um cmdlet de um módulo.
• Quando um runbook importa o módulo explicitamente com o cmdlet Import-Module.
• Quando um runbook importa o módulo explicitamente com o usando a instrução do módulo. A instrução using tem suporte a partir do Windows PowerShell 5.0 e dá suporte à importação de classes e tipo enumerado.
• Quando um runbook importa outro módulo dependente.

Você pode importar os módulos Az para a conta de Automação do portal do Azure. Como Az.Accounts é uma dependência para os outros módulos Az, importe esse módulo antes de qualquer outro.

Observação

Com a introdução do suporte ao PowerShell 7.1 (versão prévia), a opção Procurar na galeria foi atualizada com as seguintes alterações:

• Procurar na galeria está disponível na folha Automação do Processo>Módulos.
• A página Módulos exibe duas novas colunas – Versão do módulo e Versão do runtime

1. Entre no portal do Azure.

2. Pesquise e escolha Contas de Automação.

3. Na página Contas de Automação, escolha sua conta de Automação na lista.

4. Na sua conta de Automação, em Recursos Compartilhados, selecione Módulos.

5. Selecione Adicionar um módulo. Na página Adicionar um módulo, você pode selecionar uma das seguintes opções:

   1. Procurar arquivo – Seleciona um arquivo do computador local.
   2. Procurar na Galeria – Você pode procurar e selecionar um módulo existente na galeria.

6. Clique em Selecionar para escolher um módulo.

7. Selecione Versão do runtime e clique em Importar.

   

8. Na página Módulos, você pode ver o módulo importado na conta de Automação.

Você também pode fazer isso por meio da Galeria do PowerShell pesquisando o módulo a ser importado. Quando encontrar o módulo, selecione-o e escolha a guia Automação do Azure. Selecione Implantar na Automação do Azure.

Testar seus runbooks

Depois de importar os módulos Az para a conta de Automação, você poderá começar a editar seus runbooks e configurações DSC para usar os novos módulos. Uma forma de testar a modificação de um runbook usar os novos cmdlets é usando o comando Enable-AzureRmAlias -Scope Process no início do runbook. Ao adicionar esse comando ao seu runbook, o script poderá ser executado sem alterações.

Criar módulos

Recomendamos que você siga as considerações nesta seção ao criar um módulo do PowerShell personalizado para uso na Automação do Azure. Para preparar seu módulo para importação, você deve criar pelo menos um arquivo .dll do módulo .psd1, .psm1 ou do PowerShell com o mesmo nome que a pasta do módulo. Em seguida, você pode compactar a pasta do módulo para que a Automação do Azure possa importá-lo como um único arquivo. O pacote .zip deve ter o mesmo nome da pasta de módulo contida.

Para saber mais sobre como criar um módulo do PowerShell, confira Como gravar um módulo de script do PowerShell.

Pasta de versão

O controle de versão do módulo lado a lado do PowerShell permite usar mais de uma versão de um módulo no PowerShell. Isso pode ser útil se você tiver scripts mais antigos que foram testados e funcionam apenas em uma determinada versão de um módulo do PowerShell, mas outros scripts exigem uma versão mais recente do mesmo módulo do PowerShell.

Para construir módulos do PowerShell para que eles contenham várias versões, crie a pasta de módulo e, em seguida, crie uma pasta dentro dessa pasta de módulo para cada versão do módulo que você deseja que seja utilizável. No exemplo a seguir, um módulo chamado TestModule fornece duas versões: 1.0.0 e 2.0.0.

TestModule
   1.0.0
   2.0.0

Em cada uma das pastas de versão, copie os arquivos .dll . psm1,. psd1 do PowerShell ou do módulo do PowerShell que compõem um módulo na respectiva pasta de versão. Compacte a pasta do módulo para que a Automação do Azure possa importá-lo como um único arquivo .zip. Embora a Automação mostre apenas uma das versões do módulo importado, se o pacote de módulo contiver versões lado a lado do módulo, todas estarão disponíveis para uso em suas configurações DSC ou de runbooks.

Embora a Automação ofereça suporte a módulos que contêm versões lado a lado no mesmo pacote, ela não dá suporte ao uso de várias versões de um módulo em importações de pacote de módulo. Por exemplo, você importa o módulo A, que contém as versões 1 e 2 para sua conta de Automação. Posteriormente, você atualiza o módulo A para incluir as versões 3 e 4, quando você importa para sua conta de Automação, somente as versões 3 e 4 são utilizáveis nas configurações DSC ou de runbooks. Se você precisar que todas as versões-1, 2, 3 e 4 estejam disponíveis, o arquivo .zip importado deve conter as versões 1, 2, 3 e 4.

Se você pretende usar versões diferentes do mesmo módulo entre runbooks, você deve sempre declarar a versão que deseja usar em seu runbook usando o cmdlet Import-Module e incluir o parâmetro -RequiredVersion <version>. Mesmo que a versão que você deseja usar seja a versão mais recente. Isso ocorre porque os trabalhos do runbook podem ser executados na mesma área restrita. Se a área restrita já tiver carregado explicitamente um módulo de um determinado número de versão porque um trabalho anterior nessa área restrita instruiu para que isso fosse feito, os trabalhos futuros nessa área não carregarão automaticamente a versão mais recente desse módulo. Isso porque alguma versão dele já está carregada na área restrita.

Para um recurso de DSC, use o seguinte comando para especificar uma versão determinada:

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

Informações de ajuda

Incluem uma sinopse, uma descrição e um URI de ajuda para cada cmdlet no seu módulo. No PowerShell, você pode definir informações de ajuda para cmdlets usando o cmdlet Get-Help. O exemplo a seguir mostra como definir um URI de sinopse e ajuda em um arquivo de módulo .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
  }
}
}

Fornecer essas informações mostra o texto de ajuda por meio do cmdlet Get-Help no console do PowerShell. Esse texto também é exibido no portal do Azure.

Tipo de conexão

Se o módulo se conectar a um serviço externo, defina um tipo de conexão usando um módulo de integração personalizado. Cada cmdlet no módulo deve aceitar uma instância do mesmo tipo de conexão (objeto de conexão) que um parâmetro. Os usuários mapeiam parâmetros do ativo de conexão para os parâmetros correspondentes do cmdlet sempre que chamarem um cmdlet.

O exemplo de runbook a seguir usa um ativo de conexão da Contoso chamado ContosoConnection para acessar recursos da Contoso e retornar dados do serviço externo. Neste exemplo, os campos são mapeados para as propriedades UserName e Password de um objeto PSCredential e, em seguida, passados para o cmdlet.

$contosoConnection = Get-AutomationConnection -Name 'ContosoConnection'

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

Uma forma melhor e mais fácil de abordar esse comportamento é passando diretamente o objeto de conexão para o cmdlet:

$contosoConnection = Get-AutomationConnection -Name 'ContosoConnection'

Connect-Contoso -Connection $contosoConnection
}

Você pode habilitar um comportamento semelhante para seus cmdlets permitindo que eles aceitem um objeto de conexão diretamente como um parâmetro, em vez de apenas campos de conexão para parâmetros. Normalmente, convém ter um conjunto de parâmetros para cada um, para que um usuário que não esteja usando a Automação possa chamar seus cmdlets sem construir uma tabela de hash para agir como o objeto de conexão. O conjunto de parâmetros UserAccount é usado para passar as propriedades do campo de conexão. ConnectionObject permite que você passe a conexão diretamente.

Tipo de saída

Defina o tipo de saída para todos os cmdlets no módulo. A definição de um tipo de saída para um cmdlet permite o IntelliSense no tempo de design para ajudar você a determinar as propriedades de saída do cmdlet durante a criação. Essa prática é especialmente útil durante a criação do runbook gráfico, para o qual o conhecimento de tempo de design é fundamental para uma experiência do usuário fácil com seu módulo.

Adicione [OutputType([<MyOutputType>])], em que MyOutputType é um tipo válido. Para saber mais sobre OutputType, confira Sobre Funções OutputTypeAttribute. O seguinte código é um exemplo de como adicionar OutputType a um cmdlet:

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

Esse comportamento é semelhante à funcionalidade "preenchimento automático" da saída de um cmdlet no ambiente de serviço de integração do PowerShell, sem precisar executá-lo.

Estado do cmdlet

Torne todos os cmdlets em seu módulo sem estado. Vários trabalhos de runbook podem ser executados simultaneamente no mesmo AppDomain e no mesmo processo e área restrita. Se houver qualquer estado compartilhado nesses níveis, os trabalhos poderão afetar uns aos outros. Esse comportamento pode levar a problemas intermitentes e difíceis de diagnosticar. Veja um exemplo do que não fazer:

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

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

   $output
}

Dependência do módulo

Verifique se o módulo está totalmente contido em um pacote que pode ser copiado usando xcopy. Os módulos da Automação são distribuídos para as áreas restritas da Automação quando os runbooks são executados. Os módulos devem funcionar independentemente do host que os executa.

Você deve poder compactar e mover um pacote de módulo e ele deve funcionar normalmente quando importado para outro ambiente do PowerShell do host. Para que isso aconteça, verifique se o módulo não depende de nenhum arquivo fora da pasta do módulo que é compactada quando o módulo é importado para a Automação.

Seu módulo não deve depender de nenhuma configuração de Registro exclusiva em um host. Os exemplos são as configurações feitas quando um produto é instalado.

Caminhos de arquivo do módulo

Verifique se todos os arquivos no módulo têm caminhos com menos de 140 caracteres. Caminhos com mais de 140 caracteres causam problemas com a importação runbooks. A Automação não pode importar um arquivo com tamanho de caminho maior que 140 caracteres para a sessão do PowerShell com Import-Module.

Importar módulos

Esta seção define várias maneiras como você pode importar um módulo para sua conta de Automação.

Importar módulos no portal do Azure

Para importar um módulo no portal do Azure:

1. No portal do Azure, procure e selecione Contas de Automação.
2. Na página Contas de Automação, selecione sua conta de Automação na lista.
3. Em Recursos Compartilhados, selecione Módulos.
4. Selecione Adicionar um módulo.
5. Selecione o arquivo .zip que contém o módulo.
6. Selecione OK para começar a importar o processo.

Importar módulos usando o PowerShell

Você pode usar o cmdlet New-AzAutomationModule para importar um módulo para sua conta de Automação. O cmdlet usa a URL para um pacote .zip do módulo.

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

Você também pode usar o mesmo cmdlet para importar um módulo da Galeria do PowerShell diretamente. Pegue ModuleName e ModuleVersion da Galeria do PowerShell.

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

Importar módulos da Galeria do PowerShell

Você pode importar módulos da Galeria do PowerShell diretamente da Galeria ou da sua conta de Automação.

Para importar um módulo diretamente da Galeria do PowerShell:

1. Acesse https://www.powershellgallery.com e procure o módulo para importar.
2. Em Opções de Instalação, na guia Automação do Azure, selecione Implantar na Automação do Azure. Essa ação abre o portal do Azure.
3. Na página Importar, selecione sua conta de Automação e OK.

Para importar um módulo da Galeria do PowerShell diretamente da sua conta de Automação:

1. No portal do Azure, procure e selecione Contas de Automação.
2. Na página Contas de Automação, selecione sua conta de Automação na lista.
3. Em Recursos Compartilhados, selecione Módulos.
4. Selecione Procurar na galeria e, em seguida, pesquise na Galeria um módulo.
5. Selecione o módulo a ser importado e selecione Importar.
6. Selecione OK para iniciar o processo de importação.

Excluir módulos

Se você tiver problemas com um módulo ou precisar reverter para uma versão anterior de um módulo, poderá excluí-lo da sua conta de Automação. Não é possível excluir as versões originais dos módulos padrão importados quando você cria uma conta de Automação. Se o módulo a ser excluído for uma versão mais recente de um dos módulos padrão, ele será revertido para a versão que foi instalada com sua conta de Automação. Caso contrário, qualquer módulo que você excluir da sua conta de Automação será removido.

Excluir módulos no portal do Azure

Para remover um módulo no portal do Azure:

1. No portal do Azure, procure e selecione Contas de Automação.
2. Na página Contas de Automação, selecione sua conta de Automação na lista.
3. Em Recursos Compartilhados, selecione Módulos.
4. Selecione o módulo que você deseja remover.
5. Na página Módulo, selecione Excluir. Se esse módulo for um dos módulos padrão, ele será revertido para a versão que existia quando a conta de Automação foi criada.

Excluir módulos usando o PowerShell

Para remover um módulo por meio do PowerShell, execute o seguinte comando:

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

Próximas etapas

• Para obter mais informações sobre como usar os módulos do Azure PowerShell, veja Introdução ao Azure PowerShell.

• Para saber mais sobre como criar os módulos do PowerShell, veja Escrevendo um módulo do Windows PowerShell.