Types de Runbooks Azure Automation

Limitations

• PowerShell 7.4 est disponible uniquement dans l’expérience de l’environnement d'exécution.
• Pour la version du runtime PowerShell 7.4, les activités de module ne sont pas extraites pour les modules importés. Utilisez l’extension Azure Automation pour VS Code pour simplifier l’expérience de création de runbooks.
• PowerShell 7.x ne prend pas en charge les workflows. Pour plus d’informations et de détails, consultez PowerShell Workflow.
• PowerShell 7.x ne prend pas en charge les runbooks signés pour le moment.
• L’intégration du contrôle de code source ne prend pas en charge PowerShell 7.4. En outre, les runbooks PowerShell 7.4 dans le contrôle de code source sont créés dans le compte Automation en tant que Runtime 5.1.
• Le module Az 12.3.0 est installé par défaut. La liste complète des modules de composant de la version sélectionnée du module Az s’affiche une fois que la version Az est configurée à nouveau à l’aide du portail Azure ou de l’API.
• Le module PowerShell 7.4 importé serait validé pendant l’exécution du travail. Vérifiez que toutes les dépendances du module sélectionné sont également importées pour une exécution réussie du travail.
• Le runbook Azure ne prend pas en charge Start-Job avec -credential.
• Azure ne prend pas en charge tous les paramètres d’entrée PowerShell. Plus d’informations

Problèmes connus

• Les Runbooks qui dépendent des chemins d’accès de fichiers internes, tels que C:\modules, peuvent échouer en raison de modifications apportées à l’infrastructure back-end du service. Modifiez le code du runbook pour vous assurer qu’il n’existe aucune dépendance sur les chemins de fichiers internes et utilisez Get-ChildItem pour obtenir les informations de module requises.

• La cmdlet Get-AzStorageAccount peut échouer avec une erreur : La commande Get-AzStorageAccount a été trouvée dans le module Az.Storage, mais le module n’a pas pu être chargé.

• L’exécution de scripts enfants à l’aide de .\child-runbook.ps1 n’est pas prise en charge.
  Solution de contournement : utiliser Start-AutomationRunbook (cmdlet interne) ou Start-AzAutomationRunbook (à partir du module Az.Automation) pour démarrer un autre runbook à partir du runbook parent.

• Lorsque vous utilisez le module ExchangeOnlineManagement version 3.0.0 ou ultérieure, vous pouvez rencontrer des erreurs. Pour résoudre le problème, veillez à charger explicitement des modules PowerShellGet et PackageManagement.

• Lorsque vous utilisez la cmdlet New-AzAutomationVariable dans le module Az.Automation pour charger une variable de type objet, l’opération ne fonctionne pas comme prévu. Solution de contournement : convertissez l’objet en chaîne JSON à l’aide de la cmdlet ConvertTo-Json, puis chargez la variable avec la chaîne JSON comme valeur. Cette solution de contournement garantit une gestion appropriée de la variable dans l’environnement Azure Automation en tant que chaîne JSON.

  Exemple : créer un objet PowerShell qui a stocké des informations relatives à des machines virtuelles Azure

  azurepowershell
  
  # 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 
  

Limitations

• Dans la version de runtime PowerShell 7.2, les activités du module ne sont pas extraites pour les modules importés.
• PowerShell 7.x ne prend pas en charge les workflows. Pour plus d’informations et de détails, consultez PowerShell Workflow.
• PowerShell 7.x ne prend pas en charge les runbooks signés pour le moment.
• L’intégration du contrôle de code source ne prend pas en charge PowerShell 7.2. En outre, les runbooks PowerShell 7.2 dans le contrôle de code source sont créés dans le compte Automation en tant que runtime 5.1.
• Le module Az 8.3.0 est installé par défaut. La liste complète des modules de composant de la version sélectionnée du module Az s’affiche une fois que la version Az est configurée à nouveau à l’aide du portail Azure ou de l’API.
• Le module PowerShell 7.2 importé est validé pendant l’exécution du travail. Vérifiez que toutes les dépendances du module sélectionné sont également importées pour une exécution réussie du travail.
• Le runbook Azure ne prend pas en charge Start-Job avec -credential.
• Azure ne prend pas en charge tous les paramètres d’entrée PowerShell. Plus d’informations

