When Az PowerShell Gets Weird: How to Clean Up Duplicate Modules Without Breaking Anything

The companion code for this blog can be found here.

One thing you may have noticed is that I have been in PowerShell a bit more frequently as of late. The back story is I had a machine that all of a sudden didn't respond well with PowerShell and I spent quite a bit of time cleaning everything up. Whenever plagued with PowerShell issues, I run through an extensive list of troubleshooting every time a machine doesn't play nice and figured it might be a good time to share some of what's helped me over the years. Ultimately this step specifically was one of the things I developed as part of troubleshooting a number of years ago, so I figured it likely will help others. Windows loves to get funky (I know, I know...I should probably just switch to Apple).

So back to the topic at hand, if PowerShell starts feeling slow, flaky, or inconsistent, one of the first things I check is duplicate Az modules. Az is the Azure specific PowerShell module and if you have a machine that's been living in this world for a bit, the module (or modules) you have installed might be old and/or maybe you have duplicates.

I've found this is especially common if you have:

• Used Windows PowerShell and PowerShell 7 side by side

• Installed and/or upgraded Az modules over multiple years

• Mixed user scope and all users installs

• Used both MSI and PowerShell Gallery installs

  
  

PowerShell does not fail loudly when any of this happens. It just slows down while trying to decide which module version it should load.

The good news is you do not need to uninstall everything (once a lazy system administrator, always a lazy system administrator). You just need to clean up the older duplicates.

Why Duplicate Az Modules Cause Problems

PowerShell (inclusive of the Az module) resolves modules by walking every path in $env:PSModulePath. If you open up an elevated PowerShell environment, run $env:PSModulePath. After running that command, if it finds multiple versions of the Az module, the Az module installed in multiple locations, and across different scopes, know PowerShell has to enumerate and compare them every time you open a session or import Az.

I've found that delay adds up fast.

Step 1: See All Installed Az Modules

Start here to understand what PowerShell is dealing with.

Get-Module Az* -ListAvailable |
    Select-Object Name, Version, ModuleBase |
    Sort-Object Name, Version

If you see the same module name repeated with multiple versions or paths, you have duplication.

That alone is not wrong, but it is usually unnecessary.

Step 2: The Right Strategy

The safest approach is to keep the newest version of each Az module, remove older versions, and leave the newest version exactly where it is installed. This avoids breaking dependencies and avoids reinstalling everything.

Step 3: Remove Older Az Module Versions Only

The script I've written handles the following tasks:

• Groups Az modules by name

• Keeps the newest version

• Removes only older versions

• Works across all module paths

  
  

Run this in PowerShell (no admin required unless the module lives under Program Files).

$azModules = Get-Module Az* -ListAvailable |
    Group-Object Name

foreach ($group in $azModules) {
    $latest = $group.Group |
        Sort-Object Version -Descending |
        Select-Object -First 1

    $older = $group.Group |
        Where-Object {
            $_.Version -ne $latest.Version
        }

    foreach ($module in $older) {
        Write-Host "Removing $($module.Name) $($module.Version)"
        Write-Host "Path: $($module.ModuleBase)"

        try {
            Remove-Item $module.ModuleBase -Recurse -Force -ErrorAction Stop
        } catch {
            Write-Warning "Failed to remove $($module.ModuleBase). Try running as admin."
        }
    }
}

What this script does not do:

• It does not touch the newest version

• It does not assume a specific install path

• It does not blindly delete user scope modules

  
  

It only removes versions the Az PowerShell module that you will never need again.

Step 4: Restart PowerShell and Verify

After the cleanup, restart PowerShell and run:

Get-Module Az* -ListAvailable |
    Select-Object Name, Version, ModuleBase |
    Sort-Object Name, Version

You should now see one Az version per Az module, consistent load behavior, and faster startup and imports. If PowerShell or the Az module felt sluggish before, this often makes an immediate difference.

Why This Happens every So Often

This issue usually comes from normal usage patterns on a Windows machine. Things like installing Az in Windows PowerShell, then again in PowerShell 7, years of upgrades without pruning old versions, and different tools installing Az in different scopes lead to this behavior. Note, none of this means you did anything wrong. It just means PowerShell is being very inefficient.

Final Takeaway

If PowerShell starts acting strange, check for duplicate modules first (especially Azure's specific module). Keeping only the newest version of each Az module is (and really any PowerShell module you use on your machine) safe, reversible, and one of the highest impact fixes you can make. I hope this post helped you resolve any overall "funkiness" with PowerShell and the Az module for Azure commands. Happy PowerShellin'!