FIX: Import-Module Az.Accounts in Azure Automation sandbox

FIX: The term ‘AZ.ACCOUNTS CMDLET‘ is not recognized as a name of a cmdlet, function, script file, or executable program

I’m getting several errors in an Azure Automation runbook job, all of which amount to the same thing.
I made a seperate error messages section, because it’s too much for the intro section!

But the issue here is, the Az.Accounts module is not loaded causing the first cmdlet from the Az.Accounts module to fail and my runbook to fail completely.

What’s causing the Import-Module to fail?

This issue only arises in Azure Automation environments where multiple jobs are started at the same time, which then start on the same Azure sandbox and want to use the Az.Accounts module, which then wants to call the PSConfig.json but cannot open it because it is already using is run by another process on the sandbox:

The process cannot access the file ‘C:\Users\Client\.Azure\PSConfig.json’ because it is being used by another process

And that’s because it wants to see if EnableDataCollection is enabled…

{
    "Az": {
        "EnableDataCollection": true
    }
}

Could this theoretically occur on a Hybrid Worker? Yes, in the end you would theoretically have the same problem there, but I haven’t tested this.

Let’s fix Import-Module Az.Accounts The process cannot access the file ” because it is being used by another process

This is easily solved by importing the module manually (instead of automatically via a cmdlet) and continuing to call it until it has been loaded.

I handle my powershell sections in regions with a try {} catch {} block.
I don’t want to spend too much time on this, but in principle you can use and edit mine the way you want. See the section below for the full script to resolve this issue.

After my block Import-Module Az.Accounts will finally work, or throw an error and ending the runbook in error state.

Complete PowerShell region I use in my runbook(s)

#region Must have modules before starting runbook
$VerbosePreference = 'SilentlyContinue'
$i = 0
$MaxSeconds = 300
$tryEvery = 5
while (($i -ne $MaxSeconds) -and ($ImportSuccessful -ne $true)) {
    try {
        $null = Import-Module Az.Accounts -ErrorAction Stop
        $ImportSuccessful = $true
    }
    catch {
        Write-Warning "Importing Az.Accounts failed, retrying in 5 seconds. Attempt $i of $MaxSeconds"
        $i = $i + $tryEvery
        Start-Sleep -Seconds $tryEvery
    }
}
if ($ImportSuccessful -ne $true) {
    $ImportAttempts = $MaxSeconds / $tryEvery
    throw "Importing Az.Accounts failed after $ImportAttempts attempts and $MaxSeconds seconds, exiting script"
}
$VerbosePreference = 'Continue'
#endregion Must have modules before starting runbook

List of the errors I received in the job errors output

Most common one is probably the not recognized as a name of a cmdlet, function, script file, or executable program, that could be with all cmdlets from the module.

I received it with Disable-AzContextAutosave though (You may of course wonder why I run this within a runbook job on a sandbox environment).

The term ‘Disable-AzContextAutosave’ is not recognized as a name of a cmdlet, function, script file, or executable program

After importing the module manually I received a list of errors:

• Import-Module (Join-Path -Path $PSScriptRoot -ChildPath Microsoft.Azu …) The process cannot access the file ‘C:\Users\Client.Azure\PSConfig.json’ because it is being used by another process
• The module to process ‘Az.Accounts.psm1’, listed in field ‘ModuleToProcess/RootModule’ of module manifest ‘C:\ModulesV2\Global\Az.Accounts\Az.Accounts.psd1’ was not processed because no valid module was found in any module directory.

They are difficult to write out because they are divided into one line per row error output: