Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Az.Resources v6.6.1 fails to import to Azure Automation Account #21647

Open
o-l-a-v opened this issue Apr 25, 2023 · 77 comments
Open

Az.Resources v6.6.1 fails to import to Azure Automation Account #21647

o-l-a-v opened this issue Apr 25, 2023 · 77 comments
Assignees
Labels
ADO Issue is documented on MSFT ADO for internal tracking bug This issue requires a change to an existing behavior in the product in order to be resolved. customer-reported Tracking We will track status and follow internally

Comments

@o-l-a-v
Copy link

o-l-a-v commented Apr 25, 2023

Edit 2024-01-03:


Description

Tried three times to import Az.Resources v6.6.1 to an Azure Automation Account, but it fails.

I imported/updated Az.Accounts to v2.12.2 prior to this.

This is using the built in "Browse gallery" method.

image

Issue script & Debug output

None.

Environment data

5.1 in Azure Automation Account

Module versions

Az.Accounts v2.12.2
Az.Resources v6.6.1

Error output

Error importing the module Az.Resources. Import failed with the following error: Orchestrator.Shared.AsyncModuleImport.ModuleImportException: An error occurred when trying to import the module to an internal PowerShell session. Either the module dependencies are not imported correctly or the module is unsupported. Internal Error Message: The type initializer for 'Microsoft.Azure.Commands.Common.AzModule' threw an exception. The type initializer for 'Microsoft.Azure.Commands.Common.AzModule' threw an exception. . at Orchestrator.Activities.SetModuleVersion.GetPsModuleVersion(String moduleName, String moduleFullPath, Guid accountId, Guid moduleVersionId, InitialSessionState defaultSessionState) at Orchestrator.Activities.SetModuleVersion.InsertModuleVersion(String moduleName, ModuleLanguage moduleLanguage, String pythonModuleVersion, String moduleFullyQualifiedName, ActivitiesMetadataWorkflowExtension activitiesMetadataWorkflowExtension, Guid accountId, Guid moduleVersionId, Int64 moduleContentByteSize, ContentUriInfo contentUri, String storageUri, Int32 moduleVersion) at Orchestrator.Activities.SetModuleVersion.ExecuteInternal(CodeActivityContext context, String moduleName, ModuleLanguage moduleLanguage, String pythonModuleVersion, String modulePath, Guid accountId, Guid moduleVersionId, Int64 moduleContentByteSize, String storageUri, Int32 moduleVersion) at Orchestrator.Activities.SetModuleVersion.Execute(CodeActivityContext context) at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

@o-l-a-v o-l-a-v added bug This issue requires a change to an existing behavior in the product in order to be resolved. needs-triage This is a new issue that needs to be triaged to the appropriate team. labels Apr 25, 2023
@ghost ghost added customer-reported and removed needs-triage This is a new issue that needs to be triaged to the appropriate team. labels Apr 25, 2023
@o-l-a-v
Copy link
Author

o-l-a-v commented Apr 25, 2023

More info:

Running locally, Az.Resources v6.6.1 fails to import on Windows PowerShell 5.1, but only when using VSCode and the VSCode PowerShell Extension.

  • PowerShell.exe terminal works fine.
  • PowerShell ISE works fine
  • VSCode + PS extension + PowerShell 7.3.x = Success
  • VSCode + PS extension + Windows PowerShell 5.1 = Fail
    • It had no problems with Az.Accounts v2.12.1 and Az.Resources v6.6.0.

Some assembly conflict?

Output with verbose and debug set to 'Continue'.

