Azure and AzureRM Powershell Module Conflicts - azure

I'm setting up an Azure DevOps self hosted pipeline agent. We have some legacy cloud services, so we need the "old" Azure powershell module that targets the service management API. We also obviously use Azure Resource Manager, so either the AzureRM or the new Az module is also required.
We currently have the Azure module version 5.3.0 and AzureRM module version 6.13.1 being installed using the following commands:
Install-Module -Name Azure -RequiredVersion 5.3.0 -AllowClobber -Scope AllUsers -Force
Install-Module -Name AzureRM -RequiredVersion 6.13.1 -AllowClobber -Scope AllUsers -Force
The problem we're encountering is that, depending on the order these modules are imported, we will get script failures. If, for example, the order of import is Azure followed by AzureRM, we get the following error:
Import-Module : The following error occurred while loading the
extended type data file: Error in TypeData
"Microsoft.Azure.Commands.Common.Authentication.Abstractions.IAzureContextContainer":
The TypeConverter was ignored because it already occurs. Error in
TypeData
"Microsoft.Azure.Commands.Common.Authentication.Abstractions.IAzureContextContainer":
The member SerializationDepth is already present. Error in TypeData
"Microsoft.Azure.Commands.Common.Authentication.ProtectedFileTokenCache":
The member PropertySerializationSet is already present. Error in
TypeData
"Microsoft.Azure.Commands.Common.Authentication.ProtectedFileTokenCache":
The member SerializationMethod is already present. Error in TypeData
"Microsoft.Azure.Commands.Common.Authentication.AuthenticationStoreTokenCache":
The member PropertySerializationSet is already present. Error in
TypeData
"Microsoft.Azure.Commands.Common.Authentication.AuthenticationStoreTokenCache":
The member SerializationMethod is already present. Error in TypeData
"Microsoft.Azure.Commands.Profile.Models.PSAzureContext": The member
SerializationDepth is already present. Error in TypeData
"Microsoft.Azure.Commands.Profile.Models.PSAzureProfile": The member
SerializationDepth is already present. At C:\Program
Files\WindowsPowerShell\Modules\AzureRm\6.13.1\AzureRM.psm1:81 char:1
+ Import-Module AzureRM.Profile -RequiredVersion 5.8.2 -Global
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Import-Module], RuntimeException
+ FullyQualifiedErrorId : FormatXmlUpdateException,Microsoft.PowerShell.Commands.ImportModuleCommand
You can see this in the following screen shot:
But if import AzureRm first, followed by Azure, it appears to work fine:
The problem is, we don't control the order of the imports when using existing pipeline tasks built by Microsoft and others. We're getting failures deploying our cloud services due to the fact the cloud service deployment task built by MS happens to import Azure first.
Lastly, I tried simply not installing the old Azure module, hoping that AzureRM "came with" what it would need to handle some service management API tasks, but it does not. If I try do a deployment without the Azure module installed, we get the error:
Certificate based authentication is not supported. Azure PowerShell
module is not found.
So it appears the legacy module is required, and yet it conflicts.

This appears to be caused by the order of installation. Flipping the order from Azure then AzureRm to AzureRm then Azure resolved the issue. So the following install commands do not result in the problem:
Install-Module -Name AzureRM -RequiredVersion 6.13.1 -AllowClobber -Scope AllUsers -Force
Install-Module -Name Azure -RequiredVersion 5.3.0 -AllowClobber -Scope AllUsers -Force
It appears the root cause is that the Azure module, if installed first, will always install the most recent version of AzureRm.profile. This appears to be caused by the Azure.Storage module, which has a dependency on AzureRm.profile.
If you install the Azure module first, it will install AzureRm.profile version 5.8.3. When you then install AzureRm, it has a dependency of AzureRm.profile as well, but it will ignore the fact that you already have AzureRm.profile v5.8.3 installed and install AzureRm.profile v5.8.2. I believe this is because while the Azure module has a dependency on AzureRm.profile, the AzureRm module includes AzureRm.profile.
When Import-Module is called for Azure first, it loads v5.8.3 of the AzureRm.profile module, as it will always load the most recent version by design. When, however, AzureRm itself is loaded, it tries to load the version IT came with (v5.8.2), and this fails due to the type error noted in the question.
If you install AzureRM before Azure, it prevents this from happening. Since when the Azure module is being installed it sees there is already a version of AzureRm.profile that satisfies its dependency (or, more specifically, satisfies the dependency that Azure.Storage has), it doesn't install AzureRm.profile again. This leaves only the version that AzureRm was packaged with, and everything is fine.
Lastly, for an existing "broken" environment, running this command resolved the problem:
Uninstall-Module -Name AzureRM.profile -RequiredVersion 5.8.3

