3

My Windows 11 laptop has two versions of PowerShell installed:

  • 5.1.22621.963
  • 7.3.1 (PowerShell Core)

Following MS instructions, I want to install the Az module in PowerShell 7.3, so I use this command:

Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force

This gives me the following error:

Install-Package: The following commands are already available on this system:'Login-AzAccount,Logout-AzAccount,Resolve-Error,Send-Feedback'. This module 'Az.Accounts' may override the existing commands. If you still want to install this module 'Az.Accounts', use -AllowClobber parameter

This error is discussed in this SO post. The solution given there is to remove all the pre-existing Az modules from the PowerShell 5.x installation. This doesn't fit my situation, as (1) I don't have any Az modules currently installed in either version of PowerShell and (2) I'm not interested in modifying my PowerShell 5.x installation. Please notice these results:

# From PowerShell 5.x
PS C:\Users\BArias> Get-InstalledModule -Name AzureRM -AllVersions -OutVariable AzVersions

Version    Name                                Repository           Description
-------    ----                                ----------           -----------
5.7.0      AzureRM                             https://www.power... Azure Resource Manager Module

And then...

# From PowerShell 7.3.x
PS C:\Users\BArias> Get-InstalledModule -Name AzureRM -AllVersions -OutVariable AzVersions
Get-Package: No match was found for the specified search criteria and module names 'AzureRM'.

I get the same "No match" result for -Name Az. In other words, there should be no reason that I need to remove either Az or AzureRM from my PowerShell 7.3.x, because such things simply aren't there. Furthermore, I am complying with the MS "coexistence" rules of AzureRM and AZ.

So this brings me back to square one. Why am I getting the This module 'Az.Accounts' may override the existing commands error, when my PowerShell 7.3.x does not have AzureRM installed?

It seems like installing the Az module into PowerShell 7.3.x is a no-brainer, so why does it not "just work?" I'm left with the impression that maybe there is something inherently incorrect with attempting to install the Az module into PowerShell 7? For example, is MS simply expecting that I will use the "Azure Cloud Shell" and I shouldn't be fiddling with my PowerShell 7?

Brent Arias
  • 29,277
  • 40
  • 133
  • 234
  • Try `Get-Command Login-AzAccount | Select Name, Module` to see if command exists and if so, from what module. – Daniel Jan 18 '23 at 20:20
  • @Daniel it says the module is `AzureRM.Profile`. The heck? I'm not sure what to do with that information. When I then issue `Get-InstalledModule` and specify `-Name AzureRM.Profile`, it says "no match was found." What the heck?! – Brent Arias Jan 18 '23 at 20:22

1 Answers1

2

