Starting the runbook on Automation accounts containing Az modules may lead to intermittent failures

[AnatoliB]

No description provided.

[AnatoliB]

The runbook updates AzureRM.* modules but not Az.* modules

[ayoung012]

See below my tests using this runbook in its current state to update Az.Storage to the latest version 1.2.0 from 1.1.0:

Importing Array of modules : Az.Storage
Importing Az.Storage module of version 1.2.0 to Automation
Checking import Status for module : Az.Storage
Successfully imported module : Az.Storage

The documentation in this repository and the link below led me to believe this would not work.

https://docs.microsoft.com/en-us/azure/automation/automation-update-azure-modules

Specifically the points:

• This runbook supports updating only the Azure and AzureRm modules currently. Azure PowerShell Az modules are supported in Automation accounts, but cannot be updated with this runbook.
• Avoid starting this runbook on Automation accounts that contain Az modules.

Can anyone explain why this is an issue?

[AnatoliB]

@ayoung012 Depending on the content of your Automation account (imported modules, running runbooks) and the timing, you may get lucky and not run into any issues. However, in general case, various intermittent problems are expected. The root cause of this the inability of AzureRM and Az modules to work side-by-side in the same PS session or the same process. Azure Automation can reuse PS sessions and sandbox processes between cloud jobs for the same Automation account, and the user does not have direct control over this. In order to makes sure AzureRM and Az modules are not mixed, we recommend isolating them on the Automation account level (see Az module support in Azure Automation for more details). The runbook in this repository breaks these guidelines by explicitly loading AzureRM modules into the current PS session. This may lead to failures if this job happens to be running on a cloud sandbox executing another job that loads Az modules.

One way to fix this would be to modify this runbook to:

• accept a parameter indicating whether AzureRM or Az modules should be updated;
• depending on the passed value:
  • load either AzureRM.Profile + AzureRM.Automation or Az.Accounts + Az.Automation at the beginning;
  • ignore (don't try to update) either Az.* modules or AzureRM.* modules already available on this account.

[ayoung012]

@AnatoliB thanks for the in depth explanation. The main issue here is now clear. This runbook is using the AzureRM.Profile + AzureRM.Automation modules, and is designed to update AzureRM.* modules only. When Az.* modules are installed in an automation account, this runbook will pick them up anyway and may cause failures.

Based on your modification suggestion, have you got anything against maintaining two different update runbooks:

• this one modified intentionally to update only AzureRM.* modules
• another that loads Az.Accounts + Az.Automation to update Az.* modules only.

Seperate runbooks would make it really clear that this separation is necessary, rather than parameters and module imports based on clauses.

[AnatoliB]

@ayoung012 Yes, maintaining two different runbooks would also work. However, one drawback I see is that these two runbooks would have to share some code (specifically, the code querying the PS Gallery and the logic of ordering module updates according to the dependency graph), with all the consequences of code duplication. This is not terrible, but something to consider.

[ayoung012]

@AnatoliB I see your point, agreed. Factor in that only four out of the eleven functions implemented use a AzureRM specific module, one of:

• Add-AzureRmAccount
• Select-AzureRmSubscription
• Get-AzureRmAutomationModule
• New-AzureRmAutomationModule

So code duplication would be pretty major if two runbooks were to be maintained.

[mortenlerudjordet]

As AA loads all modules I do not think it is advised to have both AzureRM and Az imported in the same account. Not sure how AA team plans to tackle this. Probably needs to be able to make choice at account creation time what type of Azure modules to use.

From doc:
"You cannot load Az and AzureRM modules in the same PowerShell session"
https://github.com/Azure/azure-powershell/blob/master/documentation/announcing-az-module.md

[AnatoliB]

@mortenlerudjordet AA does not load all modules to PS sessions. Only those modules that are actually used or explicitly imported with Import-Module are loaded. Please see https://docs.microsoft.com/en/azure/automation/az-modules for the guidelines on using Az in Azure Automation. This is why the associated PR is also taking care of loading either Az or AzureRM modules, but never both.

[AnatoliB]

Az module support is implemented.