Related

module not found after converting script with ps2exe

I built a simple GUI powershell script that runs exactly how I want it on many different computers (after installing all the right modules I also tried installing them with the -scope allusers).
when I compile the script using ps2exe it throws errors as if I haven't installed some of the modules I can use on the computer.
I also made sure to import the modules at the top of the script.
I assume this has something todo with scope but I am not sure how to configure the module/exe to be able to see Az.Accounts
Note: the powershell module sqlserver seems to work just fine no issues for the exe to find and use that one.
Edit: I just tested the script with no code other than just importing the module Az.Accounts and Connect-AzAccount. again this script runs just fine before converting with ps2exe
Glad #ryankennedy712 for identifying the cause of the issue and solving yourself. Posting it as answer that would help the community members who will face similar issue.
It was the overriding of previously installed the modules of Az.Accounts with the cmdlet Install-Module Az -scope allusers -allowclobber.
Re-installation (Full Uninstall and Install) of the module Az.Accountsalong with the scope of allusers works successfully.
when I installed sqlserver module it didnt need the all users scope.
There is no scope attribute for installing the SqlServer Module installation for AllUsers in the PowerShell cmdlet. To install that module for all the users in the system, the command should be run in Elevated PowerShell Session (as an administrator) mentioned by Microsoft in this MS Doc.

Azure PowerShell SDK: Could not load file or assembly 'Azure.Storage.Queues' when Import-Module Az.Storage

