Share via

Update-AzSqlInstanceVulnerabilityAssessmentSetting issues

Julie 220 Reputation points
2026-03-04T19:53:59.7166667+00:00

Hello,

I am configuring Vulnerability Assessment for an Azure SQL Managed Instance using a Storage Account located in another subscription.

This configuration works in the Azure Portal but fails when using the PowerShell cmdlet Update-AzSqlInstanceVulnerabilityAssessmentSetting, which cannot find the storage account.

Is cross-subscription storage supported for SQL Managed Instance Vulnerability Assessment, and if so, how should it be configured via PowerShell?

Azure SQL Database

2 answers

Sort by: Most helpful
  1. Saraswathi Devadula 15,850 Reputation points Microsoft External Staff Moderator
    2026-03-05T05:29:14.82+00:00

    Hello **Julie

    **You can absolutely point your Managed Instance VA to a storage account in another subscription – it isn’t limited to “same-sub” only. The trick is that when you call Update-AzSqlInstanceVulnerabilityAssessmentSetting you must reference the storage account by its full resource ID (or its key/SAS URI), not just by name. Here’s a quick PowerShell pattern you can adapt:

    # 1. Make sure you’re logged into both subs (or have a context for the storage sub)
    Connect-AzAccount
    # (Optional) Set context to the storage subscription so Get-AzStorageAccount will find it:
    Set-AzContext -SubscriptionId "<storage-subscription-id>"
    
    # 2. Grab the StorageAccount object
    $sa = Get-AzStorageAccount -ResourceGroupName "RG-Storage" -Name "myStorageAcct"
    
    # 3. Switch context back to the MI subscription if needed
    Set-AzContext -SubscriptionId "<mi-subscription-id>"
    
    # 4. Update VA on your Managed Instance
    Update-AzSqlInstanceVulnerabilityAssessmentSetting   
    -ResourceGroupName "RG-MI"
    -InstanceName "myManagedInstance" 
    -StorageAccountName "mystorage"
    -ScanResultsContainerName "vulnerability-assessment"    
    -RecurringScansInterval Weekly
    

    Key things to check:

    • Storage account must be GPv1 or GPv2, Standard performance, same region as your MI.
    • The MI’s managed identity (or your user principal) needs these roles on the storage account:

    • Storage Blob Data Reader (to read/write blobs)
    • Owner or User Access Administrator (to let VA save its settings) • You also need SQL Security Manager on the Managed Instance itself.

    If you still see “storage account not found,” double-check:

    1. That you’re targeting the correct subscription context when you call Get-AzStorageAccount or set the resource ID,
    2. That your PowerShell module (Az.Sql) is up to date, and
    3. Your identity has Microsoft.Storage/storageAccounts/read permission on that storage resource.

    https://learn.microsoft.com/en-us/powershell/module/az.sql/update-azsqlinstancevulnerabilityassessmentsetting?view=azps-15.4.0
    https://learn.microsoft.com/en-us/azure/defender-for-cloud/sql-azure-vulnerability-assessment-overview
    https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/storage#storage-blob-data-reader

    Please do let us know if you have any further queries. I am happy to address you.

    0 comments No comments

  2. Q&A Assist
    2026-03-04T19:54:13.23+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    Cross-subscription storage accounts are supported for Azure SQL Managed Instance Vulnerability Assessment, but the PowerShell cmdlet must be given a storage reference it can resolve without needing to look up the storage account as an Azure resource in the current subscription.

    For Update-AzSqlInstanceVulnerabilityAssessmentSetting, there are two supported patterns in the context:

    1. Use a storage account name (same-subscription scenario)
    Update-AzSqlInstanceVulnerabilityAssessmentSetting `
        -ResourceGroupName "ResourceGroup01" `
        -InstanceName "ManagedInstance01" `
        -StorageAccountName "mystorage" `
        -ScanResultsContainerName "vulnerability-assessment" `
        -RecurringScansInterval Weekly `
        -EmailAdmins $true `
        -NotificationEmail @("******@mail.com" , "******@mail.com")
    

    This parameter set assumes the cmdlet can resolve the storage account by name in the context of the subscription where the managed instance resides. If the storage account is in another subscription, this resolution can fail.

    1. Use a Blob Storage SAS URI (cross-subscription–friendly)

    To avoid subscription-based resolution, configure Vulnerability Assessment to use a container-level SAS URI from the storage account, which works regardless of subscription, as long as the SAS grants the required permissions:

    Update-AzSqlInstanceVulnerabilityAssessmentSetting `
        -ResourceGroupName "ResourceGroup01" `
        -InstanceName "ManagedInstance01" `
        -BlobStorageSasUri "https://mystorage.blob.core.windows.net/vulnerability-assessment?st=XXXXXX" `
        -RecurringScansInterval Weekly `
        -EmailAdmins $true `
        -NotificationEmail @("******@mail.com" , "******@mail.com")
    

    Key points for cross-subscription configuration via PowerShell:

    1. In the storage account’s subscription, create a container (for example, vulnerability-assessment).
    2. Generate a SAS token on that container with at least read, write, and list permissions for the duration needed.
    3. Build the full SAS URI, for example: https://<storageaccount>.blob.core.windows.net/<container>?<sas-token>
    4. Run Update-AzSqlInstanceVulnerabilityAssessmentSetting against the managed instance using the -BlobStorageSasUri parameter set instead of -StorageAccountName.

    This approach avoids the need for the cmdlet to find the storage account in the managed instance’s subscription and is the supported way (per the syntax and examples) to configure Vulnerability Assessment when using a storage account in another subscription.


    References:

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.