Click to view
PS C:\Users\ORB\<redacted>> Import-Module -Name Az.Resources
VERBOSE: Loading module from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\Az.Resources.psd1'.
VERBOSE: Cannot verify the Microsoft .NET Framework version 4.7.2 because it is not included in the list of permitted versions.
VERBOSE: Loading 'Assembly' from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\Microsoft.Azure.Management.Authorization.dll'.
VERBOSE: Loading 'Assembly' from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\Microsoft.Azure.Management.Authorization.dll'.
VERBOSE: Loading 'Assembly' from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\Microsoft.Azure.Management.ResourceManager.dll'.
VERBOSE: Loading 'Assembly' from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\Microsoft.Azure.Management.ResourceManager.dll'.
VERBOSE: Loading 'Assembly' from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\Microsoft.Azure.Management.ManagementGroups.dll'.
VERBOSE: Loading 'Assembly' from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\Microsoft.Azure.Management.ManagementGroups.dll'.
VERBOSE: Loading 'Assembly' from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\Microsoft.Extensions.Caching.Abstractions.dll'.
VERBOSE: Loading 'Assembly' from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\Microsoft.Extensions.Caching.Abstractions.dll'.
VERBOSE: Loading 'Assembly' from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\Microsoft.Extensions.Caching.Memory.dll'.
VERBOSE: Loading 'Assembly' from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\Microsoft.Extensions.Caching.Memory.dll'.
VERBOSE: Loading 'Assembly' from path
'C:\Users\ORB\.vscode\extensions\ms-vscode.powershell-2023.3.3\modules\PowerShellEditorServices\bin\Common\Microsoft.Extensions.DependencyInjection.Abstractions.dll'.        
VERBOSE: Loading 'Assembly' from path
'C:\Users\ORB\.vscode\extensions\ms-vscode.powershell-2023.3.3\modules\PowerShellEditorServices\bin\Common\Microsoft.Extensions.DependencyInjection.Abstractions.dll'.        
VERBOSE: Loading 'Assembly' from path
'C:\Users\ORB\.vscode\extensions\ms-vscode.powershell-2023.3.3\modules\PowerShellEditorServices\bin\Common\Microsoft.Extensions.Options.dll'.
VERBOSE: Loading 'Assembly' from path
'C:\Users\ORB\.vscode\extensions\ms-vscode.powershell-2023.3.3\modules\PowerShellEditorServices\bin\Common\Microsoft.Extensions.Options.dll'.
VERBOSE: Loading 'Assembly' from path
'C:\Users\ORB\.vscode\extensions\ms-vscode.powershell-2023.3.3\modules\PowerShellEditorServices\bin\Common\Microsoft.Extensions.Primitives.dll'.
VERBOSE: Loading 'Assembly' from path
'C:\Users\ORB\.vscode\extensions\ms-vscode.powershell-2023.3.3\modules\PowerShellEditorServices\bin\Common\Microsoft.Extensions.Primitives.dll'.
VERBOSE: Loading 'Assembly' from path
'C:\Users\ORB\.vscode\extensions\ms-vscode.powershell-2023.3.3\modules\PowerShellEditorServices\bin\Common\System.Runtime.CompilerServices.Unsafe.dll'.
VERBOSE: Loading 'Assembly' from path
'C:\Users\ORB\.vscode\extensions\ms-vscode.powershell-2023.3.3\modules\PowerShellEditorServices\bin\Common\System.Runtime.CompilerServices.Unsafe.dll'.
VERBOSE: Loading 'Assembly' from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\MSGraph.Autorest\bin\Az.MSGraph.private.dll'.
VERBOSE: Loading 'Assembly' from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\MSGraph.Autorest\bin\Az.MSGraph.private.dll'.
VERBOSE: Loading 'Assembly' from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\Authorization.Autorest\bin\Az.Authorization.private.dll'.   
VERBOSE: Loading 'Assembly' from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\Authorization.Autorest\bin\Az.Authorization.private.dll'.   
VERBOSE: Loading 'FormatsToProcess' from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\Resources.format.ps1xml'.
VERBOSE: Loading 'FormatsToProcess' from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\ResourceManager.format.ps1xml'.
VERBOSE: Loading 'FormatsToProcess' from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\ResourceManager.generated.format.ps1xml'.
VERBOSE: Loading 'FormatsToProcess' from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\Tags.format.ps1xml'.
VERBOSE: Loading 'FormatsToProcess' from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\MSGraph.Autorest\Az.MSGraph.format.ps1xml'.
VERBOSE: Loading 'FormatsToProcess' from path
'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\Authorization.Autorest\Az.Authorization.format.ps1xml'.
VERBOSE: Loading module from path 'C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\MSGraph.Autorest\Az.MSGraph.psm1'.
Loaded Module 'Az.Accounts'
VERBOSE: Importing cmdlet 'Export-CmdletSurface'.
VERBOSE: Importing cmdlet 'Export-ExampleStub'.
VERBOSE: Importing cmdlet 'Export-FormatPs1xml'.
VERBOSE: Importing cmdlet 'Export-HelpMarkdown'.
VERBOSE: Importing cmdlet 'Export-ModelSurface'.
VERBOSE: Importing cmdlet 'Export-ProxyCmdlet'.
VERBOSE: Importing cmdlet 'Export-Psd1'.
VERBOSE: Importing cmdlet 'Export-TestStub'.
VERBOSE: Importing cmdlet 'Get-CommonParameter'.
VERBOSE: Importing cmdlet 'Get-ModuleGuid'.
VERBOSE: Importing cmdlet 'Get-ScriptCmdlet'.
VERBOSE: Importing cmdlet 'Add-AzADApplicationKey_Add'.
VERBOSE: Importing cmdlet 'Add-AzADApplicationKey_AddExpanded'.
VERBOSE: Importing cmdlet 'Add-AzADApplicationPassword_Add'.
VERBOSE: Importing cmdlet 'Add-AzADApplicationPassword_AddExpanded'.
VERBOSE: Importing cmdlet 'Add-AzADServicePrincipalKey_Add'.
VERBOSE: Importing cmdlet 'Add-AzADServicePrincipalKey_AddExpanded'.
VERBOSE: Importing cmdlet 'Add-AzADServicePrincipalPassword_Add'.
VERBOSE: Importing cmdlet 'Add-AzADServicePrincipalPassword_AddExpanded'.
VERBOSE: Importing cmdlet 'Get-AzADAppFederatedCredential_Get'.
VERBOSE: Importing cmdlet 'Get-AzADAppFederatedCredential_List'.
VERBOSE: Importing cmdlet 'Get-AzADApplication_Get'.
VERBOSE: Importing cmdlet 'Get-AzADApplication_List'.
VERBOSE: Importing cmdlet 'Get-AzADGroupMember_List'.
VERBOSE: Importing cmdlet 'Get-AzADGroup_Get'.
VERBOSE: Importing cmdlet 'Get-AzADGroup_List'.
VERBOSE: Importing cmdlet 'Get-AzADOrganization_List'.
VERBOSE: Importing cmdlet 'Get-AzADServicePrincipal_Get'.
VERBOSE: Importing cmdlet 'Get-AzADServicePrincipal_List'.
VERBOSE: Importing cmdlet 'Get-AzADUserOwnedApplication_List'.
VERBOSE: Importing cmdlet 'Get-AzADUserOwnedObject_List'.
VERBOSE: Importing cmdlet 'Get-AzADUserSigned_Get'.
VERBOSE: Importing cmdlet 'Get-AzADUser_Get'.
VERBOSE: Importing cmdlet 'Get-AzADUser_List'.
VERBOSE: Importing cmdlet 'New-AzADAppFederatedCredential_CreateExpanded'.
VERBOSE: Importing cmdlet 'New-AzADApplication_CreateExpanded'.
VERBOSE: Importing cmdlet 'New-AzADGroupGraphRefMember_Create'.
VERBOSE: Importing cmdlet 'New-AzADGroupGraphRefMember_CreateExpanded'.
VERBOSE: Importing cmdlet 'New-AzADGroup_CreateExpanded'.
VERBOSE: Importing cmdlet 'New-AzADOrganization_Create'.
VERBOSE: Importing cmdlet 'New-AzADOrganization_CreateExpanded'.
VERBOSE: Importing cmdlet 'New-AzADServicePrincipal_CreateExpanded'.
VERBOSE: Importing cmdlet 'New-AzADUser_CreateExpanded'.
VERBOSE: Importing cmdlet 'Remove-AzADAppFederatedCredential_Delete'.
VERBOSE: Importing cmdlet 'Remove-AzADApplicationKey_Remove'.
VERBOSE: Importing cmdlet 'Remove-AzADApplicationKey_RemoveExpanded'.
VERBOSE: Importing cmdlet 'Remove-AzADApplicationPassword_Remove'.
VERBOSE: Importing cmdlet 'Remove-AzADApplicationPassword_RemoveExpanded'.
VERBOSE: Importing cmdlet 'Remove-AzADApplication_Delete'.
VERBOSE: Importing cmdlet 'Remove-AzADGroupRefMember_Delete'.
VERBOSE: Importing cmdlet 'Remove-AzADGroup_Delete'.
VERBOSE: Importing cmdlet 'Remove-AzADServicePrincipalKey_Remove'.
VERBOSE: Importing cmdlet 'Remove-AzADServicePrincipalKey_RemoveExpanded'.
VERBOSE: Importing cmdlet 'Remove-AzADServicePrincipalPassword_Remove'.
VERBOSE: Importing cmdlet 'Remove-AzADServicePrincipalPassword_RemoveExpanded'.
VERBOSE: Importing cmdlet 'Remove-AzADServicePrincipal_Delete'.
VERBOSE: Importing cmdlet 'Remove-AzADUser_Delete'.
VERBOSE: Importing cmdlet 'Update-AzADAppFederatedCredential_UpdateExpanded'.
VERBOSE: Importing cmdlet 'Update-AzADApplication_UpdateExpanded'.
VERBOSE: Importing cmdlet 'Update-AzADGroup_UpdateExpanded'.
VERBOSE: Importing cmdlet 'Update-AzADServicePrincipal_UpdateExpanded'.
VERBOSE: Importing cmdlet 'Update-AzADUser_UpdateExpanded'.
Register-AzModule : The type initializer for 'Microsoft.Azure.Commands.Common.AzModule' threw an exception.
At C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\MSGraph.Autorest\Az.MSGraph.psm1:49 char:13
+   $VTable = Register-AzModule
+             ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [Register-AzModule], TypeInitializationException
    + FullyQualifiedErrorId : Microsoft.Azure.Commands.Common.RegisterAzModule

