Unable to dissociate public IP from non-existent load balancer - Batch account stuck in AccountBeingDeleted/Deleting state

Daniel-4204 290 Reputation points
2026-05-29T16:22:09.88+00:00

Batch account has been stuck in AccountBeingDeleted/Deleting state since May 28, 2026. Deletion is blocked by a public IP created by the Batch service, which holds a stale ipConfiguration reference to a Batch-created load balancer that returns 404 via ARM API and does not exist. ARM PUT and az network public-ip update --remove ipConfiguration both fail to clear the reference. The account cannot be re-deleted as it is already in a deleting state. Backend removal of the orphaned ipConfiguration reference on the public IP is required. Reference: https://learn.microsoft.com/en-us/answers/questions/5599327/unable-to-delete-public-ip-address-its-associated

The resolution in other past public cases appear to be "The product group team has removed the associations from the PIPs on the backend, allowing the customer to delete the PIPs.". Please can you reach out to me and delete this orphaned IP address.

Many thanks.

-Daniel

User's image

Azure Batch
Azure Batch

An Azure service that provides cloud-scale job scheduling and compute management.

Answer accepted by question author

Thanmayi Godithi 11,550 Reputation points Microsoft External Staff Moderator
2026-05-29T16:30:19.7+00:00

Hi Daniel-4204 ,

Thank you for reaching out on Microsoft Q&A forum.

Could you try the following workaround (this has helped in some scenarios involving orphaned load balancer references):

Attempt to recreate a load balancer with the same name and configuration as the missing one.

Try to associate the existing Public IP with this newly created load balancer.

Once attached, attempt to detach/remove the Public IP properly from the recreated load balancer.

After detaching, try deleting the Public IP and completing the Batch account deletion again.

The idea behind this approach is to restore the missing dependency so that Azure can allow a clean disassociation.

Was this answer helpful?

1 person found this answer helpful.
0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Daniel-4204 290 Reputation points
    2026-06-03T03:08:05.3933333+00:00

    Update: Resolved with additional context:

    I am happy to report this issue has been resolved with the assistance of Microsoft Backend Support. I want to thank Thanmayi for the support and for the following suggestion which I believe was ultimately the key to resolution:

    "Attempt to recreate a load balancer with the same name and configuration as the missing one. Try to associate the existing Public IP with this newly created load balancer. Once attached, attempt to detach/remove the Public IP properly from the recreated load balancer. After detaching, try deleting the Public IP and completing the Batch account deletion again."

    Important note for this workaround in my case: It was not possible to disassociate a public IP from an Azure Batch-managed load balancer through any standard client-side operation. Because these load balancers and public IPs are auto-provisioned and managed by the Batch service, ARM will not allow the PIP to be detached individually. This is a critical constraint that changes how the resolution was approached.

    What was tried and failed:

    • (CLI) ARM REST PUT on the public IP with ipConfiguration set to null: the platform re-injected the reference on every attempt
    • (CLI) az network lb frontend-ip update --remove publicIpAddress :failed with FrontendIPConfigurationHasNoSubnetOrPublicIPAddressOrPublicIPPrefix since ARM requires a frontend config to always reference a PIP, subnet, or prefix
    • Recreating the load balancer via CLI and REST PUT using the exact original name: failed repeatedly with InvalidResourceReference as ARM enforced the original Batch-generated configuration referencing backend pools, outbound rules, and NAT pools that no longer existed
    • Portal creation of the load balancer: the orphaned PIP appeared under "Cannot be associated with this load balancer" and could not be attached during creation (but eventually showed up on its own as the load balancer front end PIP).

    The anomaly: At some point during the troubleshooting process the load balancer reappeared in the resource group on its own dispite the errors: likely as a side effect of one of the earlier CLI recreation attempts partially succeeding on the backend despite returning errors client-side. Notably, when the load balancer reappeared, the orphaned public IP (after quite some time) automatically re-associated itself with the load balancer without any manual intervention. This self-association is consistent with the Batch service managing the relationship between these two resources at the platform level.

    What ultimately worked: Once the load balancer reappeared and the PIP had self-associated, I found that the orphaned public IP and the load balancer still could not be deleted individually. However, selecting both resources simultaneously in the Azure portal and deleting them together as a pair succeeded where individual deletion did not. After both resources were removed, the batch account s61baprod which had been stuck in AccountBeingDeleted/Deleting state since May 28, 2026 was finally able to process through and complete its deletion on its own after some more time passed (probably about another hour).

    I believe the recreation of the load balancer under its exact original name restored the dependency relationship between the two Batch-managed resources, which then allowed the simultaneous deletion to succeed and ultimately unblocked the stuck batch account deletion.

    I hope this detailed account helps others who encounter the same issue. Thank you Thanmayi and the Microsoft Q&A team for the support.

    Was this answer helpful?

    0 comments

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.