Unable access OS disk of Virtual Machines Scale Set

Question

Unable access OS disk of Virtual Machines Scale Set

Tan Boon Huan 20

I received error when I tried to access the personal data OS disk of my VMSS.

"The access token is from the wrong issuer <personal data>. It must match the tenant <personal data>associated with this subscription. Please use the authority (URL) <personal data> to get the token. Note, if the subscription is transferred to another tenant there is no impact to the services, but information about new tenant could take time to propagate (up to an hour). If you just transferred your subscription and see this error message, please try back later."

My subscriptions were transferred to new tenant few months ago and my AKS and node pools were recreated.

However, the VMSS OS disk still showing that error and linked to old tenant.

I am unsure how to resolve this issue and would appreciate your assistance.

Manish Deshpande 5,255 Reputation points Microsoft External Staff Moderator

2026-01-01T09:13:07.26+00:00
Hello @Tan Boon Huan

Please try the below steps to fix the issue.

When an Azure Subscription is moved from Tenant A → Tenant B, several resources get relinked automatically to the new tenant.

But VMSS OS disks (and also managed disks, snapshots, images) can sometimes retain:

Old tenant ID

Old identity authority (sts.windows.net/)

Old role assignments

Old RBAC permissions

So when the user tries to access the disk using Tenant B’s token, Azure checks the disk metadata and finds:

Disk expects Tenant A’s token

User is providing Tenant B’s token

Mismatch → Access denied

Step 1 Reassociate Disk With New Tenant

Re-register Microsoft.Compute

az provider register --namespace Microsoft.Compute

Update the Disk Using “Update” Command

az disk update \ --name <disk-name> \ --resource-group <rg-name>

Step 2 Recreate VMSS or Reimage Instances

If metadata cannot be refreshed:

Delete the VMSS instances (not the scale set)

Let VMSS recreate them
az vmss reimage --resource-group <rg> --name <vmss>

Step 3

If disk is corrupted with old tenant metadata:

Create a snapshot

Create a new disk from snapshot

Attach to VMSS or create a custom image

This ensures new metadata is generated.

Step 4
Ensure You Are Logged Into Correct Tenant

az login --tenant <correct-tenant-id>

Thanks,
Manish Deshpande.
Manish Deshpande 5,255 Reputation points Microsoft External Staff Moderator

2026-01-02T03:50:00.2933333+00:00

Hello @Tan Boon Huan

I wanted to check if my last response made sense. I’d be glad to assist further or explain anything in more detail and please accept as Yes and upvote if the answer is helpful so that it can help others in the community.
Tan Boon Huan 20 Reputation points

2026-01-05T05:42:07.0233333+00:00

Hello Manish,

I tried few suggestions above, but it seems not helping to my case.

Everything was working well in my subscriptions and AKS but I just unable to access the OS disk to change the tier.

I have not tried the reimage yet, but it seems like not really helping in the case. because the error show I was tried to get access token from my tenant (current and correct) but it said wrong issuer, however it still linked to another tenant. I feel so strange.
Manish Deshpande 5,255 Reputation points Microsoft External Staff Moderator

2026-01-06T09:06:58.0066667+00:00

Hello @Tan Boon Huan

I have requested few details over the private message and awaiting for your response once we have the details we can connect offline to fix the issue.
Manish Deshpande 5,255 Reputation points Microsoft External Staff Moderator

2026-01-13T04:57:59.8+00:00

Hello @Tan Boon Huan

I have requested few details over the private message and awaiting for your response once we have the details we can connect offline to fix the issue.
Tan Boon Huan 20 Reputation points

2026-01-13T05:48:03.34+00:00

Sorry for late reply.

I do not receive any private message from you.
Manish Deshpande 5,255 Reputation points Microsoft External Staff Moderator

2026-01-19T13:57:01.9633333+00:00
Hello @Tan Boon Huan The only reliable fix is to force new disk identity generation under the current tenant:

Create a snapshot of the affected OS disk

