My Windows 11 laptop has two versions of PowerShell installed:
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?
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).