PS C:\Users\ORB\<redacted>>PS

Output of Resolve-AzError

Click to view
   HistoryId: 8


Message        : The type initializer for 'Microsoft.Azure.Commands.Common.AzModule' threw an exception.
StackTrace     :    at Microsoft.Azure.Commands.Common.RegisterAzModule.ProcessRecord()
Exception      : System.TypeInitializationException
InvocationInfo : {Register-AzModule}
Line           :   $VTable = Register-AzModule
                 
Position       : At C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\MSGraph.Autorest\Az.MSGraph.psm1:49 char:13
                 +   $VTable = Register-AzModule
                 +             ~~~~~~~~~~~~~~~~~
HistoryId      : 8

Message        : Attempted to access an element as a type incompatible with the array.
StackTrace     :    at System.Collections.Generic.List`1.Add(T item)
                    at Microsoft.Azure.Commands.Common.AzModule..cctor()
Exception      : System.ArrayTypeMismatchException
InvocationInfo : {Register-AzModule}
Line           :   $VTable = Register-AzModule
                 
Position       : At C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\MSGraph.Autorest\Az.MSGraph.psm1:49 char:13
                 +   $VTable = Register-AzModule
                 +             ~~~~~~~~~~~~~~~~~
HistoryId      : 8



   HistoryId: 5


Message        : The type initializer for 'Microsoft.Azure.Commands.Common.AzModule' threw an exception.
StackTrace     :    at Microsoft.Azure.Commands.Common.RegisterAzModule.ProcessRecord()
Exception      : System.TypeInitializationException
InvocationInfo : {Register-AzModule}
Line           :   $VTable = Register-AzModule
                 
Position       : At C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\MSGraph.Autorest\Az.MSGraph.psm1:49 char:13
                 +   $VTable = Register-AzModule
                 +             ~~~~~~~~~~~~~~~~~
HistoryId      : 5

Message        : Attempted to access an element as a type incompatible with the array.
StackTrace     :    at System.Collections.Generic.List`1.Add(T item)
                    at Microsoft.Azure.Commands.Common.AzModule..cctor()
Exception      : System.ArrayTypeMismatchException
InvocationInfo : {Register-AzModule}
Line           :   $VTable = Register-AzModule
                 
Position       : At C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\MSGraph.Autorest\Az.MSGraph.psm1:49 char:13
                 +   $VTable = Register-AzModule
                 +             ~~~~~~~~~~~~~~~~~
HistoryId      : 5



   HistoryId: 2


Message        : The type initializer for 'Microsoft.Azure.Commands.Common.AzModule' threw an exception.
StackTrace     :    at Microsoft.Azure.Commands.Common.RegisterAzModule.ProcessRecord()
Exception      : System.TypeInitializationException
InvocationInfo : {Register-AzModule}
Line           :   $VTable = Register-AzModule
                 
Position       : At C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\MSGraph.Autorest\Az.MSGraph.psm1:49 char:13
                 +   $VTable = Register-AzModule
                 +             ~~~~~~~~~~~~~~~~~
HistoryId      : 2

