Select Language:
If you’re working with Azure Automation and PowerShell 7.2, you might encounter a common problem: the Az modules don’t load automatically in your runbook unless they’re properly imported for the right runtime and fully provisioned.
This issue typically happens for three main reasons. First, the runtime version might not match. For example, if your runbook is set to PowerShell 7.2 but the modules were imported without specifying this version, they could default to PowerShell 5.1. Second, modules go through a provisioning process when you use commands like New-AzAutomationModule. If you try to run your job before the modules are fully available, the import will fail. Third, dependencies matter. Some Az modules depend on others, like Az.Storage relying on Az.Accounts. If these dependencies aren’t aligned to the same runtime, the modules may silently fail to import.
To fix this, start by checking your runbook’s runtime version. Go into the Azure portal, navigate to your Automation Account, then to Runbooks, select your specific runbook, and verify that the runtime version is set to PowerShell 7.2. If it’s not, update it accordingly. If you created the runbook using PowerShell, re-import it and specify the runtime version with the parameter -Type PowerShell72.
Next, you need to make sure the modules are imported for PowerShell 7.2. In the portal, go to your Automation Account, then Shared Resources > Modules and browse the gallery. Search for modules like Az.Accounts and Az.Storage. When you add them, choose the runtime version 7.2. Before running your job, wait until their status shows as “Available.” You can also do this manually with PowerShell commands:
powershell
New-AzAutomationModule -AutomationAccountName "YourAutomationName"
-ResourceGroupName “YourResourceGroup” -Name "Az.Accounts"
-ContentLinkUri “https://www.powershellgallery.com/api/v2/package/Az.Accounts/4.2.0” `
-RuntimeVersion “7.2”
New-AzAutomationModule -AutomationAccountName "YourAutomationName"
-ResourceGroupName “YourResourceGroup” -Name "Az.Storage"
-ContentLinkUri “https://www.powershellgallery.com/api/v2/package/Az.Storage/3.7.0” `
-RuntimeVersion “7.2”
Afterwards, ensure your modules are updated to their latest versions for runtime compatibility.
Finally, at the very top of your runbook script, add some validation code to confirm the modules are loaded properly:
powershell
Write-Output “PowerShell Version: $($PSVersionTable.PSVersion)”
Write-Output “Module Path: $env:PSModulePath”
Get-Module -ListAvailable Az.Accounts, Az.Storage | Select-Object Name, Version, ModuleBase
If these modules aren’t listed, then the provisioning isn’t complete yet. Wait a little longer and check again.
A key point to remember: avoid mixing AzureRM modules with Az modules within the same Automation account; doing so isn’t supported. If you need your jobs to run immediately and modules are still provisioning, consider setting up a Hybrid Runbook Worker on your VM with the modules installed locally.
PowerShell 7.2 is approaching its end-of-life, but if you run into persistent issues, you might want to consider upgrading to PowerShell 7.4, which is now available in Azure Automation. The sandbox environment for PowerShell 7.4 is still on a 64-bit Windows OS, similar to before. To switch to this newer runtime environment, follow the instructions provided in your Azure portal’s runtime environment options.
If you have more questions or need further help, don’t hesitate to reach out. Happy scripting!
ChatGPT
Perplexity
Gemini AI
Grok AI