Create a new managed disk from the snapshot

This generates fresh metadata bound to the current tenant

Recreate the VMSS (or create a custom image using the new disk)

VMSS does not support live OS disk replacement, so recreation is required

After this, disk control‑plane operations (tier change, attach/detach, resize) work as expected.

Detailed steps for the above points:

Create a snapshot of OS Disk :

az`` snapshot create \

``--resource-group <rg> \

``--name <snapshot-name> \

``--source <os-disk-id>

Create a New OS disk from snapshot : A new disk is created under the current tenant authority.

az`` disk create \

``--resource-group <rg> \

``--name <new-os-disk-name> \

``--source <snapshot-name> \

``--sku Premium_LRS

``

Recreate the VMSS using the New Disk: For VMSS, direct OS disk swap is not supported. What worked earlier:

Create a new VMSS (or custom image)

Point it to the new disk / image

Validate access → then decommission old VMSS

Links :
Subscription transfer and behaviour https://learn.microsoft.com/en-us/azure/role-based-access-control/transfer-subscription

Thanks,

Manish Deshpande.
Manish Deshpande 5,255 Reputation points Microsoft External Staff Moderator

2026-01-20T09:13:02.53+00:00

Hello @Tan Boon Huan

I wanted to check if my last response made sense. I’d be glad to assist further or explain anything in more detail and please accept as Yes and upvote if the answer is helpful so that it can help others in the community.
Manish Deshpande 5,255 Reputation points Microsoft External Staff Moderator

2026-01-21T10:53:00.4366667+00:00

Hello @Tan Boon Huan

I wanted to check if my last response made sense. I’d be glad to assist further or explain anything in more detail and please accept as Yes and upvote if the answer is helpful so that it can help others in the community.

2 answers

Your answer

Manish Deshpande 5,255 Reputation points Microsoft External Staff Moderator

2026-01-01T09:13:07.26+00:00

Hello @Tan Boon Huan

Please try the below steps to fix the issue.

When an Azure Subscription is moved from Tenant A → Tenant B, several resources get relinked automatically to the new tenant.

But VMSS OS disks (and also managed disks, snapshots, images) can sometimes retain:

Old tenant ID

Old identity authority (sts.windows.net/)

Old role assignments

Old RBAC permissions

So when the user tries to access the disk using Tenant B’s token, Azure checks the disk metadata and finds:

Disk expects Tenant A’s token

User is providing Tenant B’s token

Mismatch → Access denied

Step 1 Reassociate Disk With New Tenant

Re-register Microsoft.Compute

az provider register --namespace Microsoft.Compute

Update the Disk Using “Update” Command

az disk update \ --name <disk-name> \ --resource-group <rg-name>

Step 2 Recreate VMSS or Reimage Instances

If metadata cannot be refreshed:

Delete the VMSS instances (not the scale set)

Let VMSS recreate them
az vmss reimage --resource-group <rg> --name <vmss>

Step 3

If disk is corrupted with old tenant metadata:

Create a snapshot

Create a new disk from snapshot

Attach to VMSS or create a custom image

This ensures new metadata is generated.

Step 4
Ensure You Are Logged Into Correct Tenant

az login --tenant <correct-tenant-id>

Thanks,
Manish Deshpande.
Manish Deshpande 5,255 Reputation points Microsoft External Staff Moderator

2026-01-02T03:50:00.2933333+00:00

Hello @Tan Boon Huan

I wanted to check if my last response made sense. I’d be glad to assist further or explain anything in more detail and please accept as Yes and upvote if the answer is helpful so that it can help others in the community.
Tan Boon Huan 20 Reputation points

2026-01-05T05:42:07.0233333+00:00

Hello Manish,

I tried few suggestions above, but it seems not helping to my case.

Everything was working well in my subscriptions and AKS but I just unable to access the OS disk to change the tier.