Message        : Attempted to access an element as a type incompatible with the array.
StackTrace     :    at System.Collections.Generic.List`1.Add(T item)
                    at Microsoft.Azure.Commands.Common.AzModule..cctor()
Exception      : System.ArrayTypeMismatchException
InvocationInfo : {Register-AzModule}
Line           :   $VTable = Register-AzModule
                 
Position       : At C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\MSGraph.Autorest\Az.MSGraph.psm1:49 char:13
                 +   $VTable = Register-AzModule
                 +             ~~~~~~~~~~~~~~~~~
HistoryId      : 2



   HistoryId: 1


Message        : The type initializer for 'Microsoft.Azure.Commands.Common.AzModule' threw an exception.
StackTrace     :    at Microsoft.Azure.Commands.Common.RegisterAzModule.ProcessRecord()
Exception      : System.TypeInitializationException
InvocationInfo : {Register-AzModule}
Line           :   $VTable = Register-AzModule
                 
Position       : At C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\MSGraph.Autorest\Az.MSGraph.psm1:49 char:13
                 +   $VTable = Register-AzModule
                 +             ~~~~~~~~~~~~~~~~~
HistoryId      : 1

Message        : Attempted to access an element as a type incompatible with the array.
StackTrace     :    at System.Collections.Generic.List`1.Add(T item)
                    at Microsoft.Azure.Commands.Common.AzModule..cctor()
Exception      : System.ArrayTypeMismatchException
InvocationInfo : {Register-AzModule}
Line           :   $VTable = Register-AzModule
                 
Position       : At C:\Users\ORB\AppData\Local\Microsoft\PowerShell\Modules\Az.Resources\6.6.1\MSGraph.Autorest\Az.MSGraph.psm1:49 char:13
                 +   $VTable = Register-AzModule
                 +             ~~~~~~~~~~~~~~~~~
HistoryId      : 1

@o-l-a-v
Copy link
Author

o-l-a-v commented Apr 25, 2023

Workaround for running locally

230915: vscode-powershell won't fix with 5.1, blaims shortcomings with Windows PowerShell 5.1 (or rather .NET Framework). Ref 1, Ref 2.

  • Don't use VSCode + vscode-powershell + Windows PowerShell 5.1 (use PowerShell 7.3.x instead), or
  • Install previous version of mentioned modules

Workaround for running in Azure Automation Account

230915: Az.Accounts 2.13.0 works with Az.Resources 6.10.0 and PowerShell 5.1, so seems fixed.

  • Download previous version of mentioned modules manually from PowerShellGallery.
  • Repackage them into a zip where:
    • Zip file name: <modulename>.zip, example: Az.Accounts.zip
    • Root folder name: <modulename>, example: Az.Accounts
    • Child directory name: <version>, example: 2.12.1.
Az.Accounts.zip
|- Az.Accounts
  |- 2.12.1
    |- <put content of nupkg file from PowerShellGallery here>

Please vote for the ability to import specific module versions to Automation Accounts, so we don't have to do this manually next time it happens:

@bnichms
Copy link
Contributor

bnichms commented Apr 25, 2023

More info:

Running locally, Az.Resources v6.6.1 fails to import on Windows PowerShell 5.1, but only when using VSCode and the VSCode PowerShell Extension.

  • PowerShell.exe terminal works fine.
  • PowerShell ISE works fine
  • VSCode with PS extension had no problems with Az.Accounts v2.12.1 and Az.Resources v6.6.0.

Some assembly conflict?

Output with verbose and debug set to 'Continue'.

Click to view
Output of Resolve-AzError

Click to view

Update: Issue is present in Powershell.exe (v5.1) on Windows Server. Previous versions do not have issue. @wyunchi-ms / @isra-fel can you help to triage?

@bnichms bnichms added ADO Issue is documented on MSFT ADO for internal tracking Tracking We will track status and follow internally labels Apr 25, 2023
@isra-fel
Copy link
Member

Thanks for the thorough investigation @o-l-a-v . We are looking into this problem.

@isra-fel
Copy link
Member

isra-fel commented Apr 26, 2023

I was able to reproduce with (a) vscode and (b) azure automation, looks like related to our recent update of Newtonsoft.Json, still investigating.

@bnichms I can't reproduce on Windows Server 2022. What version did you use? Can you run the following script and share the result after reproducing?

[System.AppDomain]::CurrentDomain.GetAssemblies() | select -Property FullName,Location | sort -Property FullName | fl

@jrudley
Copy link

jrudley commented Apr 27, 2023

I am seeing this in GCC High (Azure Gov) as well.

@AlyaKoni
Copy link

AlyaKoni commented May 1, 2023

Same here in several automation accounts. And not only Az.Resources. Also:
Az.Advisor
Az.Aks
Az.Compute
Az.DesktopVirtualization
Az.EventHub
Az.Kusto

Error message:
Error importing the module Az.Advisor. Import failed with the following error: Orchestrator.Shared.AsyncModuleImport.ModuleImportException: An error occurred when trying to import the module to an internal PowerShell session. Either the module dependencies are not imported correctly or the module is unsupported. Internal Error Message: The type initializer for 'Microsoft.Azure.Commands.Common.AzModule' threw an exception. . at Orchestrator.Activities.SetModuleVersion.GetPsModuleVersion(String moduleName, String moduleFullPath, Guid accountId, Guid moduleVersionId, InitialSessionState defaultSessionState) at Orchestrator.Activities.SetModuleVersion.InsertModuleVersion(String moduleName, ModuleLanguage moduleLanguage, String pythonModuleVersion, String moduleFullyQualifiedName, ActivitiesMetadataWorkflowExtension activitiesMetadataWorkflowExtension, Guid accountId, Guid moduleVersionId, Int64 moduleContentByteSize, ContentUriInfo contentUri, String storageUri, Int32 moduleVersion) at Orchestrator.Activities.SetModuleVersion.ExecuteInternal(CodeActivityContext context, String moduleName, ModuleLanguage moduleLanguage, String pythonModuleVersion, String modulePath, Guid accountId, Guid moduleVersionId, Int64 moduleContentByteSize, String storageUri, Int32 moduleVersion) at Orchestrator.Activities.SetModuleVersion.Execute(CodeActivityContext context) at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

@AlyaKoni
Copy link

AlyaKoni commented May 1, 2023

