Résoudre les problèmes de runbook
Cet article décrit décrit des problèmes de runbook qui peuvent se produire, et explique comment les résoudre. Pour obtenir des informations générales sur les runbooks, consultez Exécution d’un Runbook dans Azure Automation.
Il n’est plus possible d’utiliser les applets de commande des modules importés non définis par défaut dans les runbooks PowerShell graphiques
Problème
Quand vous importez un module PowerShell, vous ne pouvez pas utiliser ses applets de commande dans les runbooks PowerShell graphiques.
Cause
Pour améliorer la posture de sécurité des runbooks PowerShell, le service ne traite plus le fichier manifeste du module pour exporter les applets de commande et les fonctions. Cela signifie qu’elles ne peuvent pas être utilisées pour créer des runbooks PowerShell graphiques.
Résolution
Il n’y a pas d’impact sur l’exécution des runbooks existants. Pour les nouveaux runbooks utilisant des modules PowerShell non définis par défaut, nous vous recommandons d’utiliser des runbooks textuels au lieu de runbooks PowerShell graphiques pour résoudre le problème. Vous pouvez utiliser l’extension Azure Automation pour VScode pour créer et modifier des runbooks PowerShell, laquelle tire parti de GitHub Copilot pour simplifier l’expérience de création de runbook.
Start-AzAutomationRunbook échoue avec le message d’erreur « runbookName ne correspond pas au modèle attendu »
Problème
Lorsque vous exécutez Start-AzAutomationRunbook
pour démarrer des runbooks spécifiques :
start-azautomationRunbook -Name "Test_2" -AutomationAccountName "AutomationParent" -ResourceGroupName "AutomationAccount"
Il échoue avec l'erreur suivante :
Start-AzAutomationRunbook: "runbookname" does not match expected pattern '^[a-zA-Z]*-*[a-zA-Z0-9]*$'
Cause
Le code introduit dans la version 1.9.0 du module Az.Automation vérifie les noms des runbooks à démarrer et marque de manière incorrecte les runbooks comportant plusieurs caractères « – » ou avec un caractère « _ » dans le nom comme non valides.
Solution de contournement
Nous vous suggestions de revenir à la version 1.8.0 du module.
Résolution
Nous travaillons actuellement au déploiement d'un correctif pour résoudre ce problème.
Diagnostiquer des problèmes de runbook
Lorsque des erreurs surviennent pendant l’exécution de runbooks dans Azure Automation, vous pouvez utiliser les étapes suivantes pour diagnostiquer les problèmes :
Vérifiez que le script de votre runbook s’exécute correctement sur votre machine locale.
Pour obtenir des modules de référence et d’entraînement du langage, reportez-vous à la Documentation de PowerShell ou à la Documentation de Python. L’exécution en local de votre script peut détecter et résoudre les erreurs courantes, telles que :
- Modules manquants
- Erreurs de syntaxe
- Erreurs logiques
Examinez les flux d’erreurs des runbooks.
Regardez si ces flux contiennent des messages particuliers, et comparez-les aux erreurs documentées dans cet article.
Vérifiez que vos nœuds et votre espace de travail Automation disposent des modules nécessaires.
Si votre runbook importe des modules, vérifiez qu’ils sont disponibles pour votre compte Automation en effectuant les étapes décrites dans Importer des modules. Mettez à jour vos modules PowerShell vers la dernière version disponible en suivant les instructions fournies dans Mettre à jour des modules Azure PowerShell dans Azure Automation. Pour plus d’informations sur la résolution des problèmes, consultez Résoudre les problèmes liés aux modules.
En cas d’échec inattendu ou d’interruption du runbook :
- Renouvelez le webhook si vous essayez d’utiliser un webhook expiré pour démarrer le runbook.
- Vérifiez les états des travaux pour déterminer les états de runbook actuels et des causes possibles du problème.
- Ajoutez une sortie supplémentaire au runbook pour identifier ce qui se passe avant l'interruption du runbook.
- Gérez les exceptions qui sont levées par votre travail.
Effectuez cette étape si le travail ou l’environnement du runbook sur Runbook Worker hybride ne répond pas.
Si vous exécutez vos runbooks sur un runbook Worker hybride plutôt que dans Azure Automation, vous devez peut-être résoudre les problèmes liés au Worker hybride lui-même.
Scénario : Impossible de créer un travail Automation dans la région Europe Ouest
Problème
Lors de la création de travaux Automation, vous pouvez être exposé à un retard ou à un échec de création des travaux. Les travaux planifiés sont automatiquement retirés, et les travaux exécutés via le portail peuvent être retirés si vous constatez un échec.
Cause
Ce problème est dû à la charge élevée des runbooks des clients qui utilisent le service Automation dans la région Europe Ouest.
Résolution
Si possible, procédez comme suit en fonction de vos besoins et de votre environnement pour réduire les risques de défaillance :
- Si vous utilisez le début de chaque heure pour la création des travaux (12h00, 1h00, 2h00, etc.), en choisissant généralement l’heure pile ou la demi-heure, nous vous recommandons de décaler l’heure de début du travail de cinq minutes avant ou après l’heure/la demi-heure. En effet, la plupart des clients utilisent le début de chaque heure pour exécuter leurs travaux, ce qui augmente considérablement la charge sur le service, alors que celle-ci est relativement faible aux autres créneaux horaires.
Scénario : Le runbook échoue avec le message d’erreur « this.Client.SubscriptionId ne peut pas être null. »
Problème
Votre runbook utilisant une identité managée Connect-AzAccount -Identity qui tente de gérer des objets Azure échoue à fonctionner correctement et consigne l’erreur suivante : this.Client.SubscriptionId cannot be null.
get-azvm : 'this.Client.SubscriptionId' cannot be null. At line:5 char:1 + get-azvm + ~~~~~~~~ + CategoryInfo : CloseError: (:) [Get-AzVM], ValidationException + FullyQualifiedErrorId : Microsoft.Azure.Commands.Compute.GetAzureVMCommand
Cause
Ceci peut se produire quand l’identité managée (ou un autre compte utilisé dans le runbook) n’a pas reçu les autorisations nécessaires pour accéder à l’abonnement.
Résolution
Accordez à l’identité managée (ou à un autre compte utilisé dans le runbook) une appartenance au rôle approprié dans l’abonnement. En savoir plus
Scénario : Accès bloqué au Stockage Azure, à Azure Key Vault ou à Azure SQL
Ce scénario utilise Azure Storage comme exemple ; cependant, les informations sont également applicables à Azure Key Vault et Azure SQL.
Problème
Toute tentative d’accès à stockage Azure à partir d’un Runbook provoque une erreur similaire au message suivant : The remote server returned an error: (403) Forbidden. HTTP Status Code: 403 - HTTP Error Message: This request is not authorized to perform this operation.
Cause
Le pare-feu Azure sur stockage Azure est activé.
Résolution
L’activation du Pare-feu Azure sur Stockage Microsoft Azure, Azure Key Vault ou Azure SQL bloque l’accès à partir des runbooks Azure Automation pour ces services. L'accès sera bloqué même si l'exception de pare-feu autorisant les services Microsoft approuvés est activée, car Automation ne figure pas dans la liste des services approuvés. Lorsqu'un pare-feu est activé, l'accès n'est possible qu'à l'aide d'un Runbook Worker hybride et d'un point de terminaison de service de réseau virtuel.
Scénario : Le runbook échoue avec une erreur 403 Interdit ou Aucune autorisation
Problème
Votre runbook échoue avec une erreur 403 Aucune autorisation ou Interdit, ou une erreur équivalente.
Cause
Les comptes d’identification n’ont peut-être pas les mêmes autorisations sur les ressources Azure que votre compte Automation actuel.
Résolution
Vérifiez que votre compte d’identification dispose des autorisations nécessaires pour accéder aux ressources utilisées dans votre script.
Scénario : Échec de la connexion au compte Azure
Problème
L’une des erreurs suivantes s’affiche quand vous utilisez l’applet de commande Connect-AzAccount
:
Unknown_user_type: Unknown User Type
No certificate was found in the certificate store with thumbprint
Cause
Ces erreurs se produisent quand le nom de la ressource d’informations d’identification n’est pas valide. Elles peuvent également se produire si le nom d’utilisateur et le mot de passe que vous avez utilisés pour configurer la ressource d’informations d’identification Automation ne sont pas valides.
Résolution
Pour identifiez le problème, suivez ces étapes :
Vérifiez qu’il n’existe aucun caractère spécial (notamment le caractère
\@
) dans le nom de la ressource d’informations d’identification Automation que vous utilisez pour vous connecter à Azure.Vérifiez que vous pouvez utiliser le nom d’utilisateur et le mot de passe stockés dans les informations d’identification Azure Automation dans votre éditeur d’ISE PowerShell local. Exécutez les applets de commande suivantes dans PowerShell ISE.
$Cred = Get-Credential #Using Azure Service Management Add-AzureAccount -Credential $Cred #Using Azure Resource Manager Connect-AzAccount -Credential $Cred
Si votre authentification échoue localement, cela signifie que vous n’avez pas correctement configuré vos informations d’identification Microsoft Entra. Pour configurer correctement le compte Microsoft Entra, consultez l’article S’authentifier auprès d’Azure à l’aide de Microsoft Entra ID.
Si cette erreur semble temporaire, essayez d’ajouter la logique de nouvelle tentative à votre routine d’authentification pour renforcer l’authentification.
$logonAttempt = 0 $logonResult = $False while(!($connectionResult) -And ($logonAttempt -le 10)) { $LogonAttempt++ #Logging in to Azure... $connectionResult = Connect-AzAccount ` Start-Sleep -Seconds 30 if($connectionResult) { $logonResult = $True } }
Scénario : Exécuter Login-AzureRMAccount pour se connecter
Problème
Lors de l’exécution d’un runbook, vous recevez l’erreur suivante :
Run Login-AzureRMAccount to login.
Cause
Cette erreur peut se produire lorsque vous n’utilisez pas un compte d’identification ou quand le compte d’identification a expiré.
Cette erreur a deux causes principales :
- Il existe plusieurs versions du module AzureRM ou Az.
- Vous essayez d’accéder à des ressources dans un abonnement distinct.
Résolution
Si vous recevez cette erreur après avoir mis à jour un module AzureRM ou Az, mettez à jour tous vos modules vers la même version.
Si vous essayez d’accéder à des ressources dans un autre abonnement, suivez ces étapes pour configurer les autorisations :
Accédez au compte d’identification Automation, puis copiez l’ID d’application et l’Empreinte.
Accédez au Contrôle d’accès de l’abonnement dans lequel le compte Automation n’est pas hébergé, puis ajoutez une nouvelle attribution de rôle.
Ajoutez l’ID d’application collecté précédemment. Sélectionnez des autorisations Contributeur.
Copiez le nom de l’abonnement.
Vous pouvez maintenant utiliser le code de runbook suivant pour tester les autorisations de votre compte Automation sur l’autre abonnement. Remplacez
<CertificateThumbprint>
par la valeur copiée à l’étape 1. Remplacez"<SubscriptionName>"
par la valeur copiée à l’étape 4.$Conn = Get-AutomationConnection -Name AzureRunAsConnection Connect-AzAccount -ServicePrincipal -Tenant $Conn.TenantID -ApplicationId $Conn.ApplicationID -CertificateThumbprint "<CertificateThumbprint>" #Select the subscription you want to work with Select-AzSubscription -SubscriptionName '<YourSubscriptionNameGoesHere>' #Test and get outputs of the subscriptions you granted access. $subscriptions = Get-AzSubscription foreach($subscription in $subscriptions) { Set-AzContext $subscription Write-Output $subscription.Name }
Scénario : Impossible de trouver l’abonnement Azure
Problème
L’erreur suivante s’affiche quand vous utilisez l’applet de commande Select-AzureSubscription
, Select-AzureRMSubscription
ou Select-AzSubscription
:
The subscription named <subscription name> cannot be found.
Erreur
Cette erreur peut se produire si :
- Le nom de l’abonnement n’est pas valide.
- L'utilisateur Microsoft Entra qui tente d'obtenir les détails de l'abonnement n'est pas configuré en tant qu'administrateur de l'abonnement.
- L’applet de commande n’est pas disponible.
- Le changement de contexte s’est produit.
Résolution
Pour le changement de contexte, voir Changement de contexte dans Azure Automation.
Scénario : Les runbooks échouent lors du traitement de plusieurs abonnements
Problème
Lors de l’exécution de runbooks, le runbook ne parvient pas à gérer les ressources Azure.
Cause
Le runbook n’utilise pas le contexte approprié lors de l’exécution. Cela peut être dû au fait que le runbook tente d’accéder accidentellement à l’abonnement incorrect.
Vous pouvez voir des erreurs telles que celle-ci :
Get-AzVM : The client '<client-id>' with object id '<object-id> does not have authorization to perform action 'Microsoft.Compute/virtualMachines/read' over scope '/subscriptions/<subscriptionIdOfSubscriptionWhichDoesntContainTheVM>/resourceGroups/REsourceGroupName/providers/Microsoft.Compute/virtualMachines/VMName '.
ErrorCode: AuthorizationFailed
StatusCode: 403
ReasonPhrase: Forbidden Operation
ID : <AGuidRepresentingTheOperation> At line:51 char:7 + $vm = Get-AzVM -ResourceGroupName $ResourceGroupName -Name $UNBV... +
ou comme celle-ci :
Get-AzureRmResource : Resource group "SomeResourceGroupName" could not be found.
... resources = Get-AzResource -ResourceGroupName $group.ResourceGro ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (:) [Get-AzResource], CloudException
+ FullyQualifiedErrorId : Microsoft.Azure.Commands.ResourceManager.Cmdlets.Implementation.GetAzureResourceCmdlet
Résolution
Pour éviter d'essayer accidentellement d'accéder à l'abonnement incorrect, voir Changement de contexte dans Azure Automation.
Scénario : L’authentification auprès d’Azure échoue parce que l’authentification multifacteur est activée
Problème
Vous recevez l’erreur suivante lors de l’authentification auprès d’Azure avec vos nom d’utilisateur et mot de passe Azure :
Add-AzureAccount: AADSTS50079: Strong authentication enrollment (proof-up) is required
Cause
Si vous disposez d’une authentification multifacteur sur votre compte Azure, vous ne pouvez pas utiliser un utilisateur Microsoft Entra pour vous authentifier auprès d’Azure. Au lieu de cela, vous devez utiliser un certificat ou un principal de service pour l’authentification.
Résolution
Pour utiliser un principal de service avec des applets de commande Azure Resource Manager, reportez-vous à Création du principal du service à l’aide du portail Azure et Authentification d’un principal du service à l’aide d’Azure Resource Manager.
Scénario : Le runbook échoue avec le message d’erreur « Une tâche a été annulée »
Problème
Votre runbook échoue avec une erreur similaire à l’exemple suivant :
Exception: A task was cancelled.
Cause
Cette erreur peut être due à l’utilisation de modules Azure obsolètes.
Résolution
Vous pouvez corriger cette erreur en mettant à jour vos modules Azure avec la toute dernière version :
- Dans votre compte Automation, sélectionnez Modules, puis Mettre à jour les modules Azure.
- La mise à jour prend environ 15 minutes. Une fois l’opération terminée, réexécutez le runbook qui a échoué.
Pour en savoir plus sur la mise à jour de vos modules, consultez Mettre à jour des modules Azure dans Azure Automation.
Scénario : Terme non reconnu comme nom d’une applet de commande, d’une fonction or d’un script
Problème
Votre runbook échoue avec une erreur similaire à l’exemple suivant :
The term 'Connect-AzAccount' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if the path was included verify that the path is correct and try again.
Cause
Cette erreur peut se produire pour les raisons suivantes :
- Le module qui contient l’applet de commande n’est pas importé dans le compte Automation.
- Le module qui contient l’applet de commande est importé, mais il est obsolète.
Résolution
Effectuez l’une des tâches suivantes pour corriger cette erreur :
- Pour un module Azure, consultez Guide de mise à jour des modules Azure PowerShell dans Azure Automation afin de savoir comment mettre à jour vos modules dans votre compte Automation.
- Pour un module non-Azure, vérifiez que le module a été importé dans votre compte Automation.
Scénario : l'applet de commande échoue dans le runbook PnP PowerShell sur Azure Automation
Problème
Lorsqu’un runbook écrit directement un objet généré par PowerShell PnP dans la sortie Azure Automation, la sortie de la cmdlet ne peut pas être renvoyée à Automation.
Cause
Ce problème est généralement dû au fait qu’Azure Automation traite les runbooks qui appellent des applets de commande PowerShell PnP, par exemple add-pnplistitem
, sans intercepter les objets de retour.
Résolution
Modifiez vos scripts pour attribuer des valeurs retournées à des variables, afin que les applets de commande n’essaient pas d’écrire des objets entiers dans la sortie standard. Un script peut rediriger le flux de sortie vers une applet de commande, comme indiqué ici.
$null = add-pnplistitem
Si votre script analyse la sortie de la cmdlet, le script doit stocker la sortie dans une variable et manipuler la variable au lieu de simplement diffuser la sortie.
$SomeVariable = add-pnplistitem ....
if ($SomeVariable.someproperty -eq ....
Scénario : l’applet de commande n’est pas reconnue lors de l’exécution d’un runbook
Problème
Le travail de votre runbook échoue avec l’erreur :
<cmdlet name>: The term <cmdlet name> is not recognized as the name of a cmdlet, function, script file, or operable program.
Cause
Cette erreur survient quand le moteur PowerShell ne trouve pas la cmdlet que vous utilisez dans votre runbook. Il est possible que le module contenant l’applet de commande ne soit pas présent dans le compte, qu’il existe un conflit de nom avec un nom de runbook ou que l’applet de commande existe déjà dans un autre module et qu’Automation ne puisse pas résoudre le nom.
Résolution
Utilisez l’une des solutions suivantes pour résoudre le problème :
- Vérifiez que vous avez correctement entré le nom de l’applet de commande.
- Vérifiez que l’applet de commande existe dans votre compte Automation et qu’il n’existe aucun conflit. Pour vérifier si l’applet de commande est présente, ouvrez un runbook en mode édition et recherchez l’applet de commande dans la bibliothèque, ou exécutez
Get-Command <CommandName>
. Après avoir vérifié que l’applet de commande est disponible pour le compte, et qu’il n’existe aucun conflit de nom avec d’autres applets de commande ou runbooks, ajoutez l’applet de commande dans le canevas. Veillez à utiliser un jeu de paramètres valide dans votre runbook. - Si vous rencontrez un conflit de noms et si l’applet de commande est disponible dans deux modules différents, vous pouvez résoudre ce problème en utilisant le nom complet de l’applet de commande. Par exemple, vous pouvez utiliser
ModuleName\CmdletName
. - Si vous exécutez le runbook localement dans un groupe de workers hybrides, vérifiez que le module et l’applet de commande sont installés sur la machine qui héberge le worker hybride.
Scénario : référence d'objet incorrecte lors de l'appel à Add-AzAccount
Problème
Vous recevez cette erreur lorsque vous utilisez Add-AzAccount
, qui est un alias pour l’applet de commande Connect-AzAccount
:
Add-AzAccount : Object reference not set to an instance of an object
Cause
Cette erreur peut se produire si le runbook n’effectue pas les étapes appropriées avant d’appeler Add-AzAccount
pour ajouter le compte Automation. Un exemple d’étape nécessaire est la connexion avec un compte d’identification. Pour connaître les opérations correctes à utiliser dans votre runbook, consultez Exécution d’un runbook dans Azure Automation.
Scénario : La référence d’objet n’a pas la valeur d’une instance d’un objet
Problème
Vous recevez l’erreur suivante lorsque vous appelez un runbook enfant avec le paramètre Wait
, et que le flux de sortie contient un objet :
Object reference not set to an instance of an object
Cause
Si le flux contient des objets, Start-AzAutomationRunbook
ne gère pas correctement le flux de sortie.
Résolution
Implémentez une logique d’interrogation et utilisez l’applet de commande Get-AzAutomationJobOutput pour récupérer la sortie. Un exemple de cette logique est défini ici :
$AutomationAccountName = "ContosoAutomationAccount"
$RunbookName = "ChildRunbookExample"
$ResourceGroupName = "ContosoRG"
function IsJobTerminalState([string]$Status) {
$TerminalStates = @("Completed", "Failed", "Stopped", "Suspended")
return $Status -in $TerminalStates
}
$StartAzAutomationRunbookParameters = @{
Name = $RunbookName
AutomationAccountName = $AutomationAccountName
ResourceGroupName = $ResourceGroupName
}
$Job = Start-AzAutomationRunbook @StartAzAutomationRunBookParameters
$PollingSeconds = 5
$MaxTimeout = New-TimeSpan -Hours 3 | Select-Object -ExpandProperty TotalSeconds
$WaitTime = 0
while(-NOT (IsJobTerminalState $Job.Status) -and $WaitTime -lt $MaxTimeout) {
Start-Sleep -Seconds $PollingSeconds
$WaitTime += $PollingSeconds
$Job = $Job | Get-AzAutomationJob
}
$Job | Get-AzAutomationJobOutput | Get-AzAutomationJobOutputRecord | Select-Object -ExpandProperty Value
Scénario : Le runbook échoue à cause d’un objet désérialisé
Problème
Votre runbook échoue avec l’erreur :
Cannot bind parameter <ParameterName>.
Cannot convert the <ParameterType> value of type Deserialized <ParameterType> to type <ParameterType>.
Cause
Si votre runbook est un workflow PowerShell, il stocke les objets complexes dans un format désérialisé afin de conserver l’état du runbook si le workflow est suspendu.
Résolution
Utilisez une des solutions suivantes pour résoudre ce problème :
- Si vous redirigez des objets complexes d’une applet de commande vers une autre, wrappez ces deux applets de commande dans une activité
InlineScript
. - Transmettez le nom ou la valeur dont vous avez besoin depuis l’objet complexe au lieu de transmettre la totalité de l’objet.
- Utilisez un runbook PowerShell au lieu d’un runbook Workflow PowerShell.
Scénario : État 400 Requête incorrecte lors de l’appel d’un webhook
Problème
Lorsque vous essayez d’appeler un webhook pour un runbook Azure Automation, vous recevez l’erreur suivante :
400 Bad Request : This webhook has expired or is disabled
Cause
Le webhook que vous tentez d’appeler est désactivé ou a expiré.
Résolution
Si le webhook est désactivé, vous pouvez le réactiver via le portail Azure. Si le webhook a expiré, vous devez le supprimer puis le recréer. Vous pouvez uniquement renouveler un webhook s’il n’a pas déjà expiré.
Scénario : 429 : Le taux de requêtes est actuellement trop important
Problème
Vous recevez le message d’erreur suivant lors de l’exécution de l’applet de commande Get-AzAutomationJobOutput
:
429: The request rate is currently too large. Please try again
Cause
Cette erreur peut se produire lors de la récupération d’une sortie de tâche à partir d’un runbook comportant de nombreux flux détaillés.
Résolution
Effectuez l’une des actions suivantes pour corriger cette erreur :
- Modifiez le runbook et réduisez le nombre de flux de tâches émis.
- Réduisez le nombre de flux à récupérer lors de l’exécution de la cmdlet. Pour cela, vous pouvez définir la valeur du paramètre
Stream
de la cmdlet Get-AzAutomationJobOutput de manière à récupérer uniquement les flux de sortie.
Scénario : La tâche Runbook échoue car le quota alloué a été dépassé
Problème
Le travail de votre runbook échoue avec l’erreur :
The quota for the monthly total job run time has been reached for this subscription
Cause
Cette erreur se produit quand l’exécution du travail dépasse le quota gratuit de 500 minutes pour votre compte. Ce quota s’applique à tous les types de tâches d’exécution de travail, notamment le test d’un travail, le démarrage d’un travail à partir du portail, l’exécution d’un travail à l’aide de webhooks ou la planification d’un travail à exécuter en utilisant le portail Azure ou dans votre centre de données. Pour en savoir plus sur la tarification d’Automation, consultez Tarification d’Automation.
Résolution
Si vous voulez utiliser plus de 500 minutes de traitement par mois, passez d’un abonnement de niveau Gratuit à un abonnement de niveau De base :
- Connectez-vous à votre abonnement Azure.
- Sélectionnez le compte Automation à mettre à niveau.
- Sélectionnez Paramètres, puis Tarifs.
- Sélectionnez Activer au bas de la page pour mettre à niveau votre compte vers le niveau De base.
Scénario : flux de sortie du Runbook supérieur à 1 Mo
Problème
Votre runbook s’exécutant dans le bac à sable (sandbox) Azure échoue avec l’erreur suivante :
The runbook job failed due to a job stream being larger than 1MB, this is the limit supported by an Azure Automation sandbox.
Cause
Cette erreur se produit parce que votre runbook a tenté d’écrire trop de données d’exception dans le flux de sortie.
Résolution
Une limite de 1 Mo s’applique au flux de sortie des travaux. Vérifiez que votre runbook englobe des appels à un fichier exécutable ou à un sous-processus à l’aide des blocs try
et catch
. Si les opérations lèvent une exception, faites en sorte que le code écrive le message de l’exception dans une variable Automation. Cette technique empêche l’écriture du message dans le flux de sortie du travail. Pour les travaux Runbook Workers hybrides exécutés, c’est le flux de sortie tronqué à 1 Mo qui s’affiche, sans message d’erreur.
Scénario : Le démarrage de la tâche Runbook a été tenté à trois reprises, mais ne parvient pas à démarrer à chaque fois
Problème
Votre runbook échoue avec l’erreur suivante :
The job was tried three times but it failed
Cause
Cette erreur se produit en raison de l’un des problèmes suivants :
Limite de mémoire. Un travail peut échouer s’il utilise plus de 400 Mo de mémoire. Les limites documentées sur la mémoire allouée à un bac à sable sont indiquées dans Limites du service Automation.
Sockets réseau. Les bacs à sable Azure sont limités à 1 000 sockets réseau simultanés. Pour plus d’informations, consultez Limites du service Automation.
Module incompatible. Les dépendances du module sont peut-être incorrectes. Dans ce cas, votre runbook retourne généralement un message
Command not found
ouCannot bind parameter
.Aucune authentification auprès d’Active Directory pour le bac à sable. Votre runbook a tenté d’appeler un fichier exécutable ou un sous-processus qui s’exécute dans un bac à sable Azure. La configuration des runbooks pour s'authentifier avec Microsoft Entra ID à l'aide de la bibliothèque d'authentification Azure Active Directory (ADAL) n'est pas prise en charge.
Résolution
Limite de mémoire, sockets réseau. Les méthodes suggérées pour respecter les limites de mémoire consistent à diviser la charge de travail entre plusieurs runbooks, à traiter moins de données en mémoire, à éviter d’écrire une sortie inutile depuis vos runbooks et à prendre en compte le nombre de points de contrôle écrits dans vos runbooks de workflow PowerShell. Utilisez la méthode de vidage, telle que
$myVar.clear
, pour effacer les variables et utilisez[GC]::Collect
pour exécuter immédiatement un nettoyage de la mémoire. Cela permet de réduire l’empreinte mémoire de votre runbook pendant l’exécution.Module incompatible. Mettez à jour vos modules Azure en suivant les étapes décrites dans Guide pratique pour mettre à jour des modules Azure PowerShell dans Azure Automation.
Aucune authentification auprès d’Active Directory pour le bac à sable. Lorsque vous vous authentifiez auprès de Microsoft Entra ID avec un runbook, vérifiez que le module Azure AD est disponible dans votre compte Automation. Veillez à accorder au compte d’identification les autorisations nécessaires pour effectuer les tâches que le runbook automatise.
Si votre runbook ne peut pas appeler un exécutable ou un sous-processus s’exécutant dans un bac à sable Azure, utilisez le runbook sur un Runbook Worker hybride. Les Workers hybrides ne sont pas restreints par les limites de mémoire et réseau associées aux bacs à sable Azure.
Scénario : la tâche PowerShell échoue avec le message d'erreur « Impossible d'invoquer la méthode »
Problème
Vous recevez le message d’erreur suivant lorsque vous démarrez un travail PowerShell dans un runbook qui s’exécute dans Azure :
Exception was thrown - Cannot invoke method. Method invocation is supported only on core types in this language mode.
Cause
Cette erreur peut indiquer que l’exécution de runbooks dans un bac à sable (sandbox) Azure n’est pas possible dans le mode Langage complet.
Résolution
Il existe deux façons de résoudre cette erreur :
- Au lieu d’utiliser Start-Job, utilisez Start-AzAutomationRunbook pour démarrer le runbook.
- Exécutez le runbook sur un Runbook Worker hybride.
Pour plus d’informations sur ce comportement et d’autres comportements des runbooks Azure Automation, consultez Exécution d’un Runbook dans Azure Automation.
Scénario : Échec de l’exécution d’un long runbook
Problème
Votre runbook affiche l’état Stopped (Arrêté) au bout de trois heures d’exécution. Il est également possible que vous obteniez cette erreur :
The job was evicted and subsequently reached a Stopped state. The job cannot continue running.
Il s’agit du comportement par défaut dans les bacs à sable Azure en raison de la supervision de la répartition de charge équilibrée des processus au sein d’Azure Automation. Si un processus s’exécute pendant plus de trois heures, la répartition de charge équilibrée arrête automatiquement un runbook. L’état d’un runbook qui dépasse la limite de temps de la répartition de charge équilibrée diffère selon le type de runbook. Les runbooks PowerShell et Python sont mis à l’état Stopped (Arrêté). Les runbooks PowerShell Workflow sont mis à l’état Failed (Échec).
Cause
Le runbook s’est exécuté au-delà de la limite de trois heures autorisée par la répartition de charge équilibrée dans un bac à sable Azure.
Résolution
Une solution recommandée consiste à exécuter le runbook sur un Runbook Worker hybride. Les Workers hybrides ne sont pas restreints par la limite d’exécution des runbooks de trois heures, qui s’applique aux bacs à sable Azure. Les runbooks qui s’exécutent sur les runbooks Workers hybrides doivent néanmoins être développés pour prendre en charge les comportements de redémarrage en cas de problème inattendu avec l’infrastructure locale.
Une autre solution consiste à optimiser le runbook en créant des runbooks enfants. Si votre runbook exécute une boucle via la même fonction sur plusieurs ressources, comme une opération de base de données sur diverses bases de données, vous pouvez déplacer cette fonction vers un runbook enfant. Chaque runbook enfant s’exécute en parallèle dans un processus distinct. Ce comportement réduit la quantité totale de temps pour l’exécution du runbook parent.
Applets de commande PowerShell prenant en charge le scénario avec des runbooks enfants :
- Start-AzAutomationRunbook. Cette applet de commande vous permet de démarrer un runbook et de lui transmettre des paramètres.
- Get-AzAutomationJob. Si des opérations doivent être effectuées à la fin de l’exécution du runbook enfant, cette applet de commande vous permet de vérifier l’état du travail de chaque enfant.
Scénario : Une erreur se produit dans les flux de travaux en lien avec la méthode get_SerializationSettings
Problème
Vous voyez l’erreur suivante dans votre flux de travail concernant un runbook :
Connect-AzAccount : Method 'get_SerializationSettings' in type
'Microsoft.Azure.Management.Internal.Resources.ResourceManagementClient' from assembly
'Microsoft.Azure.Commands.ResourceManager.Common, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
does not have an implementation.
At line:16 char:1
+ Connect-AzAccount -ServicePrincipal -Tenant $Conn.TenantID -Appl ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Connect-AzAccount], TypeLoadException
+ FullyQualifiedErrorId : System.TypeLoadException,Microsoft.Azure.Commands.Profile.ConnectAzAccountCommand
Cause
Cette erreur est probablement due à l’utilisation d’une migration incomplète d’AzureRM vers les modules Az dans votre runbook. Cette situation peut amener Azure Automation à démarrer un travail de runbook en utilisant uniquement des modules AzureRM, puis à démarrer un autre travail en utilisant uniquement des modules Az, ce qui aboutit à un incident de bac à sable (sandbox).
Résolution
Nous vous déconseillons d’utiliser des cmdlets Az et AzureRM dans le même runbook. Pour en savoir plus sur l’utilisation correcte de ces modules, consultez Migrer vers AZ modules.
Scénario : accès refusé lors de l'utilisation du bac à sable Azure pour un runbook ou une application
Problème
Lorsque votre runbook ou votre application tente de s’exécuter dans un bac à sable (sandbox) Azure, l’environnement refuse l’accès.
Cause
Ce problème peut se produire, car les bacs à sable (sandboxes) Azure empêchent l’accès à tous les serveurs COM hors processus. Par exemple, un runbook ou une application sandbox ne peut pas appeler Windows Management Instrumentation (WMI) ni le service Windows Installer (msiserver.exe).
Résolution
Pour plus d’informations sur l’utilisation de bacs à sable (sandbox) Azure, consultez Environnement d’exécution de runbook.
Scénario : Code d’état interdit non valide lors de l’utilisation de Key Vault dans un runbook
Problème
Lorsque vous tentez d’accéder à Azure Key Vault à l’aide d’un runbook Azure Automation, vous obtenez l’erreur suivante :
Operation returned an invalid status code 'Forbidden'
Cause
Les causes possibles de ce problème sont :
- N’utilise pas de compte d’identification.
- Autorisations insuffisantes.
Résolution
N’utilise pas un compte d’identification.
Suivez les instruction de l’Étape 5 : Ajouter l’authentification pour gérer les ressources Azure pour vous vérifier que vous utilisez un compte d’identification pour accéder à Key Vault.
Autorisations insuffisantes
Ajoutez des autorisations à Key Vault pour vous assurer que votre compte d’identification dispose d’autorisations suffisantes pour accéder à Key Vault.
Scénario : le runbook échoue avec l’erreur « Longueur du paramètre dépassée »
Problème
Votre runbook utilise des paramètres, puis échoue avec l’erreur suivante :
Total Length of Runbook Parameter names and values exceeds the limit of 30,000 characters. To avoid this issue, use Automation Variables to pass values to runbook.
Cause
Il existe une limite à la longueur totale des caractères de tous les paramètres pouvant être fournis dans les runbooks Python 2.7, Python 3.8 et PowerShell 7.1. La longueur totale de l’ensemble des noms de paramètres et des valeurs de paramètres ne doit pas dépasser 30 000 caractères.
Résolution
Pour résoudre ce problème, vous pouvez utiliser Azure Automation Variables pour transmettre des valeurs au runbook. Vous pouvez également réduire le nombre de caractères dans Noms de paramètres et Valeurs de paramètre pour garantir que la longueur totale ne dépasse pas 30 000 caractères.
Documents recommandés
Étapes suivantes
Si votre problème ne figure pas dans cet article, ou si vous ne parvenez pas à le résoudre, utilisez un des canaux suivants pour obtenir de l’assistance :
- Obtenez des réponses de la part d’experts Azure via les Forums Azure.
- Connectez-vous à @AzureSupport, le compte Microsoft Azure officiel pour améliorer l’expérience client. Le Support Azure vous met en relation avec la communauté Azure pour obtenir des réponses, un support technique et des experts.
- Si vous avez besoin de plus d’aide, vous pouvez signaler un incident au support Azure. Accédez au site du support Azure, puis sélectionnez Obtenir de l’aide.