I have not tried the reimage yet, but it seems like not really helping in the case. because the error show I was tried to get access token from my tenant (current and correct) but it said wrong issuer, however it still linked to another tenant. I feel so strange.
Manish Deshpande 5,255 Reputation points Microsoft External Staff Moderator

2026-01-06T09:06:58.0066667+00:00

Hello @Tan Boon Huan

I have requested few details over the private message and awaiting for your response once we have the details we can connect offline to fix the issue.
Manish Deshpande 5,255 Reputation points Microsoft External Staff Moderator

2026-01-13T04:57:59.8+00:00

Hello @Tan Boon Huan

I have requested few details over the private message and awaiting for your response once we have the details we can connect offline to fix the issue.
Tan Boon Huan 20 Reputation points

2026-01-13T05:48:03.34+00:00

Sorry for late reply.

I do not receive any private message from you.
Manish Deshpande 5,255 Reputation points Microsoft External Staff Moderator

2026-01-19T13:57:01.9633333+00:00

Hello @Tan Boon Huan The only reliable fix is to force new disk identity generation under the current tenant:

Create a snapshot of the affected OS disk

Create a new managed disk from the snapshot

This generates fresh metadata bound to the current tenant

Recreate the VMSS (or create a custom image using the new disk)

VMSS does not support live OS disk replacement, so recreation is required

After this, disk control‑plane operations (tier change, attach/detach, resize) work as expected.

Detailed steps for the above points:

Create a snapshot of OS Disk :

az`` snapshot create \

``--resource-group <rg> \

``--name <snapshot-name> \

``--source <os-disk-id>

Create a New OS disk from snapshot : A new disk is created under the current tenant authority.

az`` disk create \

``--resource-group <rg> \

``--name <new-os-disk-name> \

``--source <snapshot-name> \

``--sku Premium_LRS

``

Recreate the VMSS using the New Disk: For VMSS, direct OS disk swap is not supported. What worked earlier:

Create a new VMSS (or custom image)

Point it to the new disk / image

Validate access → then decommission old VMSS

Links :
Subscription transfer and behaviour https://learn.microsoft.com/en-us/azure/role-based-access-control/transfer-subscription

Thanks,

Manish Deshpande.
Manish Deshpande 5,255 Reputation points Microsoft External Staff Moderator

2026-01-20T09:13:02.53+00:00

Hello @Tan Boon Huan

I wanted to check if my last response made sense. I’d be glad to assist further or explain anything in more detail and please accept as Yes and upvote if the answer is helpful so that it can help others in the community.
Manish Deshpande 5,255 Reputation points Microsoft External Staff Moderator

2026-01-21T10:53:00.4366667+00:00

Hello @Tan Boon Huan

I wanted to check if my last response made sense. I’d be glad to assist further or explain anything in more detail and please accept as Yes and upvote if the answer is helpful so that it can help others in the community.

Answer 1

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more

Answer 2

To resolve the issue with accessing the OS disk of your Virtual Machine Scale Set (VMSS) that is linked to an old tenant, you may need to ensure that the identity used to access the disk is properly configured with the new tenant. Here are some steps you can take:

Check Managed Identity Configuration: Ensure that the managed identity for your VMSS is correctly configured for the new tenant. You can refer to the Azure documentation on how to configure managed identities for Azure resources on a VM.
Rebind the Kubelet Identity: If the error log indicates that the identity isn't found, you may need to manually bind the kubelet identity to the VMSS.
Wait for Propagation: Since you mentioned that the subscriptions were transferred a few months ago, if you recently made changes, it might take some time for the new tenant information to propagate fully. Wait for up to an hour and try accessing the OS disk again.
Check Token Issuer: Make sure that you are using the correct authority URL to obtain the access token. It should match the tenant associated with your subscription.

If these steps do not resolve the issue, consider submitting a support ticket to Azure support for further assistance.

References:

OrasPullUnauthorizedVMExtensionError error code (212) when deploying an AKS cluster

Share via

Unable access OS disk of Virtual Machines Scale Set

2 answers

Your answer