How to delete a left over load balancer in Azure?

Question

I am trying to delete the VNETs in the subscription. It tells me I can't delete them because there are connected devices. When checking, it shows some load balancer (which I can't see under Load Balancers, so I think it's a leftover from a VNET Gateway). I can't delete this load balancer:{"sessionId":"PII","subscriptionId":"PII","resourceGroup":"PII","errorCode":"401","resourceId":PII","resourceName":"PII","details":"The access token is from the wrong issuer 'PII'. It must match the tenant 'PII/' associated with this subscription. Please use the authority (URL) 'PII' 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."} The tenant mentioned here is unfamiliar to me. Can you help me delete the resources?

Answer 1

Hi @TinoDonderwinkel-3216,

This issue is caused by a tenant-mismatch authentication token combined with an orphaned (managed) Load Balancer. Such load balancers are often created automatically by services like Virtual Network Gateway or Private Endpoint. Even if the load balancer does not appear in the Azure Portal, it can still exist in ARM and block VNET deletion.

1.Re-authenticate to the correct tenant

If the subscription was moved to another tenant, you must explicitly sign in to that tenant.

az logout 
az login --tenant <tenant-id> 
az account set --subscription <subscription-id>

• Azure CLI authentication: https://learn.microsoft.com/cli/azure/authenticate-azure-cli
• Set active subscription: https://learn.microsoft.com/cli/azure/account#az-account-set

2.List and delete the blocking Load Balancer

Managed/orphaned load balancers may only be visible via CLI or ARM.

az network lb list --resource-group <resource-group-name>

az network lb delete -g MyResourceGroup -n MyLb

• az network lb list: https://learn.microsoft.com/cli/azure/network/lb#az-network-lb-list
• az network lb delete: https://learn.microsoft.com/cli/azure/network/lb#az-network-lb-delete

3.Delete the VNET

After the blocking resources are removed, delete the virtual network.

az network vnet delete --resource-group myResourceGroup --name myVNet

• Manage / delete virtual networks: https://learn.microsoft.com/azure/virtual-network/manage-virtual-network

After a tenant transfer, Azure backend reconciliation can take up to ~1 hour.

If the above steps didn't help, let us know to assist you further.

If the answer is helpful, please "Accept the answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Answer 2

Hello TinoDonderwinkel-3216,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you would like to know how you can delete a leftover of load-balancer in Azure.

The true core problem is NOT the load balancer itself, however; it is a tenant-mismatch authentication issue blocking deletion of a hidden/orphaned managed load balancer created by a Gateway or Private Endpoint. @Thanmayi Godithi response has really helped to identify the root cause.

Therefore, to delete Orphaned Load Balancer follow the below steps:

1. Identify the correct tenant that owns the subscription by Run:

      az account subscription show --id <subscription-id> --query tenantId -o tsv
   

   This returns the true tenant ID associated with the subscription. This tenant ID must match the issuer expected in the error response, make sure you validated against issue description
2. Re-authenticate into the correct tenant using

      az logout
      az login --tenant <tenant-id>
      az account set --subscription <subscription-id>
   

3. List hidden/orphaned load balancers (ARM-level only) use: az resource list --resource-type Microsoft.Network/loadBalancers -g <resource-group> If it still does not appear use: az network lb list -g <resource-group> --query "[].{name:name, id:id}"This reveals system-managed LB instances invisible in Portal.
4. Force delete the orphaned load balancer using ARM once the LB ID is known (from step 3 above): az resource delete --ids <resource-id>This deletes even system-managed/orphaned load balancers that the Portal cannot show.
5. Retry deleting the VNET: az network vnet delete -g <resource-group> -n <vnet-name>Once the LB is removed, VNET deletion will succeed.
6. If error persists after a recent tenant migration, you have to wait up to 60 minutes, per Azure behavior described in the error itself.

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

---

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Answer 3

The lingering load balancer, created by internal processes to support a VNET or ER Network Gateway, caused the Virtual Network to be in an unstable state. Through resources.azure.com, I was able to 'reset' the state of the VNET, after which I could delete the entire VNET.

Luckily, there was nothing more in it. This was the only way I could see to 'fix' the issue.