Problèmes connus

• Les Runbooks qui dépendent des chemins d’accès de fichiers internes, tels que C:\modules, peuvent échouer en raison de modifications apportées à l’infrastructure back-end du service. Modifiez le code du runbook pour vous assurer qu’il n’existe aucune dépendance sur les chemins de fichiers internes et utilisez Get-ChildItem pour obtenir les informations de module requises.

• La cmdlet Get-AzStorageAccount peut échouer avec une erreur : La commande Get-AzStorageAccount a été trouvée dans le module Az.Storage, mais le module n’a pas pu être chargé.

• L’exécution de scripts enfants à l’aide de .\child-runbook.ps1 n’est pas prise en charge.
  Solution de contournement : utiliser Start-AutomationRunbook (cmdlet interne) ou Start-AzAutomationRunbook (à partir du module Az.Automation) pour démarrer un autre runbook à partir du runbook parent.

• Lorsque vous utilisez le module ExchangeOnlineManagement version 3.0.0 ou ultérieure, vous pouvez rencontrer des erreurs. Pour résoudre le problème, veillez à charger explicitement des modules PowerShellGet et PackageManagement.

• Lorsque vous utilisez la cmdlet New-AzAutomationVariable dans le module Az.Automation pour charger une variable de type objet, l’opération ne fonctionne pas comme prévu.

  Solution de contournement : convertissez l’objet en chaîne JSON à l’aide de la cmdlet ConvertTo-Json, puis chargez la variable avec la chaîne JSON comme valeur. Cette solution de contournement garantit une gestion appropriée de la variable dans l’environnement Azure Automation en tant que chaîne JSON.

  Exemple : créer un objet PowerShell qui a stocké des informations relatives à des machines virtuelles Azure

    azurepowershell
  
    # 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 
  

Limitations

• Les runbooks ne peuvent pas utiliser un traitement en parallèle pour effectuer plusieurs actions en parallèle.
• Les runbooks ne peuvent pas utiliser de points de contrôle pour reprendre le runbook en cas d'erreur.
• Vous pouvez uniquement inclure PowerShell, les runbooks de flux de travail PowerShell et les runbooks graphiques comme runbooks enfants à l’aide de la cmdlet Start-AzAutomationRunbook, ce qui crée un travail.
• Les runbooks ne peuvent pas utiliser l’instruction PowerShell #Requires, car elle n’est pas prise en charge dans le bac à sable Azure ni sur les Runbooks Workers hybrides et peut entraîner l’échec de la tâche.
• Le runbook Azure ne prend pas en charge Start-Job avec -credential.
• Azure ne prend pas en charge tous les paramètres d’entrée PowerShell. Plus d’informations

Problèmes connus

• Les Runbooks qui dépendent des chemins d’accès de fichiers internes, tels que C:\modules, peuvent échouer en raison de modifications apportées à l’infrastructure back-end du service. Modifiez le code du runbook pour vous assurer qu’il n’existe aucune dépendance sur les chemins de fichiers internes et utilisez Get-ChildItem pour obtenir les informations de module requises.

  Exemple 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
  
  

• La cmdlet Get-AzStorageAccount peut échouer avec une erreur : La commande Get-AzStorageAccount a été trouvée dans le module Az.Storage, mais le module n’a pas pu être chargé.

• Les runbooks PowerShell ne peuvent pas récupérer une ressource variable non chiffrée avec une valeur null.

• Les runbooks PowerShell ne peuvent pas récupérer une ressource variable dont le nom contient le symbole *~*.

• Une opération Get-Process dans une boucle d’un runbook PowerShell peut se bloquer après environ 80 itérations.

• Un runbook PowerShell peut échouer s’il essaie d'écrire une grande quantité de données à la fois dans le flux de sortie. Vous pouvez généralement contourner ce problème en configurant le runbook pour qu'il ne sorte que les informations nécessaires au traitement des objets volumineux. Par exemple, au lieu d’utiliser Get-Process sans aucune limitation, vous pouvez faire en sorte que l’applet de commande génère uniquement les paramètres requis, comme dans Get-Process | Select ProcessName, CPU.

