Unable to Delete Storage Account- Yet No Legal Hold exists No visible Immutability Policy exists

NateS-5294 0 Reputation points
2026-09-02T21:17:31.22+00:00

Problem description

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

I inherited an Azure subscription and am trying to remove 3 unused Storage Accounts. As we inherited the account we are paying 600/month for something we don't even use as we already stored their backups else ware. I cannot delete the associated subscription. As these are blocked from deletion

All 3 storage accounts are the same symptoms, these storage accounts are the only resources even on the subscription.

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

Symptoms

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

Azure Storage Accounts Cannot Be Deleted Due to Immutable Storage With Versioning

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

Attempting to delete the storage accounts returns:

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

StorageAccountProtectedFromDeletion

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

Attempting to delete the containers returns:

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

ContainerImmutableStorageWithVersioningEnabled

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

Attempting to disable immutable storage returns:

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

PropertyIsImmutable

The property 'immutableStorageWithVersioning.enabled'

cannot be updated as it is immutable.

Enviroment Details

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

Storage account query returns:

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

{

"enabled": true,

"immutabilityPolicy": null

}

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

Container query returns:

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

{

"immutableStorageWithVersioningEnabled": true,

"hasImmutabilityPolicy": false,

"hasLegalHold": false

}

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

Data Protection Settings

Current configuration:

  • Version-Level Immutability Support: Enabled
  • Blob Versioning: Enabled
  • Blob Soft Delete: Disabled
  • Container Soft Delete: Disabled

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

Investigation Performed

Using Azure CLI and storage account keys, I discovered the containers are not actually empty.

Blob listing shows:

  • 5,000+ blob versions
  • Azure returns a Next Marker indicating more than 5,000 objects

Example objects:

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

VMB9/

IM/

RM/

TestConnection/

*.altj

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

Example version data:

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

{

"versionId": "2023-10-26T*9:47:38.1807281Z",

"immutabilitypolicy": {

"expiryTime": null,

"policyMode": null

}

}

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

Additional Findings

  • No Legal Hold found
  • No visible Immutability Policy found
  • No Lifecycle/Management Policy found
  • Blob versions appear to have:

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

{

"expiryTime": null,

"policyMode": null

}

A lot of the blobs are no longer current blobs but versions

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

Current blobs often return:

a { text-decoration: none; color: #464feb; }tr th, tr td { border: 1px solid #e6e6e6; }tr th { background-color: #f5f5f5; }

Question

Has anyone encountered a situation where:

  • immutableStorageWithVersioning.enabled = true
  • No Legal Hold exists
  • No visible Immutability Policy exists
  • Blob versions still exist
  • Container deletion fails with ContainerImmutableStorageWithVersioningEnabled
  • The immutable setting itself cannot be disabled because it is immutable

I am confused as I don't see anywhere where there is NO retention dates or any legal holds telling me when it expires.

Is there a supported method to remove the remaining blob versions and delete the storage accounts, or does this require Microsoft backend intervention?

It looks like some left over Backups that are just no longer needed These Storage Accounts are no longer needed and need to be permanently removed from the Azure subscription. Then we can cancel the subscription.

Azure Storage
Azure Storage

Globally unique resources that provide access to data management services and serve as the parent namespace for the services.

0 comments
Answer recommended by moderator
SHOUMIK CHAKRAVARTY 660 Reputation points
2026-09-03T01:31:47.6566667+00:00

Hi @NateS-5294 , This is all fixable yourself and doesn't need Microsoft. The reason it looks impossible is that the rule you're hitting has nothing to do with legal holds or immutability policies, which is exactly why you can't find any.

Once version-level immutability support is turned on, containers and accounts have to be empty before they can be deleted, whether or not anything is actually under retention. The docs say it twice, once for containers and once for accounts. From Configure immutability policies for blob versions:

"If version-level immutability support is enabled for a container and the container contains one or more blobs, then you must delete all blobs in the container before you can delete the container, even if there are no immutability policies in effect for the container or its blobs."

"If version-level immutability support is enabled for the storage account and the account contains one or more containers, then you must delete all containers before you delete the storage account, even if there are no immutability policies in effect for the account or containers."

The bit that matters in both is "even if there are no immutability policies in effect". Your hasImmutabilityPolicy: false and hasLegalHold: false readings are correct, they just don't help you. There's no expiry date to wait for here either. Nothing is actually under retention, so nothing is going to lapse on its own. It stays blocked until you empty the containers yourself.

And the reason you can't switch the setting off, from the same page:

"Version-level immutability cannot be disabled after it is enabled on the storage account, although unlocked policies can be deleted."

So it's a one way door, which is what PropertyIsImmutable is telling you.

Working order is a single pass over every version, including the current ones, deleting each by version ID. Then the containers, then the account.

Versions are where this gets tedious, and you've already noticed most of what's in there are versions rather than current blobs. Deleting a blob doesn't take its previous versions with it, so you'll need to enumerate them and delete each one by ID. Something like az storage blob list --include v to enumerate, paging past that 5,000 marker you hit, then az storage blob delete --version-id <id> for each. Snapshots are separate again, so --delete-snapshots include on the blob deletes.

Worth checking that syntax against the CLI reference before you script it against 5,000 objects. I'm going from memory on the flags.

As for whether they'll actually go: the docs say a previous version can be deleted, and that it's a time-based retention policy that prevents it. Yours show expiryTime null and policyMode null, so there's nothing in effect and they should delete fine. If a particular version refuses, that one has a policy on it, and if the policy is unlocked you can delete it on that version first.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.

Was this answer helpful?

3 people found this answer helpful.

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

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.