Background information:

  • Get-InstalledModule does not list all locally available modules, it lists only those that were installed with Install-Module, in a given edition of PowerShell.

  • To see all locally available modules, use Get-Module with the -ListAvailable switch (without -ListAvailable, only the currently loaded modules are listed.

  • Modules not covered by Get-InstalledModule include:

    • Modules that ship with PowerShell.

    • Modules manually copied into one of the directories listed in $env:PSModulePath, the environment variable that PowerShell uses for module auto-loading.

    • In PowerShell (Core), specifically, those modules that were installed with Install-Module, but from Windows PowerShell, in the AllUsers scope (-Scope AllUsers), given that PowerShell (Core)'s $env:PSModulePath contains the following Windows PowerShell-specific directories too:

      • $env:ProgramFiles\WindowsPowerShell\Modules (the dir. for the AllUsers scope of user-installed modules)
      • $env:windir\System32\WindowsPowerShell\v1.0\Modules (the modules that ship with Windows PowerShell)

Therefore, to be sure that there are truly no Az-related modules installed, run the following:

Get-Module -ListAvailable Az* | Select-Object Name, Path

If you find any, uninstall them - possibly from Windows PowerShell - with Uninstall-Module (to uninstall modules in the AllUsers scope, you'll need to run with elevation), and then try installing from PowerShell (Core) again.

If you do not want to remove installed Azure modules from your Windows PowerShell installation, you can try the following (untested):

  • Before running Install-Module in PowerShell (Core), (temporarily) remove the $env:ProgramFiles\WindowsPowerShell\Modules entry from $env:PSModulePath, so that Install-Module cannot discover the existing Az* modules there, which you can do as follows (this only modifies the process-specific copy of the environment variable; the next session will again see the registry-defined value):

    $env:PSModulePath = ($env:PSModulePath -split ';' -ne "$env:ProgramFiles\WindowsPowerShell\Modules") -join ';'
    
  • Once installed in a PowerShell (Core)-specific directory (whether in the AllUsers or CurrentUser scope), that installation should take precedence over the version in $env:ProgramFiles\WindowsPowerShell\Modules, given that PowerShell (Core)-specific entries are listed before the Windows PowerShell-specific ones in $env:PSModulePath.

Another, less desirable option would be to uninstall the module from the AllUsers scope in Windows PowerShell and re-install in the CurrentUser scope (of potentially multiple users that need it). Given that PowerShell (Core) sees only the AllUsers-scoped modules installed with Install-Module, moving them to the CurrentUser scope effectively hides them from PowerShell (Core).

mklement0
  • 382,024
  • 64
  • 607
  • 775
  • Wow! This is an incredible answer. For a bit more clarification...I think you are revealing that modules installed in Windows PowerShell are often (automatically?) pair-wise deployed into PowerShell Core. If so, then to uninstall from the latter, I would "normally" uninstall from the former? This would be a very strange circumstance, since the MS documentation I referenced in my OP makes it very clear that `AzureRM` and `Az` can co-exist, and no mention is made of needing to use either of your proposed solutions. It's possible there is a third option we're missing? – Brent Arias Jan 19 '23 at 16:28
  • @BrentArias, they're not _deployed_, they are just _visible_ to PowerShell Core, by virtue of including the two WinPS-directories listed in the answer in `$env:PSModulePath`. If PS Core sees your Azure module via `$env:ProgramFiles\WindowsPowerShell\Modules`, i.e. the _WinPS_ all-users location and that is what prevents installing (a different) module in PS Core, then you'll either have to uninstall _from WinPS_ (or conceivably install in the _user_ scope instead) or try the proposed temporary-`$env:PSModulePath`-modification workaround. All of this isn't specific to Azure modules. – mklement0 Jan 19 '23 at 17:01
  • @BrentArias, I'm not familiar with the Azure modules, but the [docs](https://learn.microsoft.com/en-us/powershell/azure/troubleshooting?view=azps-9.3.0#az-and-azurerm-coexistence) state: "We do not support having both the AzureRM and Az PowerShell modules installed in Windows PowerShell 5.1 at the same time." It sounds like there's an explicit check, which also affects your cross-edition scenario. – mklement0 Jan 19 '23 at 17:02
  • My preference is first...attempt to change the Windows PowerShell `AzureRM` module from "all-users" to "user-scope". I don't know how to do that, short of completely uninstalling and re-installing. Is there a better way? Otherwise, how exactly should `AzureRM` be completely re-installed, if necessary? My second preference is your "temporary" path workaround, on condition that there is a way to revert to "as before" if I run into a problem - or otherwise do surgery on the path-config. That means I want to know where (in the Registry?) this path info is kept, if I need heavy-handed repairs. – Brent Arias Jan 19 '23 at 17:38
  • @BrentArias, modifying an `$env:` variable as shown in the answer only modifies the _process-local copy_ of it - the _persistent_ value that is stored in the registry automatically resurfaces if you start a new session. As for uninstalling and reinstalling: links to the relevant cmdlets, `Uninstall-Module` and `Install-Module`, are in the answer; use `-Scope CurrentUser`. – mklement0 Jan 19 '23 at 17:55