Unable to import Az.* modules in PowerShell 7.2 Automation Runbook

Question

I've created a new Automation Account and a PowerShell 7.2 runbook with this content:

Write-Output "PS: $($PSVersionTable.PSVersion)"
Write-Output "ModulePath: $env:PSModulePath"
Import-Module Az.Accounts -Verbose
Import-Module Az.Storage  -Verbose
Get-Module -ListAvailable Az.Accounts,Az.Storage | Select-Object Name,Version,ModuleBase

Yet, when I run the runbook, it fails with two errors about being unable to import Az.Accounts and Az.Storage.

I even tried forcing it to load the modules with a routine that CoPilot gave me that invokes Get-AzAutomationModule on each, but even after that, the runbook fails.

What am I doing wrong? How to create a PowerShell 7.2 runbook with Az modules?

Answer 1

Hello Jason R. Coombs Thanks for the detailed repro. Based on the logs and your script, there are two concrete issues to fix:

1. Cmdlets are called before the module is loaded
   • Disable-AzContextAutosave, Connect-AzAccount, and Set-AzContext live in Az.Accounts. In your script they’re invoked before Import-Module Az.Accounts, so the job can’t resolve them.
   • Fix: import Az.Accounts first, then call those cmdlets
   • Reference: https://learn.microsoft.com/en-us/powershell/module/az.accounts/disable-azcontextautosave?view=azps-15.1.0
2. Assembly dependency mismatch for the 7.2 sandbox
   • The errors about Azure.Core and Microsoft.Identity.Client.Extensions.Msal show the Az module set for 7.2 isn’t fully aligned in the sandbox. The supported way to repair this in Azure Automation is to refresh the default Az module set for the 7.2 runtime (which rehydrates dependency chains). If “latest” blocks you from updating, roll back to a lower Az set and then upgrade—this forces a rebuild of the module graph.
   • Reference: https://learn.microsoft.com/en-us/azure/automation/automation-update-azure-modules

Please try below workarounds:

Refresh the Az module set for PowerShell 7.2

1. In the portal: Automation Account → Shared resources → Modules → Update Az modules.
2. Select Runtime version = 7.2 and a stable Az version (e.g., 11.2.0). Click Update.
3. If the UI says you’re already on the latest, choose an earlier Az version (e.g., 8.x) to roll back, then run Update again to move back to 11.2.0. This rollback/upgrade path is supported and rebuilds dependencies.Wait for all default Az modules to show Status = Available under the 7.2 runtime.

If you’re using the newer Runtime Environment experience, prefer a runtime with PowerShell 7.2 and defaultPackages { Az: '11.2.0' }, then assign that runtime to your runbook. It cleanly isolates module versions per runtime.

Remove “helper” commands you don’t need

• Register-AzModule isn’t required in Automation runbooks; delete it from your script. The module loader plus Import-Module is sufficient.

Fix your runbook ordering (minimal working sample)

Use this exact order so cmdlets resolve after the module is loaded:

# Show runtime
Write-Output "PS: $($PSVersionTable.PSVersion)"
Write-Output "ModulePath: $env:PSModulePath"

# 1) Import modules FIRST (stop on failure)
Import-Module Az.Accounts -ErrorAction Stop
Import-Module Az.Storage  -ErrorAction Stop

# 2) Context hygiene + auth
Disable-AzContextAutosave -Scope Process
$ctx = (Connect-AzAccount -Identity).Context
Set-AzContext -DefaultProfile $ctx | Out-Null

# 3) Verify modules resolved
Get-Module -ListAvailable Az.Accounts, Az.Storage |
  Select-Object Name, Version, ModuleBase

This resolves your specific errors:

• CommandNotFound for Disable/Connect/Set: Occurs when Az.Accounts isn’t loaded yet. Importing the module before calling those cmdlets fixes it.
• Azure.Core / MSAL extension load failures: The Update Az modules action refreshes and aligns the dependency chain that Az modules rely on for 7.2 jobs; rollback then upgrade is the supported way to force a rebuild when “latest” blocks an update.

If problems persist after the refresh:

Azure’s cloud sandbox has known limits; certain module/assembly loads can still fail depending on versions and calls. The supported workaround is to run the job on a Hybrid Runbook Worker (extension‑based), which executes outside the sandbox and avoids these load constraints.

Reference: https://learn.microsoft.com/en-us/azure/automation/shared-resources/modules#sandboxes

Are you using the classic Modules blade or the Runtime Environment (Preview) experience for this Automation Account?

Thanks,
Suchitra.

Answer 2

Ultimately, we managed to get something working, but only after lots of fiddling and interactive operations in the portal. Attempting non-interactive provisioning of PowerShell 7.2 runtimes should probably be avoided until the process is better understood and documented.

Answer 3

To resolve the issue of not being able to import the Az modules in your PowerShell 7.2 runbook, ensure that the modules are correctly imported into your Automation account. Here are some steps to follow:

1. Check Module Availability: Ensure that the Az.Accounts and Az.Storage modules are imported into your Automation account. You can do this by navigating to your Automation account in the Azure portal, selecting Modules under Shared Resources, and verifying that both modules are listed.
2. Update Modules: If the modules are present but still not importing correctly, they may be outdated. You can update the Azure modules by selecting Update Azure modules in your Automation account's Modules section. This process may take some time, so allow for that before testing again.
3. Explicit Import: In your runbook, you can explicitly import the modules using the Import-Module cmdlet. However, if the modules are not available in the Automation account, this will not work. Ensure that the modules are available and up to date.
4. Runbook Configuration: Ensure that your runbook is configured to use the correct runtime version (PowerShell 7.2) and that it is not conflicting with any other versions of PowerShell or modules.
5. Check for Errors: If you continue to receive errors, check the error messages for specifics. Common issues include the modules not being recognized due to them not being imported or being out of date.

By following these steps, you should be able to successfully import the Az modules in your PowerShell 7.2 runbook.