Azure-docs: Az - Cannot remove AzureRM modules, and AzureRM modules randomly loads automatically

[o-l-a-v]

Given your documentation.

• Migrating to Az modules
  
  
  
  • Importing Az modules into the PowerShell session
  
  
  • Remove the AzureRM modules
  
  

This documentation states that:

1. You can remove the AzureRM modules.

2. You can successfully import the Az module every time, reliably, with "Import-Module" cmdlet.

When in fact neither is true.

1. There is currently no way of completely removing AzureRM modules from an Automation Account, the option is grayed out in the portal, and using the Az module to uninstall them also fails.
   

2. Import-Module -Name 'Az.Accounts' sometimes randomly fails because Automation Account randomly automatically loads AzureRM.Profile to the session.
   

Requests:

• Please verify the information in your documentation.
• Please also specify whether it's possible to stop the Automation Account automatic loading of AzureRM modules, I've found no 100% reliable way of doing this yet.
  
  
  
  • #Requires -Modules 'Az.Accounts' does not work, "AzureRM.Profiles" still sometimes loads automatically.
  
  
  • Import-Module -Name 'Az.Accounts' as the first line in the runbook does not work reliably either, "AzureRM.Profiles" STILL sometimes loads automatically before this cmdlet is run.
  
  

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: f895a4a7-ab8c-b63e-58b9-b5ecaebd7bc9
• Version Independent ID: 90dcb4e2-b017-93a5-15af-20e355ccefb4
• Content: Manage modules in Azure Automation
• Content Source: articles/automation/shared-resources/modules.md
• Service: automation
• GitHub Login: @MGoedtel
• Microsoft Alias: magoedte

[BharathNimmala-MSFT]

@o-l-a-v Thank you bringing this to our notice. I have assigned this issue to our document author @MGoedtel to further look into it.

[MGoedtel]

This behavior can be caused if you don't have Contributor rights to the Automation account. Please check the RBAC permissions you have been granted, as the documentation is factually correct about deleting modules from an Automation account via portal or PowerShell cmdlet(s). See the following article about RBAC permissions for Automation account for further details. If you are still having issues, please open a support case. #please-close

[o-l-a-v]

@MGoedtel

Have you tried this yourself? I'm owner on the automation accounts (yes, multiple, same problem/ behavior) in question. Neither GUI or PowerShell works for removing AzureRM modules. At least not last time i tried some weeks ago.

[MGoedtel]

@o-l-a-v - Yes I tried it yesterday before responding to the issue and wasn't able to repro it, which is why I suspected it was most likely related to RBAC permissions issue. #reopen issue and will investigate further when I return on Monday.

[MGoedtel]

assign:mgoedtel

[Falconwmua]

I just tested it in my subscription and all the AzureRM modules are marked as Global modules and not able to be removed.

[MGoedtel]

Modules marked as Global cannot be deleted from your Automation account. Those are modules provided by default when you create your Automation account and under the Default module section, it states that you cannot delete the default modules (which are listed in the table in that section). The point about not being able to delete Global modules is made in the article Update Azure PowerShell modules, which should also have been made in this article about managing modules to be consistent. While I recently took over managing this content, I was not intimately familiar with this particular area of the account, so over the weekend I investigated this further (and reviewed the two articles in detail). I also encountered inconsistency between two of my five Automation accounts, where those default modules were not marked as Global and I was able to delete them (and re-add them). Which is why I originally responded the way I did interpreting the situation as related to permissions off the bat instead of taking the time to thoroughly assess/evaluate the scenario. The section referencing the ability to remove AzureRM module cmdlets I believe is not specific enough and is too general since you can't delete the default modules included with the Automation account (and are marked as Global). You should only be able to delete modules that are installed by you the Contributor/Admin of the Automation account in support of your developed runbooks. I'm going to bug these docs and have a discussion with engineering to dig into certain details described here that bother me (including the inconsistency with those default modules that should be marked as global in my Automation account and aren't).

Hope that helps.

[MGoedtel]

One important detail I just learned that slightly changes my last response. Default modules included with your Automation account that are marked Global and are updated to a newer module version, will then show the value of "No" for the Global property. If you delete the newer module, this module is automatically returned to the previous version.

[o-l-a-v]

One important detail I just learned that slightly changes my last response. Default modules included with your Automation account that are marked Global and are updated to a newer module version, will then show the value of "No" for the Global property. If you delete the newer module, this module is automatically returned to the previous version.

Thanks for the investigation, and for sharing the results.

In other words, AzureRM cannot be removed from Automation Accounts, and AzureRM can still be randomly automatically loaded into a runbook, even if the first thing the runbook does is to import Az.Accounts, and you never use or call any AzureRM.* cmdlets ever in the runbook.

That's unfortunate, and I hope this is something that can be changed very soon. Ideally AzureRM would not be a global module thats automatically added to new Automation Accounts resources in Azure.
AzureRM has been deprecated since early 2019 from what I can see (AzureRM.rofile last version from PowerShell gallery).

[arczibdg]

Do you have any estimation when fix for such problem will be delivered?
It's really causing a problems if we want to switch to Az module.

[JPuzzled]

Is it possible to reopen this issue since it is not solved? Sure, a bit more information has been shared, but this is still an unsolved issue. I agree with o-l-a-v on this matter.

I want to use AZ instead of AzureRM to start runbooks (Start-AzAutomationRunbook vs Start-AzureRMAutomationRunbook). Unfortunitely I get "Start-AzAutomationRunbook : Object reference not set to an instance of an object." The AzureRM cmdlet however is found and does not throw such an error.

[MathmosUK]

Hi, I have also been keeping an eye on o-l-a-v 's question for some time as it is causing real havoc. Amazing we still don't have a solution or even a timeline for one. Can you please re open the original request as you must have loads of other people in the same boat.

Scrap this - I have since removed my Automation account and created a new one now as long as I don't use any AzureRM commands it works fine with AZ commands. Phew :-)