-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
Comments
More info: Running locally,
Some assembly conflict? Output with verbose and debug set to 'Continue'. Click to viewPS 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 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 |
Workaround for running locally230915:
Workaround for running in Azure Automation Account230915: Az.Accounts 2.13.0 works with Az.Resources 6.10.0 and PowerShell 5.1, so seems fixed.
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: |
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? |
Thanks for the thorough investigation @o-l-a-v . We are looking into this problem. |
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?
|
I am seeing this in GCC High (Azure Gov) as well. |
Same here in several automation accounts. And not only Az.Resources. Also: Error message: |
In Runtime 7.1 already Az.Accounts failes: |
I have seen this issue too - same error as above and runbooks that rely on these modules are failing/suspended... Az.Accounts (which is a dependency of both) gets successfully updated to v 2.12.2. |
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:
|
Seeing the same problem after my AA account was auto updated to new Az version. |
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
|
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. Here is a list of know versions that are impacted by this issue, an older version would also mitigate the issue: |
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. |
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 |
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:
All the modules having a dependency on the Az.Accounts module should work with the hot-fix. |
I hit a similar issue on one my environments: #21690 |
Hit this issue today with Az.Compute. Do we have ETA on hotfix? |
https://learn.microsoft.com/en-us/azure/automation/automation-update-azure-modules No eta yet per my Microsoft case I have opened. |
Yeah. I had the same with Microsoft. Thanks for that doc link. |
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. |
Hi. there is a lot of information to read here. I have experienced the exact same issues with azure automation hybrid worker. 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 |
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. |
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. |
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 However as others mentioned this gives issues with other modules as some rely on the most recent one. Please fix this! |
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 |
On a fresh HW (without any Az module) this should do the thing (not tested) :
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 ) |
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. |
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. |
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. |
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? |
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) |
I just tested the current preview (VSCode Extension [email protected]) and it still has this problem. |
Can you give us an info here, when it is fixed in the preview of the powershell extension ? |
Yes, I will continue to reply to this issue. A blog-issue postmortem should be posted at the same time. |
@Alex-wdy I got a new prerelease (2024.3.0) of the extension and this is still not fixed in that. |
This is on our high priority list, but will still take some time. I will update here as soon as there is any progress. |
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. |
@Alex-wdy Still no news on this? |
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 |
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.
Issue script & Debug output
Environment data
Module versions
Error output
The text was updated successfully, but these errors were encountered: