Tipos de runbook da Automação do Azure

Limitações

• Na versão de runtime 7.2 do PowerShell, as atividades do módulo não são extraídas para os módulos importados. Use a extensão de Automação do Azure para código VS para simplificar a experiência de criação de runbook.
• O PowerShell 7.x não dá suporte a fluxos de trabalho. Para obter mais informações, consulte o fluxo de trabalho do PowerShell para obter mais detalhes.
• No momento, o PowerShell 7.x não dá suporte a runbooks assinados.
• A integração do controle do código-fonte não dá suporte ao PowerShell 7.2. Além disso, os runbooks do PowerShell 7.2 no controle do código-fonte são criados na conta de Automação como Runtime 5.1.
• O módulo Az 8.3.0 é instalado por padrão. A lista completa de módulos de componente da versão do módulo Az selecionada é mostrada quando a versão do Az é configurada novamente usando o portal ou a API do Azure.
• O módulo importado do PowerShell 7.2 seria validado durante a execução do trabalho. Verifique se todas as dependências do módulo selecionado também foram importadas para uma execução bem-sucedida do trabalho.
• O runbook do Azure não dá suporte a Start-Job com -credential.
• O Azure não dá suporte a todos os parâmetros de entrada do PowerShell. Saiba mais.

Problemas conhecidos

• Runbooks que assumem dependência em caminhos de arquivo internos, como C:\modules podem falhar devido a alterações na infraestrutura de back-end de serviço. Altere o código do runbook para garantir que não haja dependências em caminhos de arquivo internos e use Get-ChildItem para obter as informações necessárias do módulo.

• O cmdlet Get-AzStorageAccount pode falhar com um erro: O comando Get-AzStorageAccount foi encontrado no módulo Az.Storage, mas o módulo não pôde ser carregado.

• Não há suporte para a execução de scripts filho usando .\child-runbook.ps1.
  Solução alternativa: use Start-AutomationRunbook (cmdlet interno) ou Start-AzAutomationRunbook (do módulo Az.Automation) para iniciar outro runbook a partir do runbook pai.

• Ao usar o módulo ExchangeOnlineManagement versão 3.0.0 ou superior, você pode enfrentar erros. Para resolver o problema, certifique-se de carregar explicitamente os módulos PowerShellGet e PackageManagement.

• Quando você utiliza o cmdlet New-AzAutomationVariable no Módulo Az.Automation para carregar uma variável do tipo objeto, a operação não funciona como esperado.

  Solução alternativa: Converta o objeto em uma cadeia de caracteres JSON usando o cmdlet ConvertTo-Json e, em seguida, carregue a variável com a cadeia de caracteres JSON como seu valor. Essa solução alternativa garante o tratamento adequado da variável no ambiente da Automação do Azure como uma cadeia de caracteres JSON.

  Exemplo - Criar um objeto do PowerShell que tenha armazenado informações sobre VMs do Azure

    # Retrieve Azure virtual machines with status information for the 'northeurope' region 
    $AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"} 
  
    $VMstopatch = @($AzVM).Id 
    # Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch 
  
    # Convert the object to a JSON string 
    $jsonString = $VMstopatch | ConvertTo-Json 
  
    # Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString 
  

Limitações

• Os runbooks não usam processamento paralelo para executar várias ações paralelamente.
• Os runbooks não usam pontos de verificação para retomar o runbook em caso de erro.
• Só é possível incluir os runbooks do PowerShell, do Fluxo de Trabalho do PowerShell e os runbooks gráficos como runbooks filhos usando o cmdlet Start-AzAutomationRunbook, que cria um novo trabalho.
• Os runbooks não podem usar a instrução #Requires do PowerShell, pois ela não tem suporte na área restrita do Azure e nem no Hybrid Runbook Workers, e pode levar o trabalho a falhar.
• O runbook do Azure não dá suporte a Start-Job com -credential.
• O Azure não dá suporte a todos os parâmetros de entrada do PowerShell. Saiba mais.

Problemas conhecidos

• Runbooks que assumem dependência em caminhos de arquivo internos, como C:\modules podem falhar devido a alterações na infraestrutura de back-end de serviço. Altere o código do runbook para garantir que não haja dependências em caminhos de arquivo internos e use Get-ChildItem para obter as informações necessárias do módulo.

  Exemplo de script

  
  # Get information about module "Microsoft.Graph.Authentication"
  $ModuleName = "Microsoft.Graph.Authentication"
  
  $NewPath = "C:\usr\src\PSModules\$ModuleName"
  $OldPath = "C:\Modules\User\$ModuleName"
  
  if (Test-Path -Path $NewPath -PathType Container) {
      Get-ChildItem -Path $NewPath
  } elseif (Test-Path -Path $OldPath -PathType Container) {
      Get-ChildItem -Path $OldPath
  } else {
      Write-Output "Module $ModuleName not present."
  }
  # Getting the path to the Temp folder, if needed.
  $tmp = $env:TEMP
  
  

• O cmdlet Get-AzStorageAccount pode falhar com um erro: O comando Get-AzStorageAccount foi encontrado no módulo Az.Storage, mas o módulo não pôde ser carregado.