• Lorsque vous utilisez le module ExchangeOnlineManagement : version 3.0.0 ou ultérieure, vous pouvez rencontrer des erreurs. Pour résoudre le problème, veillez également à charger explicitement les modules PowerShellGet et PackageManagement.

• Si vous importez le module Az.Accounts avec la version 2.12.3 ou ultérieure, assurez-vous d’importer explicitement le module Newtonsoft.Json v10 si les runbooks PowerShell 5.1 ont une dépendance sur cette version du module. La solution de contournement pour ce problème consiste à utiliser des runbooks PowerShell 7.2.

• Lorsque vous utilisez la cmdlet New-AzAutomationVariable dans le module Az.Automation pour charger une variable de type objet, l’opération ne fonctionne pas comme prévu.

  Solution de contournement : convertissez l’objet en chaîne JSON à l’aide de la cmdlet ConvertTo-Json, puis chargez la variable avec la chaîne JSON comme valeur. Cette solution de contournement garantit une gestion appropriée de la variable dans l’environnement Azure Automation en tant que chaîne JSON.

  Exemple : créer un objet PowerShell qui a stocké des informations relatives à des machines virtuelles 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 
  

Limitations

• PowerShell 7.1 n’est plus pris en charge par le produit parent PowerShell. Nous vous recommandons de créer de nouveaux runbooks dans PowerShell 7.4 pour une prise en charge à long terme et de mettre à jour les runbooks obsolètes.
• Les applets de commande PowerShell internes d’Azure Automation ne sont pas prises en charge sur un Runbook Worker hybride Linux. Vous devez importer le module automationassets au début de votre runbook PowerShell pour accéder aux fonctions de ressources partagées du compte Automation.
• Dans la version de runtime PowerShell 7, les activités du module ne sont pas extraites pour les modules importés.
• Le type de paramètre de runbook PSCredential n’est pas pris en charge dans la version de runtime PowerShell 7.
• PowerShell 7.x ne prend pas en charge les workflows. Pour plus d’informations et de détails, consultez PowerShell Workflow.
• PowerShell 7.x ne prend pas en charge les runbooks signés pour le moment.
• L’intégration du contrôle de code source ne prend pas en charge PowerShell 7.1 (préversion). En outre, les runbooks PowerShell 7.1 (préversion) dans le contrôle de code source sont créés dans le compte Automation en tant que runtime 5.1.
• La gestion des modules PowerShell 7.1 n’est pas prise en charge via les applets de commande Get-AzAutomationModule.
• Le runbook échoue sans trace de journal si la valeur d’entrée contient le caractère « ’ ».
• Le runbook Azure ne prend pas en charge Start-Job avec -credential.
• Azure ne prend pas en charge tous les paramètres d’entrée PowerShell. Plus d’informations

Problèmes connus

• Les Runbooks qui dépendent des chemins d’accès de fichiers internes, tels que C:\modules, peuvent échouer en raison de modifications apportées à l’infrastructure back-end du service. Modifiez le code du runbook pour vous assurer qu’il n’existe aucune dépendance sur les chemins de fichiers internes et utilisez Get-ChildItem pour obtenir les informations de module requises.

  Exemple 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
  
  

• La cmdlet Get-AzStorageAccount peut échouer avec une erreur : La commande Get-AzStorageAccount a été trouvée dans le module Az.Storage, mais le module n’a pas pu être chargé.

• L’exécution de scripts enfants à l’aide de .\child-runbook.ps1 n’est pas prise en charge dans cette préversion. Solution de contournement : utilisez Start-AutomationRunbook (cmdlet interne) ou Start-AzAutomationRunbook (à partir du module Az.Automation) pour démarrer un autre runbook à partir du runbook parent.

• Les propriétés de runbook définissant la préférence de journalisation ne sont pas prises en charge dans le runtime PowerShell 7. Solution de contournement : définissez explicitement la préférence au début du runbook, comme suit :

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

• Évitez d’importer le Az.Accounts module vers la version 2.4.0 pour le runtime PowerShell 7, car il peut y avoir un comportement inattendu à l’aide de cette version dans Azure Automation.

• Vous pouvez rencontrer des problèmes de mise en forme avec des flux de sortie d’erreur pour les travaux qui s’exécutent dans le runtime PowerShell 7.

