Description
Initialize-AzDataProtectionBackupInstance -DatasourceType AzureDisk throws an internal cast exception when invoked against a TrustedLaunch OS disk (Premium SSD LRS). The exception originates inside the cmdlet during construction of the DataStoreParametersList property, before the cmdlet returns, so no client-side workaround is available.
Exception setting "DataStoreParametersList": "Cannot convert the
"System.Object[]" value of type "System.Object[]" to type
"Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.IDataStoreParameters"."
Both documented invocation patterns fail identically:
- Post-mutation pattern (per the MS Learn example): call
Initialize-* without -SnapshotResourceGroupId, then mutate $instance.Property.PolicyInfo.PolicyParameter.DataStoreParametersList[0].ResourceGroupId. The exception is thrown by Initialize-* itself, so the post-mutation line is never reached.
- Parameter pattern: pass
-SnapshotResourceGroupId directly to Initialize-*. The same exception is thrown at the same line — passing the parameter does not bypass the broken default-construction code path.
Standard managed disks (non-TrustedLaunch) in the same subscription and the same vault initialize successfully with both patterns. The error appears to be specific to disks belonging to a TrustedLaunch VM.
Expected behavior
Initialize-AzDataProtectionBackupInstance -DatasourceType AzureDisk should return an initialized IBackupInstanceResource for a TrustedLaunch OS disk, the same way it does for Standard SSD / Premium SSD disks attached to non-TrustedLaunch VMs. Azure Disk Backup explicitly supports Azure managed disks (Standard HDD, Standard SSD, Premium SSD, Premium SSD v2, Ultra) per https://learn.microsoft.com/azure/backup/disk-backup-support-matrix without any TrustedLaunch carve-out.
Actual behavior
The same call against a non-TrustedLaunch Premium SSD disk in the same vault and subscription succeeds and returns a valid IBackupInstanceResource. The TrustedLaunch disk consistently and deterministically throws the cast exception above.
Disk details (target of the failing call)
| Property |
Value |
| Storage type |
Premium SSD LRS |
| Disk state |
Attached |
| OS type |
Windows |
| VM generation |
V2 |
| Security type |
Trusted Launch |
| Disk size |
127 GiB |
| Max shares |
0 |
Hypothesis / observation
The exception text indicates the cmdlet is constructing DataStoreParametersList as System.Object[] and failing to assign it to a strongly-typed IDataStoreParameters property on the model object. This looks like a manifest / default-construction path that handles the TrustedLaunch case differently from the standard disk case and produces an untyped array where a typed one is expected.
The MS Learn doc page for Initialize-AzDataProtectionBackupInstance instructs users to mutate DataStoreParametersList[0].ResourceGroupId post-call — implying the cmdlet is meant to return a model with that property already constructed and typed. For the TrustedLaunch disk, the cmdlet never returns because the construction itself fails.
Workaround currently in use
We are detecting this specific error signature (DataStoreParametersList + IDataStoreParameters) in PowerShell and skipping the disk for the run with a single [WARN] log line. On non-TrustedLaunch disks the script proceeds normally. This workaround is fragile across module updates because it relies on exception string matching.
Impact
- All TrustedLaunch VMs in our environment cannot have their OS or data disks protected via Az.DataProtection until this is resolved.
- The same code path succeeds for thousands of non-TrustedLaunch managed disks in the same subscription across the same nightly automation run — failure is specific to TrustedLaunch.
- Workaround in PowerShell scripts requires special-casing TrustedLaunch disks via exception string matching, which is fragile across module updates.
Issue script & Debug output
$DebugPreference = 'Continue'
# Repro environment:
# PowerShell 5.1 (Windows ConsoleHost), Az.DataProtection 3.0.0
# Disk: TrustedLaunch OS disk, Premium SSD LRS
$sub = '<subscription-guid>'
$diskRG = '<vm-resource-group>'
$diskName = '<trustedlaunch-os-disk-name>'
$vaultRG = '<vault-resource-group>'
$vault = '<backup-vault-name>'
$policy = '<disk-backup-policy-name>'
$policyId = "/subscriptions/$sub/resourceGroups/$vaultRG/providers/Microsoft.DataProtection/backupVaults/$vault/backupPolicies/$policy"
$diskId = "/subscriptions/$sub/resourceGroups/$diskRG/providers/Microsoft.Compute/disks/$diskName"
# ---------------------------------------------------------------------------
# Attempt 1: post-mutation pattern (the documented MS Learn example).
# ---------------------------------------------------------------------------
$instance = Initialize-AzDataProtectionBackupInstance `
-DatasourceType AzureDisk `
-DatasourceLocation <region> `
-PolicyId $policyId `
-DatasourceId $diskId
# ^ Throws here for TrustedLaunch OS disks; post-mutation line below is never reached.
$instance.Property.PolicyInfo.PolicyParameter.DataStoreParametersList[0].ResourceGroupId = `
"/subscriptions/$sub/resourceGroups/$vaultRG"
# ---------------------------------------------------------------------------
# Attempt 2: parameter pattern (pass -SnapshotResourceGroupId directly).
# Hypothesis was that passing the parameter would bypass default construction;
# in practice it throws the IDENTICAL exception at the same line.
# ---------------------------------------------------------------------------
$instance = Initialize-AzDataProtectionBackupInstance `
-DatasourceType AzureDisk `
-DatasourceLocation <region> `
-PolicyId $policyId `
-DatasourceId $diskId `
-SnapshotResourceGroupId "/subscriptions/$sub/resourceGroups/$vaultRG"
# ^ Same exception. Both attempts fail before Initialize-* returns.
**Resulting exception (identical for both attempts):**
Exception setting "DataStoreParametersList": "Cannot convert the
"System.Object[]" value of type "System.Object[]" to type
"Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.IDataStoreParameters"."
At line:1 char:1
+ $instance = Initialize-AzDataProtectionBackupInstance @params
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], SetValueInvocationException
+ FullyQualifiedErrorId : ExceptionWhenSetting
**Params dict (Attempt 2, anonymized) from the wrapping automation log:**
{
"DatasourceType": "AzureDisk",
"DatasourceLocation": "<region>",
"PolicyId": "/subscriptions/<subscription-guid>/resourceGroups/<vault-resource-group>/providers/Microsoft.DataProtection/backupVaults/<backup-vault-name>/backupPolicies/<disk-backup-policy-name>",
"DatasourceId": "/subscriptions/<subscription-guid>/resourceGroups/<vm-resource-group>/providers/Microsoft.Compute/disks/<trustedlaunch-os-disk-name>",
"SnapshotResourceGroupId": "/subscriptions/<subscription-guid>/resourceGroups/<vault-resource-group>"
}
Environment data
Name Value
---- -----
PSVersion 5.1.20348.4294
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.20348.4294
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Host: Windows Server 2022 — Azure App Service WebJob (non-interactive `ConsoleHost`). Repro also observed on Windows Server 2019 in PowerShell ISE.
Authentication: Managed Identity (App Service) and interactive (ISE) — both reproduce identically.
Module versions
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Script 5.5.0 Az.Accounts {Add-AzEnvironment, Clear-AzConfig, Clear-AzContext...}
Script 11.6.0 Az.Compute {Add-AzImageDataDisk, Add-AzVhd, Add-AzVMAdditionalUnattendContent...}
Script 3.0.0 Az.DataProtection {Backup-AzDataProtectionBackupInstanceAdhoc, Edit-AzDataProtectionPolicyRetentionRuleClientObject, Edit-AzDataProtectionPolicyTagClientObject...}
Script 6.5.0 Az.KeyVault {Add-AzKeyVaultCertificate, Add-AzKeyVaultKey, Add-AzKeyVaultManagedHsmRegion...}
Script 7.12.0 Az.RecoveryServices {Backup-AzRecoveryServicesBackupItem, Copy-AzRecoveryServicesVault, Disable-AzRecoveryServicesBackupAutoProtection...}
Script 1.3.0 Az.ResourceGraph {Search-AzGraph}
Script 10.0.0 Az.Resources {Add-AzADGroupMember, Export-AzResourceGroup, Get-AzADAppCredential...}
`Az` rollup: **16.0.0** (June 2026).
Error output
HistoryId: <not captured -- non-interactive WebJob>
Exception : Exception setting "DataStoreParametersList": "Cannot convert
the "System.Object[]" value of type "System.Object[]" to type
"Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.IDataStoreParameters"."
InvocationInfo :
MyCommand : Initialize-AzDataProtectionBackupInstance
Line : $instance = Initialize-AzDataProtectionBackupInstance @params
PositionMessage : At line:1 char:1
+ $instance = Initialize-AzDataProtectionBackupInstance @params
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CategoryInfo : NotSpecified: (:) [], SetValueInvocationException
FullyQualifiedErrorId: ExceptionWhenSetting
ScriptStackTrace :
at Initialize-AzDataProtectionBackupInstance, <...>\Az.DataProtection\3.0.0\Az.DataProtection.psm1
(within the cmdlet's default-construction path for DataStoreParametersList)
PSMessageDetails :
**Reproduces deterministically** for the TrustedLaunch disk on every invocation. The same `Initialize-AzDataProtectionBackupInstance` call against any non-TrustedLaunch managed disk in the same subscription, vault, and policy returns a valid `IBackupInstanceResource` without error.
Description
Initialize-AzDataProtectionBackupInstance -DatasourceType AzureDiskthrows an internal cast exception when invoked against a TrustedLaunch OS disk (Premium SSD LRS). The exception originates inside the cmdlet during construction of theDataStoreParametersListproperty, before the cmdlet returns, so no client-side workaround is available.Both documented invocation patterns fail identically:
Initialize-*without-SnapshotResourceGroupId, then mutate$instance.Property.PolicyInfo.PolicyParameter.DataStoreParametersList[0].ResourceGroupId. The exception is thrown byInitialize-*itself, so the post-mutation line is never reached.-SnapshotResourceGroupIddirectly toInitialize-*. The same exception is thrown at the same line — passing the parameter does not bypass the broken default-construction code path.Standard managed disks (non-TrustedLaunch) in the same subscription and the same vault initialize successfully with both patterns. The error appears to be specific to disks belonging to a TrustedLaunch VM.
Expected behavior
Initialize-AzDataProtectionBackupInstance -DatasourceType AzureDiskshould return an initializedIBackupInstanceResourcefor a TrustedLaunch OS disk, the same way it does for Standard SSD / Premium SSD disks attached to non-TrustedLaunch VMs. Azure Disk Backup explicitly supports Azure managed disks (Standard HDD, Standard SSD, Premium SSD, Premium SSD v2, Ultra) per https://learn.microsoft.com/azure/backup/disk-backup-support-matrix without any TrustedLaunch carve-out.Actual behavior
The same call against a non-TrustedLaunch Premium SSD disk in the same vault and subscription succeeds and returns a valid
IBackupInstanceResource. The TrustedLaunch disk consistently and deterministically throws the cast exception above.Disk details (target of the failing call)
Hypothesis / observation
The exception text indicates the cmdlet is constructing
DataStoreParametersListasSystem.Object[]and failing to assign it to a strongly-typedIDataStoreParametersproperty on the model object. This looks like a manifest / default-construction path that handles the TrustedLaunch case differently from the standard disk case and produces an untyped array where a typed one is expected.The MS Learn doc page for
Initialize-AzDataProtectionBackupInstanceinstructs users to mutateDataStoreParametersList[0].ResourceGroupIdpost-call — implying the cmdlet is meant to return a model with that property already constructed and typed. For the TrustedLaunch disk, the cmdlet never returns because the construction itself fails.Workaround currently in use
We are detecting this specific error signature (
DataStoreParametersList+IDataStoreParameters) in PowerShell and skipping the disk for the run with a single[WARN]log line. On non-TrustedLaunch disks the script proceeds normally. This workaround is fragile across module updates because it relies on exception string matching.Impact
Issue script & Debug output
Environment data
Module versions
Error output