• Os runbooks do PowerShell não conseguem recuperar um ativo variável não criptografado com um valor nulo.

• Os runbooks do PowerShell não conseguem recuperar um ativo variável com *~* no nome.

• Uma operação Get-Process em um loop dentro de um runbook do PowerShell pode falhar após cerca de 80 iterações.

• Um runbook do PowerShell pode falhar se tentar gravar uma grande quantidade de dados no fluxo de saída de uma só vez. Geralmente, você pode contornar esse problema fazendo com que o runbook emita apenas as informações necessárias para trabalhar com objetos grandes. Por exemplo, em vez de usar Get-Process sem limitações, faça com que o cmdlet gere apenas os parâmetros necessários como em Get-Process | Select ProcessName, CPU.

• Ao usar o módulo ExchangeOnlineManagement versão 3.0.0 ou superior, você pode enfrentar erros. Para resolver o problema, verifique se você também carrega explicitamente os módulos PowerShellGet e PackageManagement.

• Se você importar o módulo Az.Accounts com a versão 2.12.3 ou mais recente, certifique-se de importar o módulo v10 Newtonsoft.Json explicitamente se os runbooks do PowerShell 5.1 tiverem uma dependência nesta versão do módulo. A solução alternativa para esse problema é usar runbooks do PowerShell 7.2.

• Quando você utiliza o cmdlet New-AzAutomationVariable no Módulo Az.Automation para carregar uma variável do tipo objeto, a operação não funciona como esperado.

  Solução alternativa: Converta o objeto em uma cadeia de caracteres JSON usando o cmdlet ConvertTo-Json e, em seguida, carregue a variável com a cadeia de caracteres JSON como seu valor. Essa solução alternativa garante o tratamento adequado da variável no ambiente da Automação do Azure como uma cadeia de caracteres JSON.

  Exemplo - Criar um objeto do PowerShell que tenha armazenado informações sobre VMs do Azure

    # Retrieve Azure virtual machines with status information for the 'northeurope' region 
    $AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"} 
  
    $VMstopatch = @($AzVM).Id 
    # Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch 
  
    # Convert the object to a JSON string 
    $jsonString = $VMstopatch | ConvertTo-Json 
  
    # Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString 
  

Limitações

• O PowerShell 7.1 não é mais compatível com o produto pai PowerShell. Recomendamos que você crie novos runbooks no PowerShell 7.2 para um suporte de longo prazo e atualize os runbooks desatualizados.
• Não há suporte para os cmdlets internos do PowerShell de Automação do Azure no Hybrid Runbook Worker do Linux. Você precisa importar o módulo automationassets no início do runbook PowerShell para acessar as funções de recursos compartilhados (ativos) da conta de Automação.
• Na versão de runtime 7 do PowerShell, as atividades do módulo não são extraídas para os módulos importados.
• Não há suporte para o tipo de parâmetro de runbook PSCredential na versão de runtime do PowerShell 7.
• O PowerShell 7.x não dá suporte a fluxos de trabalho. Para obter mais informações, consulte o Fluxo de Trabalho do PowerShell para obter mais detalhes.
• No momento, o PowerShell 7.x não dá suporte a runbooks assinados.
• A integração de controle do código-fonte não dá suporte ao PowerShell 7.1 (versão prévia). Além disso, os runbooks do PowerShell 7.1 (versão prévia) no controle do código-fonte são criados na conta de Automação como Runtime 5.1.
• Não há suporte para o gerenciamento de módulo do PowerShell 7.1 por meio de cmdlets Get-AzAutomationModule.
• O runbook falha sem rastreamento de log se o valor de entrada contiver o caractere '.
• O runbook do Azure não dá suporte a Start-Job com -credential.
• O Azure não dá suporte a todos os parâmetros de entrada do PowerShell. Saiba mais.

Problemas conhecidos

• Runbooks que assumem dependência em caminhos de arquivo internos, como C:\modules podem falhar devido a alterações na infraestrutura de back-end de serviço. Altere o código do runbook para garantir que não haja dependências em caminhos de arquivo internos e use Get-ChildItem para obter as informações necessárias do módulo.

  Exemplo de script

  
  # Get information about module "Microsoft.Graph.Authentication"
  $ModuleName = "Microsoft.Graph.Authentication"
  
  $NewPath = "C:\usr\src\PSModules\$ModuleName"
  $OldPath = "C:\Modules\User\$ModuleName"
  
  if (Test-Path -Path $NewPath -PathType Container) {
      Get-ChildItem -Path $NewPath
  } elseif (Test-Path -Path $OldPath -PathType Container) {
      Get-ChildItem -Path $OldPath
  } else {
      Write-Output "Module $ModuleName not present."
  }
  # Getting the path to the Temp folder, if needed.
  $tmp = $env:TEMP
  
  

• O cmdlet Get-AzStorageAccount pode falhar com um erro: O comando Get-AzStorageAccount foi encontrado no módulo Az.Storage, mas o módulo não pôde ser carregado.

