Updated Troubleshooting Module Version Incompatibilities With Azure PowerShell (markdown)

Mark Cowlishaw 2017-11-07 09:00:43 -08:00
Родитель 4051d22e00
Коммит 647256489b
1 изменённых файлов: 5 добавлений и 5 удалений

@ -25,11 +25,11 @@ At line:1 char:1
### Potential Reason 1: Older Version Stored in User or Global Scope
PowerShell allows installing multiple versions of modules. Normally, PowerShell will load the latest version of a module unless specifically instructed to load a specific version by using ```Import-Module -RequiredVersion <version>```. Howevere, if modules are installed in multiple directories of the ```PSModulePath```, then the results can be unexpected. When PowerShell searches for a module in the module path, it will return the latest version stored in the earliest path componenet where the module appears, even if a later version of the module is installed in a subsequent directory in the PSModulePath.
PowerShell allows installing multiple versions of modules. Normally, PowerShell will load the latest version of a module unless specifically instructed to load a specific version by using ```Import-Module -RequiredVersion <version>```. However, if modules are installed in multiple directories of the ```PSModulePath```, then the results can be unexpected. When PowerShell searches for a module in the module path, it will return the latest version stored in the earliest path component where the module appears, even if a later version of the module is installed in a subsequent directory in the PSModulePath.
For example, if the PSModulePath contains directory A followed by directory B, and if Directory A contains version 1 of a module, and Directory B contains version 2 of the module, PowerShell will *always* load version 1, unless the entire path to the later moduel in directory B is provided when importing the module.
For example, if the PSModulePath contains directory A followed by directory B, and if Directory A contains version 1 of a module, and Directory B contains version 2 of the module, PowerShell will *always* load version 1, unless the entire path to the later module in directory B is provided when importing the module.
To determine if this problem occurs on your machine, run ```Get-Module -ListAvailable``` and check for deuplicate entries for AzureRM.Profile in different directories in the ```PSModulePath```. For example:
To determine if this problem occurs on your machine, run ```Get-Module -ListAvailable``` and check for duplicate entries for AzureRM.Profile in different directories in the ```PSModulePath```. For example:
```powershell
c:\> Get-Module -ListAvailable
@ -59,7 +59,7 @@ To resolve this problem, simply remove all versions of Azure PowerShell cmdlets
Additionally, because the Azure and AzureRM modules are installed separately, they are not always updated at the same time. If the 'Azure' module is updated without updating any installed AzureRM modules, then a version of AzureRM.profile that is compatible with the new 'Azure' module, but not compatible with the older 'AzureRM' modules may be loaded by default, and authentication will not work for AzureRM modules.
To detect this problem, again, run ```Get-Module -ListAvailable``` and look for multiple versions of ```Azure``` and ```AzureRm.Profile``` in the same directory in the module path, but fewer versions of other AzureRM Modules.
To detect this problem, run ```Get-Module -ListAvailable``` and look for multiple versions of ```Azure``` and ```AzureRm.Profile``` in the same directory in the module path, but fewer versions of other AzureRM Modules.
For example:
@ -81,7 +81,7 @@ Script 4.0.0 AzureRM.profile {Disable-AzureRmDataCo
Script 3.4.1 AzureRM.profile {Disable-AzureRmDataCollection, Disable-AzureRmContextAuto...
```
As shown above, the 'Azure' mdouel was updates without updating AzureRM.Compute, resulting in log in provlems when using compute cmdlets.
As shown above, the 'Azure' module was updated without updating AzureRM.Compute, resulting in log in problems when using compute cmdlets.
To resolve the issues, update all AzureRM modules (for example ```Update-Module AzureRM.Compute```), or remove the later versions of 'Azure'.