• Lorsque vous importez un module PowerShell 7.1 qui dépend d’autres modules, il se peut que le bouton d’importation soit grisé même si la version PowerShell 7.1 du module dépendant est installée. Par exemple, le module Az PowerShell.Compute version 4.20.0 dépend de Az.Accounts version >= 2.6.0. Ce problème se produit lorsqu’un module dépendant équivalent dans PowerShell 5.1 ne répond pas aux exigences de version. Par exemple, la version 5.1 de Az.Accounts était < 2.6.0.

• Lorsque vous démarrez un runbook PowerShell 7 à l’aide du webhook, il convertit automatiquement le paramètre d’entrée du webhook en JSON non valide.

• Nous vous recommandons d’utiliser la version 3.0.0 ou inférieure du module ExchangeOnlineManagement, car la version 3.0.0 ou ultérieure peut entraîner des échecs de travaux.

• Si vous importez le module Az.Accounts avec la version 2.12.3 ou ultérieure, veillez à importer explicitement le module Newtonsoft.Json v10 si les runbooks PowerShell 7.1 ont une dépendance sur cette version du module. La solution de contournement pour ce problème consiste à utiliser des runbooks PowerShell 7.2.

• Lorsque vous utilisez la cmdlet New-AzAutomationVariable dans le module Az.Automation pour charger une variable de type objet, l’opération ne fonctionne pas comme prévu.

  Solution de contournement : convertissez l’objet en chaîne JSON à l’aide de la cmdlet ConvertTo-Json, puis chargez la variable avec la chaîne JSON comme valeur. Cette solution de contournement garantit une gestion appropriée de la variable dans l’environnement Azure Automation en tant que chaîne JSON.

  Exemple : créer un objet PowerShell qui a stocké des informations relatives à des machines virtuelles 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 
  

• Pour les modules Python 3.10, seuls les fichiers wheel ciblant le système d'exploitation Linux pour cp310 sont pris en charge. En savoir plus
• L’intégration du contrôle de code source n’est pas prise en charge.
• Les packages personnalisés pour Python 3.10 sont validés uniquement pendant l’exécution du travail. Le travail devrait échouer si le package n’est pas compatible dans le runtime ou si les dépendances requises des packages ne sont pas importées dans le compte Automation.
• Actuellement, les runbooks Python 3.10 ne sont pris en charge qu’à partir du portail Azure et de l’API Rest.

• Python 3.8 n’est plus pris en charge par le produit parent Python. Nous vous recommandons de créer de nouveaux runbooks dans les versions prises en charge et de mettre à jour les runbooks obsolètes.
• Vous devez être familiarisé avec les scripts Python.
• L’intégration du contrôle de code source n’est pas prise en charge.
• Pour les modules Python 3.8, utilisez des fichiers wheel ciblant cp38-amd64.
• Pour utiliser des bibliothèques tierces, vous devez importer les packages dans le compte Automation.
• L’utilisation de la cmdlet Start-AutomationRunbook dans PowerShell/PowerShell Workflow pour démarrer un runbook Python 3.8 ne fonctionne pas. Vous pouvez utiliser la cmdlet Start-AzAutomationRunbook issue du module Az.Automation ou la cmdlet Start-AzureRmAutomationRunbook issue du module AzureRm.Automation pour contourner cette limitation. 
• Azure Automation ne prend pas en charge sys.stderr.
• Le package automationassets Python n’étant pas disponible sur pypi.org, il n’est pas disponible pour importation sur une machine Windows.

• Python 2.7 n’est plus pris en charge par le produit parent Python. Nous vous recommandons de créer de nouveaux runbooks dans les versions actuellement prises en charge et de mettre à jour ceux qui sont obsolètes.
• Vous devez être familiarisé avec les scripts Python.
• Pour les modules Python 2.7.12, utilisez les fichiers wheel cp27-amd6.
• Pour utiliser des bibliothèques tierces, vous devez importer les packages dans le compte Automation.
• Azure Automation ne prend pas en charge sys.stderr.
• Le package automationassets Python n’étant pas disponible sur pypi.org, il n’est pas disponible pour importation sur une machine Windows.