In Runtime 7.1 already Az.Accounts failes:
Error message:
Error importing the module Az.Accounts. Import failed with the following error: Orchestrator.Shared.AsyncModuleImport.ModuleImportException: An error occurred when trying to import the module to an internal PowerShell session. Either the module dependencies are not imported correctly or the module is unsupported. Internal Error Message: Import-Module: C:\Users\Client\Temp\JGQKZQJGNR\Az.Accounts\Az.Accounts.psm1:87 Line | 87 | Import-Module (Join-Path -Path $PSScriptRoot -ChildPath Microsoft.Azu … | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Could not load file or assembly 'Newtonsoft.Json, Version=13.0.0.0, | Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'. The system cannot | find the file specified. . at Orchestrator.Activities.SetModuleVersion.GetPs7ModuleVersion(String moduleName, String moduleFullPath, Guid accountId, Guid moduleVersionId, InitialSessionState defaultSessionState) at Orchestrator.Activities.SetModuleVersion.InsertModuleVersion(String moduleName, ModuleLanguage moduleLanguage, String pythonModuleVersion, String moduleFullyQualifiedName, ActivitiesMetadataWorkflowExtension activitiesMetadataWorkflowExtension, Guid accountId, Guid moduleVersionId, Int64 moduleContentByteSize, ContentUriInfo contentUri, String storageUri, Int32 moduleVersion) at Orchestrator.Activities.SetModuleVersion.ExecuteInternal(CodeActivityContext context, String moduleName, ModuleLanguage moduleLanguage, String pythonModuleVersion, String modulePath, Guid accountId, Guid moduleVersionId, Int64 moduleContentByteSize, String storageUri, Int32 moduleVersion) at Orchestrator.Activities.SetModuleVersion.Execute(CodeActivityContext context) at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

@MainDBA
Copy link

MainDBA commented May 1, 2023

I have seen this issue too - same error as above and runbooks that rely on these modules are failing/suspended...
The following updates in two of my Azure subscriptions (automated using an update runbook downloaded from MS's gallery) have failed on 30/05
AZ.Compute from version 5.7.0 to 5.7.1
AZ.Resources from version 6.6.0 to 6.6.1

Az.Accounts (which is a dependency of both) gets successfully updated to v 2.12.2.
Attempts to revert back to an earlier version of both modules also fail - when I delete the modules I am able to revert back to Az.Accounts v2.12.1 but then when I try and revert back to Az.Compute 5.7.0 or Az.Resources 6.6.0 they both first update Az.Accounts to v2.12.2 (despite documentation saying their dependency is v2.12.1) before installation and both attempts subsequently fail

@MainDBA
Copy link

MainDBA commented May 1, 2023

Update: The only way to rollback to the older versions of these modules (that worked for me) is to delete them from your automation accounts and install them from a local file, manually downloaded from the PowerShell Gallery and rename the *.nupg file as a *.zip file as per the workaround posted above.

Neither using PowerShell nor deploying to Azure either from within the Portal or from the PowerShell Gallery webpage worked. Modules that have been affected for me were:

  1. Az.Accounts had to rollback to v2.12.1
  2. Az.Compute had to rollback to v5.7.0
  3. Az.Network had to rollback to v5.6.0
  4. Az.Resources had to rollback to v6.6.0
  5. Az.SQL had to rollback to v4.5.0
  6. Az.Storage had to rollback to v5.5.0

@mortenlerudjordet
Copy link

Seeing the same problem after my AA account was auto updated to new Az version.
Multiple Az submodules are in a import failed state, and Runbooks trying to use them will just outright fail

@o-l-a-v
Copy link
Author

o-l-a-v commented May 2, 2023

Anyone tried Automation Account + not Windows PowerShell 5.1? I haven't because newer PowerShell versions still are in preview (for Azure Automation Account).

Lets hope Microsoft can implement two new test cases that must succeed before launching a stable version of any Az.* module in the future:

  • Azure Automation Account + Windows PowerShell 5.1
    • Import/install on the Automation Account itself
    • Import and use from a PowerShell runbook (easy to test auth with Managed Identity)
  • VSCode + vscode-powershell + Windows PowerShell 5.1
    • Import

@jrudley
Copy link

jrudley commented May 2, 2023

FYI, I spoke with MS support on this and product is aware. They are working on a hotfix.

here is our guidance to mitigate the issue:

• Download previous version of mentioned modules manually from PowerShellGallery.
o Az.Accounts v2.12.1
o Az.Resources v6.6.0
• Repackage them into a zip where:
o Zip file name: .zip, example: Az.Accounts.zip
o Root folder name: , example: Az.Accounts
o Child directory name: , example: 2.12.1.
Az.Accounts.zip
|- Az.Accounts
|- 2.12.1
|-

Here is a list of know versions that are impacted by this issue, an older version would also mitigate the issue:
6.6.0
6.5.3
6.2.0
6.0.1

@bnichms
Copy link
Contributor

bnichms commented May 2, 2023

I was able to reproduce with (a) vscode and (b) azure automation, looks like related to our recent update of Newtonsoft.Json, still investigating.

@bnichms I can't reproduce on Windows Server 2022. What version did you use? Can you run the following script and share the result after reproducing?

[System.AppDomain]::CurrentDomain.GetAssemblies() | select -Property FullName,Location | sort -Property FullName | fl

Agreed. We have found it is not widespread across Windows Server/Azure Stack HCI. We found it is affecting systems which are running our E2E testing. The problem in triaging thus far is that the error only occurs during our test runs. What we are seeing is that logging in and trying to manually repro does not result in the error.

We are still triaging.

@tpascal
Copy link

tpascal commented May 3, 2023

Received the same exception while attempting to upgrade RunAs automation account from using AzureRM to Az

Manually installing Az.Accounts (2.12.1) and Az.Resources (6.6.0) via workaround gets the conversion completed and scripts running again with managed identity

@utkarshmsf
Copy link

utkarshmsf commented May 3, 2023

The Azure Automation team is investigating and working on the identified issue, the workaround is to download the Az.Accounts v2.12.1 from the PowerShell gallery and upload it with the following file structure:

Az.Accounts.zip
|- Az.Accounts
  |- 2.12.1
    |- <put content of nupkg file from PowerShellGallery here>

All the modules having a dependency on the Az.Accounts module should work with the hot-fix.

@ritviknagpal48
Copy link

I hit a similar issue on one my environments: #21690

@bnichms
Copy link
Contributor

bnichms commented May 3, 2023

I hit a similar issue on one my environments: #21690

@isra-fel please see this issue posted by one of our team members (which has relevant repro steps and other information)

@srjennings
Copy link

srjennings commented May 4, 2023

I hit a similar issue on one my environments: #21690

@isra-fel please see this issue posted by one of our team members (which has relevant repro steps and other information)

FYI, I spoke with MS support on this and product is aware. They are working on a hotfix.

Hit this issue today with Az.Compute. Do we have ETA on hotfix?

@jrudley
Copy link

jrudley commented May 4, 2023

https://learn.microsoft.com/en-us/azure/automation/automation-update-azure-modules

image

No eta yet per my Microsoft case I have opened.

@srjennings
Copy link

https://learn.microsoft.com/en-us/azure/automation/automation-update-azure-modules

image

No eta yet per my Microsoft case I have opened.

Yeah. I had the same with Microsoft. Thanks for that doc link.

@shootex20
Copy link

Hi all, I've been encountering the same issue and have been trying to update the package manually due to the latest version of Az.Accounts causing me issues. My upload keeps failing even with the provided folder structure for reference. Currently, this is mine:
image

Anyone have any ideas or able to help me out? Or will I have to wait for the update?

This is the error I've got on my automation account
image

Any information is appreciated. Thanks

@dpravo
Copy link

dpravo commented Aug 17, 2023

2 days down the drain troubleshooting why I can't log into Azure from a Powershell 5.1 runbook running on a hybrid runbook worker - not even sure how I stumbled across this page but thanks to the comments from @mbrat2005 above I am moving forward again.

@KezHalls
Copy link

Hi. there is a lot of information to read here. I have experienced the exact same issues with azure automation hybrid worker.
Even though still in preview we opted to try the 7.2 version so I updated they hybrid worker server.
After running we get the below error. Can I please get some guidance on peoples experience to next steps.

job...................................RunbookFlow : Method 'get_SerializationSettings' in type 'Microsoft.Azure.Management.Internal.Resources.ResourceManagementClient' from assembly 'Microsoft.Azure.PowerShell.Clients.ResourceManager, Version=1.0.0.0, Culture=neutral, PublicKeyToken=xxxx5' does not have an implementation. At line:1 char:57 + <#-- Enable activity tracing to see error location --#> RunbookFlow ` + ~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Invoke-RunbookFlow], TypeLoadException + FullyQualifiedErrorId : System.TypeLoadException,Orchestrator.GraphRunbook.Cmdlets.InvokeRunbookFlowCommand

@MasterKuat
Copy link
Contributor

MasterKuat commented Aug 22, 2023

Hi @KezHalls , just to be sure, have you also recreate runbook to use runtime 7.2 ? Runtime version is fixed at runbook's creation time.

@mundayn
Copy link

mundayn commented Oct 6, 2023

Is there any update to this issue?

I am using a new Automation Account with Hybrid Worker Windows Server 2022 with Az modules freshly installed today using PowerShell 5.1 and experiencing the same issues.

Same in Visual Studio Code.

Receiving the "get_SerializationSettings" error, downgrading Az.Accounts and Az.Resources seemed to resolve it, until I needed to call another module using Az.Network which then needed a later version of Az.Accounts.

@brolifen
Copy link

brolifen commented Oct 7, 2023

Is there any update to this issue?

I am using a new Automation Account with Hybrid Worker Windows Server 2022 with Az modules freshly installed today using PowerShell 5.1 and experiencing the same issues.

Same in Visual Studio Code.

Receiving the "get_SerializationSettings" error, downgrading Az.Accounts and Az.Resources seemed to resolve it, until I needed to call another module using Az.Network which then needed a later version of Az.Accounts.

Exactly the same. Just running Connect-AZAccount spits this error out on version 2.13.1. This is extremely annoying.

@brolifen
Copy link

brolifen commented Oct 7, 2023

Had to go down to 2.12.1 but first needed to manually remove the module from under C:\Program Files\WindowsPowerShell\Modules because it kept complaining it was still in use
Then ran:
Install-Module Az.Accounts -RequiredVersion 2.12.1 -Force

However as others mentioned this gives issues with other modules as some rely on the most recent one. Please fix this!

@o-l-a-v
Copy link
Author

o-l-a-v commented Oct 8, 2023

I've never worked with hybrid workers, but maybe manually installing and importing modules with a given version to a temp path on the workers could work?

Proof of concept script that worked from PowerShell ISE on Windows 10, and VSCode with PowerShell 5.1:

Click to expand
#Requires -Version 5.1
#Requires -PSEdition Desktop
<#
    .SYNOPSIS
        Installs and imports Az modules to a given path. Adjust Assets to your requirements.

    .NOTES
        Author:   Olav Rønnestad Birkeland | github.com/o-l-a-v
        Created:  231008
        Modified: 231008

        # Why
        * 230425 - "Az.Resources v6.6.1 fails to import to Azure Automation Account #21647"
        https://github.com/Azure/azure-powershell/issues/21647

        # Learnings
        * Installing Az v9.6.0 with PowerShellGet or PackageManagement installs much newer Az.Accounts.
          * Which means most modules won't load, because they rely on older versions of Az.Accounts.
        * Installing Az v9.6.0 with PowerShellGet or PackageManagement installs some other older Az submodules which rely on much older versions of Az.Accounts.
          * Az.PrivateDNS 1.0.3 for instance, requires <= Az.Accounts 1.8.1.
        * Must rename downloaded NuGet packages from PowerShell Gallery from "*.nupkg" to "*.zip", else `Expand-Archive` refuses to work.

    .EXAMPLE
        # Run with F8 (Run Selection) from PowerShell ISE or Visual Studio Code
        & $(Try{$psEditor.GetEditorContext().CurrentFile.Path}Catch{$psISE.CurrentFile.FullPath})
#>


# Input parameters
[OutputType([System.Void])]
Param()


# Assets
$TempPath = [string] '{0}\Modules' -f $env:TEMP
$ModulesToInstall = [ordered]@{
    'Az.Accounts'  = [System.Version] '2.12.1'
    'Az.Compute'   = [System.Version] '5.7.0'
    'Az.Resources' = [System.Version] '6.6.0'
}


# Settings
$ErrorActionPreference = 'Stop'
$Global:ProgressPreference = 'SilentlyContinue'
if ([System.Net.ServicePointManager]::SecurityProtocol.ToString() -ne 'Tls12') {
    [System.Net.ServicePointManager]::SecurityProtocol = 'Tls12'
}


# Create path if it does not already exist
Write-Output -InputObject 'Create $TempPath if it does not already exist'
if (-not [System.IO.Directory]::Exists($TempPath)) {
    $null = [System.IO.Directory]::CreateDirectory($TempPath)
}


# Add info to $ModulesToInstall which will also be used for importing them later
$ModulesToInstall = [PSCustomObject[]](
    $ModulesToInstall.GetEnumerator().ForEach{
        [PSCustomObject]@{
            'Name'              = [string] $_.'Name'
            'Version'           = [System.Version] $_.'Value'
            'Uri'               = [string] 'https://www.powershellgallery.com/api/v2/package/{0}/{1}' -f $_.'Name', $_.'Value'
            'DownloadFilePath'  = [string] '{0}\{1}.{2}.zip' -f $TempPath, $_.'Name', $_.'Value'.ToString()
            'InstallDirectory'  = [string] '{0}\{1}\{2}' -f $TempPath, $_.'Name', $_.'Value'.ToString()
        }
    }.ForEach{
        $null = Add-Member -InputObject $_ -MemberType 'NoteProperty' -Name 'DetectionFilePath' -Value (
            [string] '{0}\{1}.psd1' -f $_.'InstallDirectory', $_.'Name'
        )
        $_
    }
)


# Install $ModulesToInstall to $TempPath
Write-Output -InputObject ('{0}# Install $ModulesToInstall to $TempPath' -f [System.Environment]::NewLine)
foreach ($Module in $ModulesToInstall) {
    Write-Output -InputObject ('{0} v{1}' -f $Module.'Name', $Module.'Version'.ToString())

    # Check if already installed
    if ([System.IO.File]::Exists($Module.'DetectionFilePath')) {
        Write-Output -InputObject 'Already installed.'
        Continue
    }

    # Download
    $null = [System.Net.WebClient]::new().DownloadFile($Module.'Uri',$Module.'DownloadFilePath')

    # Install
    ## Create directory
    $null = [System.IO.Directory]::CreateDirectory($Module.'InstallDirectory')
    ## Extract
    $null = Expand-Archive -Path $Module.'DownloadFilePath' -DestinationPath $Module.'InstallDirectory'
    ## Delete downloaded file
    $null = [System.IO.File]::Delete($Module.'DownloadFilePath')

    # Detect and output success
    if ([System.IO.File]::Exists($Module.'DetectionFilePath')) {
        Write-Output -InputObject 'Success.'
    }
    else {
        Write-Error -ErrorAction 'Stop' -Message 'Failed.' -Exception 'Failed.'
    }
}


# Import Az modules from $TempPath
## Introduce step
Write-Output -InputObject ('{0}# Import all modules from $TempPath' -f [System.Environment]::NewLine)

## Remove any conflicting Az modules if already loaded
Write-Output -InputObject 'Remove any conflicting Az modules if already loaded.'
$null = Microsoft.PowerShell.Core\Get-Module -Name 'Az.*' | Remove-Module

## First Az.Accounts
Write-Output -InputObject 'Importing Az.Accounts'
Import-Module -Name $ModulesToInstall.Where{$_.'Name' -eq 'Az.Accounts'}.'DetectionFilePath' -WarningAction 'SilentlyContinue'

## Then other Az modules
Write-Output -InputObject ('Importing {0}' -f ($ModulesToInstall.Where{$_.'Name' -ne 'Az.Accounts'}.'Name' -join ', ' -as [string]))
Import-Module -Name $ModulesToInstall.Where{$_.'Name' -ne 'Az.Accounts'}.'DetectionFilePath'


# List imported modules
Write-Output -InputObject ('{0}# List imported modules' -f [System.Environment]::NewLine)
Get-Module | Select-Object -Property 'Name', 'Path' | ConvertTo-Json -Depth 1

@MasterKuat
Copy link
Contributor

On a fresh HW (without any Az module) this should do the thing (not tested) :

  1. Install-Module Az.Accounts -RequiredVersion 2.12.1
  2. Install-Module -Name Az -RequiredVersion 9.6.0

Az 9.6.0 require minimum version of Az.Accounts 2.12.1 (https://www.powershellgallery.com/packages/Az/9.6.0/Content/Az.psm1)

Install-Module -Name Az always install lastest version of Az.Accounts even with a RequiredVersion (See #22335 )

@MrFly72
Copy link

MrFly72 commented Oct 9, 2023

But let's face it. That does not help you any if you need a newer version of another module which needs a higher version of AZ.Accounts. You are stuck in that moment. Don't know why there is so much talk about getting the old one. This problem needs a fix and it takes way too long.
And as all modules have different requirements, it's a hazel to install them, as it is a huge work to walk through all other dependencies.

@brolifen
Copy link

brolifen commented Oct 9, 2023

But let's face it. That does not help you any if you need a newer version of another module which needs a higher version of AZ.Accounts. You are stuck in that moment. Don't know why there is so much talk about getting the old one. This problem needs a fix and it takes way too long. And as all modules have different requirements, it's a hazel to install them, as it is a huge work to walk through all other dependencies.

Agreed installing older modules is just a workaround but I'm surprised this issue has been going on for so long for something so critical without a fix.

@MasterKuat
Copy link
Contributor

MS ways past finding out but I guess they bet on PS 7.2

@brolifen
Copy link

brolifen commented Oct 9, 2023

MS ways past finding out but I guess they bet on PS 7.2

Well at least on the Azure Automation side that is still labeled as "preview" aka not production ready but most importantly preview features are not under SLA or formal support. Not that the latter matters much with MS's support reputation as is evident by this open issue.

@mark3grahams
Copy link

#21960

@isra-fel can you comment?

@o-l-a-v
Copy link
Author

o-l-a-v commented Jan 3, 2024

Just thought it was worth mentioning that PowerShell 7.2 is GA in Automation Account and works great with the latest Az modules.

Seems 7.2 is GA for hybrid workers too?

@MrFly72
Copy link

MrFly72 commented Jan 4, 2024

Any news on this?
It just stroke me again in VSCode:
image
VSCode most recent, PS5.1, Powershell Extension most recent.
It is really a pain!

@Alex-wdy
Copy link
Contributor

Alex-wdy commented Jan 5, 2024

Any news on this? It just stroke me again in VSCode: image VSCode most recent, PS5.1, Powershell Extension most recent. It is really a pain!

For VSCode Extension issue, we are tracking internally, and we expect to solve this issue in January. I think all other issues have been resolved. Once I have a VsCode extension issue progress, I will update it in github.

@MasterKuat
Copy link
Contributor

Just thought it was worth mentioning that PowerShell 7.2 is GA in Automation Account and works great with the latest Az modules.

Yep but from my point of view 7.2 is NOT productionProof as : "Executing child scripts using .\child-runbook.ps1 is not supported in PowerShell 7.1 and PowerShell 7.2" (https://learn.microsoft.com/en-us/azure/automation/automation-child-runbooks#runbook-types)
This is against the very first sentence on same page : "It's a good practice in Azure Automation to write reusable, modular runbooks with a discrete function that other runbooks call." 🤣

@MrFly72
Copy link

MrFly72 commented Jan 5, 2024

For VSCode Extension issue, we are tracking internally, and we expect to solve this issue in January. I think all other issues have been resolved. Once I have a VsCode extension issue progress, I will update it in github.

I just tested the current preview (VSCode Extension [email protected]) and it still has this problem.
So is this fix you are talking about already in that?

@MrFly72
Copy link

MrFly72 commented Jan 15, 2024

For VSCode Extension issue, we are tracking internally, and we expect to solve this issue in January. I think all other issues have been resolved. Once I have a VsCode extension issue progress, I will update it in github.

Can you give us an info here, when it is fixed in the preview of the powershell extension ?
As it is not easy to reproduce, i dont want to do it here and then.

@Alex-wdy
Copy link
Contributor

For VSCode Extension issue, we are tracking internally, and we expect to solve this issue in January. I think all other issues have been resolved. Once I have a VsCode extension issue progress, I will update it in github.

Can you give us an info here, when it is fixed in the preview of the powershell extension ? As it is not easy to reproduce, i dont want to do it here and then.

Yes, I will continue to reply to this issue. A blog-issue postmortem should be posted at the same time.

@MrFly72
Copy link

MrFly72 commented Jan 29, 2024

@Alex-wdy I got a new prerelease (2024.3.0) of the extension and this is still not fixed in that.
This is really annoying. Please raise the priority of this, as we are all full stuck at a specific AZ release and if new features come in, we cannot use them.

@Alex-wdy
Copy link
Contributor

@Alex-wdy I got a new prerelease (2024.3.0) of the extension and this is still not fixed in that. This is really annoying. Please raise the priority of this, as we are all full stuck at a specific AZ release and if new features come in, we cannot use them.

This is on our high priority list, but will still take some time. I will update here as soon as there is any progress.

@ITJoeSchmo
Copy link

ITJoeSchmo commented Feb 13, 2024

See my comment here for a potential workaround on PS 5.1 that allows using the new versions by redirecting the assembly conflict to the new version only: #21960 (comment)

This is probably a viable work around for Visual Studio as well, but I have not tested it myself on that 1 yet.

@MrFly72
Copy link

MrFly72 commented Mar 22, 2024

@Alex-wdy I got a new prerelease (2024.3.0) of the extension and this is still not fixed in that. This is really annoying. Please raise the priority of this, as we are all full stuck at a specific AZ release and if new features come in, we cannot use them.

This is on our high priority list, but will still take some time. I will update here as soon as there is any progress.

@Alex-wdy Still no news on this?
Tried everything with the newest extension + module, but still the same problem with 5.1?
I cannot believe that this blocking bug is open this long.
We are talking of one year now....
We just recently found out, that staying on the older modules had a function break in update-azvm, which resulted in making the azure Update Management break.
So there is a definite need for updated modules, which does not work if you have to develop in 5.1, as you have dependencies to modules that only run in 5.1 (in my case Citrix)

@ITJoeSchmo
Copy link

Same issue as here: #21960 -- a conflict on the assembly NewtonSoft.Json due to modules loading 2 different versions and Windows PowerShell (aka 5.1 and older) do not know what to do when there are multiple versions of the same assembly loaded, causing this error.

I posted a work-around and script to implement it in that same thread here: #21960 (comment)

I have been leveraging this solution in 2 production automation platforms that use PowerShell in sandboxed processes (1 being AzureAutomation w/ HybridWorkers) without issue for nearly 6 months now.

The only quirk is some modules have to be imported in a specific order to be happy if more than 1 is used in your script: 1) Az.* 2) Graph.* 3) ExchangeOnline

I have only had to re-apply the bindingRedirect once when the app was updated and it was overwritten

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ADO Issue is documented on MSFT ADO for internal tracking bug This issue requires a change to an existing behavior in the product in order to be resolved. customer-reported Tracking We will track status and follow internally
Projects
None yet
Development

No branches or pull requests