I am getting the following error when running: Import-Module Az.Storage. I am not what the problem is.
PS error: System.Management.Automation.CommandNotFoundException: The 'New-AzStorageAccount' command was found in the module 'Az.Storage', but the module could not be loaded due to the following error: [Could not load file or assembly 'Azure.Storage.Queues, Version=12.12.0.0, Culture=neutral, PublicKeyToken=92742159e12e44c8'.]
For more information, run 'Import-Module Az.Storage'.
---> System.Management.Automation.CmdletInvocationException: Could not load file or assembly 'Azure.Storage.Queues, Version=12.12.0.0, Culture=neutral, PublicKeyToken=92742159e12e44c8'.
---> System.IO.FileLoadException: Could not load file or assembly 'Azure.Storage.Queues, Version=12.12.0.0, Culture=neutral, PublicKeyToken=92742159e12e44c8'.
at System.Management.Automation.Runspaces.InitialSessionState.Bind_LoadAssemblies(ExecutionContext context)
at System.Management.Automation.Runspaces.InitialSessionState.Bind(ExecutionContext context, Boolean updateOnly, PSModuleInfo module, Boolean noClobber, Boolean local, Boolean setLocation)
at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModuleManifest(String moduleManifestPath, ExternalScriptInfo manifestScriptInfo, Hashtable data, Hashtable localizedData, ManifestProcessingFlags manifestProcessingFlags, Version minimumVersion, Version maximumVersion, Version requiredVersion, Nullable`1 requiredModuleGuid, ImportModuleOptions& options, Boolean& containedErrors)
--- End of inner exception stack trace ---
The error "The 'New-AzStorageAccount' command was found in the module 'Az.Storage', but the module could not be loaded due to the following error: [Could not load file or assembly 'Azure.Storage.Queues'" usually occurs if the required dependencies are not installed for the Az.Storage module.
I tried to reproduce the same in my environment and got the results like below:
Import-Module Az.Storage
I am able to install the Az.Storage module without any error:
I created an Azure Storage Account by using the below command:
New-AzStorageAccount -ResourceGroupName RGName -Name StorageAccName -Location Location -SkuName Standard_GRS
To resolve the error, please try the below:
The Azure PowerShell Az module must be installed in order to use the Az.Storage module.
Check whether you are using the latest version of the Az module and if not, update the module version:
Install-Module -Name az
Update-Module -Name Az
Get-InstalledModule -Name Az
You can also try updating the Az.Storage module like below:
Update-Module -Name Az.Storage
Get-InstalledModule -Name Az.Storage
If still the issue persists, re-install the Az Module and check.
Uninstall-Module -Name az
Install-Module -Name az
Check the PowerShell version too. Restart the PowerShell Window after the Uninstall and Install operations.
Reference:
az.storage load errors Azure/azure-powershell ยท GitHub

Using PowerShell Implicitly Importing for an older Module version

I want to use Implicitly Importing while using the PowerShell Module Az. This module has quite a lot of submodules and I don't want to import the specific version at the start of the script because of time. The script will run on an agent, which is not controlled by me, so that it could be, that a newer Az Module will be installed without my knowledge. If so, my script should still use the older version with Implicitly Importing. But I did not find a way to load older version in this way. It is always, that the newest version is used by Implicitly Importing. I could then overwrite it by importing the older version (like in the example below), but this is exactly what I don't want to do.
PS > Get-Module Impl*
PS > GetImplicitValue()
Implicit Importing from V2
PS > Get-Module Impl*
ModuleType Version PreRelease Name ExportedCommands
---------- ------- ---------- ---- ----------------
Script 2.1.2 ImplicitlyImporting GetImplicitValue
PS > Import-Module ImplicitlyImporting -Force -RequiredVersion 1.0.2
PS > GetImplicitValue()
Implicit Importing from V1
PS > Get-Module Impl*
ModuleType Version PreRelease Name ExportedCommands
---------- ------- ---------- ---- ----------------
Script 1.0.2 ImplicitlyImporting GetImplicitValue
Script 2.1.2 ImplicitlyImporting GetImplicitValue
Any idea? Thanks in advance.
Implicit implies importing the newest version, so you do not want to implicitly import when an older version may be required.
You can reduce the amount of time to import the Az module by specifying the submodule(s) you want:
# takes 0.8 seconds for two modules
Import-Module Az.Accounts -RequiredVersion 2.8.0
Import-Module Az.Security -RequiredVersion 1.3.0
# takes 70 seconds for 76 modules
Import-Module Az
Otherwise, you can check for and explicitly specify a version to load:
# Check if Az is already loaded, and what version
$loaded = Get-Module az
if ($loaded) {
if ($Loaded.Version -eq [System.Version]'8.0.0') {'Az loaded and correct version'}
else {'Wrong version of Az loaded'}
}
# If not loaded, then check if Az is installed, and what versions
if (-not (Get-Module az)) {
# check which Az is installed
$installed = Get-InstalledModule az -AllVersions
# import correct module version
if ($installed.Version -eq [System.Version]'8.0.0') {
'Correct Version Installed'
Import-Module Az -RequiredVersion 8.0.0
}
else {
Write-Error 'Required version of Az not installed'
break
}
}
As you saw with the answer here, you must explicitly import a module or its commands to use a specific version

Problem loading Az.Kusto 2.0.0 PowerShell Module from Azure DevOps Pipeline

To automatically configure an Azure Data Explorer Database from our Azure DevOps Pipeline we use the PowerShell Module Az.Kusto.
The Function we use to execute a KQL Script is New-AzKustoScript which is only available in the latest Version of Az.Kusto, so we run the following Instruction as part of our PowerShell Script which later calls New-AzKustoScript:
Install-Module -Name Az.Kusto -RequiredVersion "2.0.0" -Force -Scope CurrentUser -AllowClobber
Locally on my development machine this works but when we run this script as part of an Azure DevOps Pipeline we get the following exception
2021-06-08T09:15:42.1278098Z $RuntimeException/ at System.Management.Automation.TypeOps.ResolveTypeName(ITypeName typeName, IScriptExtent errorPos)
2021-06-08T09:15:42.1413212Z at System.Management.Automation.Language.Compiler.NewOutputTypeAttribute(AttributeAst ast)
2021-06-08T09:15:42.1462865Z at System.Management.Automation.Language.Compiler.GetAttribute(AttributeAst attributeAst)
2021-06-08T09:15:42.1465059Z at System.Management.Automation.Language.ScriptBlockAst.<System-Management-Automation-Language-IParameterMetadataProvider-GetScriptBlockAttributes>d__68.MoveNext()
2021-06-08T09:15:42.1466223Z at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
2021-06-08T09:15:42.1485936Z at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
2021-06-08T09:15:42.1503023Z at System.Management.Automation.CompiledScriptBlockData.InitializeMetadata()
2021-06-08T09:15:42.1633625Z at Microsoft.Azure.PowerShell.Cmdlets.Kusto.Runtime.PowerShell.GetScriptCmdlet.<ProcessRecord>b__16_0(FunctionInfo fi)
2021-06-08T09:15:42.1635647Z at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
2021-06-08T09:15:42.1637257Z at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
2021-06-08T09:15:42.1693162Z at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
2021-06-08T09:15:42.1719336Z at Microsoft.Azure.PowerShell.Cmdlets.Kusto.Runtime.PowerShell.GetScriptCmdlet.ProcessRecord()
2021-06-08T09:15:43.3829832Z ##[error]Unable to find type [Microsoft.Azure.PowerShell.Cmdlets.Kusto.Models.Api202101.IOperation].
2021-06-08T09:15:43.5666125Z ##[error]PowerShell exited with code '1'.
Any help or hints will be greatly appreciated.
Updates:
Unloading Az.Kusto before installation fails with error message
"No modules were removed. Verify that the specification of modules to remove is correct and those modules exist in the runspace."
I see that in the directory C:\Modules\az_5.7.0 a version 1.0.1 of Az.Kusto is installed.
Additionally when i install Az.Kusto in Version 2.0.0, this version gets installed in C:\Users\VssAdministrator\Documents\WindowsPowerShell\Modules
When i install Az.Kusto with Scope AllUsers the Module shows up under C:\Program Files\WindowsPowerShell\Modules
When i import the Module, either by specifying a Required Version or by passing -Name and the path (Import-Module -Name "C:\Program Files\WindowsPowerShell\Modules\Az.Kusto\2.0.0\Az.Kusto.psm1" -Force -Global) i get the same error.
The Module Az.Accounts is installed in the Directory C:\Modules\az_5.7.0 in Version 2.3.0
We call New-AzKustoScript in a different PowerShell Script than the one we have the Install-Module and Import-Module calls in. Might this be an issue?
Adding another step to the comment, try out:
# Unload existing version and reinstall without clobber - removing the module should remove overlaps
Remove-Module Az.Kusto
Install-Module -Name Az.Kusto -RequiredVersion "2.0.0" -Force -Scope CurrentUser
Import-Module Az.Kusto
One of the updates in version 2.0.0 was to require a slightly different version of Az.Accounts, so check this too:
RequiredModules = #(#{ModuleName = 'Az.Accounts'; ModuleVersion = '2.2.8'; })
Here's some troubleshooting steps for awkward powershell modules. Compare the output you get on azure to your dev machine after importing the module:
# Check the loaded module:
Get-Module Az.Kusto | FL Name,Version,Path,
# On your local, try finding the missing type and the dll loading it:
[Microsoft.Azure.PowerShell.Cmdlets.Kusto.Models.Api202101.IOperation]|fl Name,Module
You may be able to manually import whatever missing dll via Import-Module /azure/module/path/to.dll. Or, you may find that that dll cannot be imported due to some error that the overall az.Kusto module suppresses.
Either way, you may want to try contacting the module creators - version 2.0.0 is less than 3 weeks old and has some other known issues: https://github.com/Azure/azure-powershell/issues?q=is%3Aissue+is%3Aopen+kusto
After isolating the situation in a new empty DevOps Pipeline i found the root of the evil.
Before installing and importing Az.Kusto, where was this call that caused all the trouble:
Import-Module Az
After removing it, those calls succeeded
Install-Module -Name Az.Kusto -RequiredVersion "2.0.0" -Force -Scope CurrentUser
Import-Module Az.Kusto -RequiredVersion "2.0.0" -Force
Thus providing access to the New-AzKustoScript Cmdlet.

Get-AzureRmSnapshot throws error Get-AzureRmSnapshot : Method 'get_SerializationSettings'

When trying to restore my azure VM from previous snapshot using powershell I get error:
Get-AzureRmSnapshot : Method 'get_SerializationSettings' in type
'Microsoft.Azure.Management.Internal.Resources.ResourceManagementClient'
from assembly 'Microsoft.Azure.Commands.ResourceManager.Common,
Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
does not have an implementation.
This is a known issue, documented by Microsoft.
The error indicates that the Azure Resource Manager modules and Az modules are loaded in the same session and those modules are not compatible with each other.
Remediation: Uninstall the conflicting modules. Either Azure Resource Manager modules or the Az modules
https://learn.microsoft.com/en-us/azure-stack/operator/azure-stack-powershell-install?view=azs-2008
Close powershell and try relauch. It fixed the issue.
Hope it help others who is facing the similar issue.

Resources