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?
CodePudding user response:
Background information:
Get-InstalledModule
does not list all locally available modules, it lists only those that were installed withInstall-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 theAllUsers
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 theAllUsers
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 thatInstall-Module
cannot discover the existingAz*
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
orCurrentUser
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).