Block AzureRM PowerShell Module

TL;DR

The AzureRM module is deprecated. This guide shows you how to prevent its use in your environment, ensuring a smooth transition to the Az module and improving cyber security by removing older, potentially vulnerable code.

Steps to Block the AzureRM PowerShell Module

1. Understand Why You Need to Block AzureRM

• AzureRM is no longer supported. Microsoft recommends using the Az module for all new scripts and deployments.
• Continuing to use AzureRM introduces risks, including potential compatibility issues and security vulnerabilities.

Check if AzureRM is Installed

Run the following command in PowerShell to see if the AzureRM module is present:

Get-Module -ListAvailable AzureRM

If it returns information about the module, it’s installed. If it says nothing is found, skip to step 4.

Uninstall AzureRM (Recommended)

The best approach is to uninstall the module completely:

Uninstall-Module -Name AzureRM -AllVersions

You may be prompted for confirmation. Type ‘Y’ and press Enter.

Prevent Installation via PowerShellGet

To stop users from accidentally installing AzureRM in the future, you can block it in your PowerShellGet settings:

• Option 1: Block at the Provider Level (Recommended) – This prevents any package from that provider being installed.

Set-PSRepository -Name PSGallery -InstallationPolicy Block

Option 2: Block a Specific Package – This blocks only AzureRM.

Set-PackageSource -Name PSGallery -ProviderName NuGet -Blocked $true

Verify the Block

After blocking, try to install AzureRM again:

Install-Module -Name AzureRM

You should receive an error message indicating that the module is blocked.

Update Existing Scripts

This is the most important step. Replace all instances of AzureRM cmdlets with their equivalent Az counterparts. For example:

• Get-AzureRmVM becomes Get-AzVM
• New-AzureRmResourceGroup becomes New-AzResourceGroup

Microsoft provides detailed migration guides to help with this process.

Test Your Updated Scripts

Thoroughly test all updated scripts in a non-production environment before deploying them to production. This ensures that the changes haven’t introduced any unexpected issues.