• Não há suporte para a execução de scripts filho usando .\child-runbook.ps1 nesta versão prévia. Solução alternativa: use Start-AutomationRunbook (cmdlet interno) ou Start-AzAutomationRunbook (do módulo Az.Automation) para iniciar outro runbook por meio do runbook pai.

• Não há suporte para propriedades de runbook que definem a preferência de registro em log no runtime 7 do PowerShell. Solução alternativa: defina explicitamente a preferência no início do runbook, como é mostrado a seguir:

      $VerbosePreference = "Continue"
  
      $ProgressPreference = "Continue"
  

• Evite importar o módulo Az.Accounts para a versão 2.4.0 no runtime 7 do PowerShell, pois pode haver um comportamento inesperado ao usar essa versão na Automação do Azure.

• Pode haver problemas de formatação com fluxos de saída de erro no trabalho em execução no runtime 7 do PowerShell.

• Quando você importa um módulo do PowerShell 7.1 que depende de outros módulos, pode ocorrer que o botão de importação esteja cinza mesmo quando a versão do PowerShell 7.1 do módulo dependente está instalada. Por exemplo, o módulo Az PowerShell. A versão de computação 4.20.0 tem uma dependência do Az.Accounts sendo >= 2.6.0. Esse problema ocorre quando um módulo dependente equivalente no PowerShell 5.1 não atende aos requisitos de versão. Por exemplo, a versão 5.1 do Az.Accounts era < 2.6.0.

• Quando você inicia o runbook do PowerShell 7 usando o webhook, ele converte automaticamente o parâmetro de entrada do webhook em um JSON inválido.

• Recomendamos que você use a versão do módulo ExchangeOnlineManagement: 3.0.0 ou inferior porque a versão: 3.0.0 ou superior pode levar a falhas no trabalho.

• Se você importar o módulo Az.Accounts com a versão 2.12.3 ou mais recente, certifique-se de importar o módulo Newtonsoft.Json v10 explicitamente se os runbooks do PowerShell 7.1 tiverem uma dependência nesta versão do módulo. A solução alternativa para esse problema é usar runbooks do PowerShell 7.2.

• Quando você utiliza o cmdlet New-AzAutomationVariable no Módulo Az.Automation para carregar uma variável do tipo objeto, a operação não funciona como esperado.

  Solução alternativa: Converta o objeto em uma cadeia de caracteres JSON usando o cmdlet ConvertTo-Json e, em seguida, carregue a variável com a cadeia de caracteres JSON como seu valor. Essa solução alternativa garante o tratamento adequado da variável no ambiente da Automação do Azure como uma cadeia de caracteres JSON.

  Exemplo - Criar um objeto do PowerShell que tenha armazenado informações sobre VMs do Azure

    # Retrieve Azure virtual machines with status information for the 'northeurope' region 
    $AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"} 
  
    $VMstopatch = @($AzVM).Id 
    # Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch 
  
    # Convert the object to a JSON string 
    $jsonString = $VMstopatch | ConvertTo-Json 
  
    # Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString 
  

• Para módulos do Python 3.10 (versão prévia), atualmente há suporte apenas aos arquivos wheel direcionados ao sistema operacional Linux cp310. Saiba mais
• Não há suporte para a integração do controle do código-fonte.
• Pacotes personalizados para Python 3.10 (versão prévia) só são validados durante o runtime do trabalho. Espera-se que o trabalho falhe se o pacote não for compatível no runtime ou se as dependências necessárias dos pacotes não forem importadas para a conta de automação.
• Atualmente, os runbooks do Python 3.10 (versão prévia) só têm suporte no portal do Azure. Não há suporte à API Rest e ao PowerShell.

• Você deve estar familiarizado com script do Python.
• Não há suporte para a integração do controle do código-fonte.
• Para módulos do Python 3.8, use arquivos wheel direcionados para cp38-amd64.
• Para utilizar bibliotecas de terceiros, você deve importar os pacotes para a conta de Automação.
• O uso do cmdlet Start-AutomationRunbook no PowerShell/Fluxo de trabalho do PowerShell para iniciar um runbook do Python 3.8 não funciona. Você pode usar o cmdlet Start-AzAutomationRunbook do módulo Az.Automation ou o cmdlet Start-AzureRmAutomationRunbook do módulo AzureRm.Automation para contornar essa limitação. 
• A Automação do Azure não dá suporte para sys.stderr.
• O pacote automationassets do Python não está disponível em pypi.org, portanto, ele não está disponível para importação em um computador Windows.

• O Python 2.7 não é mais compatível com o produto pai Python. Recomendamos que você crie novos runbooks nas versões com suporte e atualize os runbooks desatualizados.
• Você deve estar familiarizado com script do Python.
• Para módulos do Python 2.7.12, use arquivos wheel cp27-amd6.
• Para utilizar bibliotecas de terceiros, você deve importar os pacotes para a conta de Automação.
• A Automação do Azure não dá suporte para sys.stderr.
• O pacote automationassets do Python não está disponível em pypi.org, portanto, ele não está disponível para importação em um computador Windows.