Unable to delete a subnet or clear its service association links after unsuccessfully trying to delete a managed devops pool

Question

Unable to delete a subnet or clear its service association links after unsuccessfully trying to delete a managed devops pool

Koenig, Jennifer 25

The subnet is permanently locked due to an orphaned Service Association Link (SAL) left behind by a deleted Managed DevOps Pool resource. All user-side ARM template overrides, CLI modifications, and PowerShell Set-AzVirtualNetwork calls return 'Subnet is in use and cannot be updated'. Please route this ticket directly to the Network Resource Provider engineering team to perform an internal backend purge on the Service Association Link.

Vinayteja Lellela 5 Reputation points Microsoft External Staff Moderator

2026-06-26T16:44:50.13+00:00
Hello Jennifer,

Sounds like you’ve hit the classic case where an orphaned Service Association Link (SAL) is left behind after a Managed DevOps Pool deletion, and that SAL keeps the subnet stuck in an “in use / cannot be updated or deleted” state.

When SALs persist (or are orphaned), the platform typically can’t clear them from the customer side immediately, and the subnet deletion remains blocked until the SAL is removed.

What you can try

Even though you mentioned ARM/CLI/PowerShell changes aren’t helping, the standard troubleshooting sequence is:

Check whether the subnet still has Service Association Links
az network vnet subnet show \ --resource-group <resource-group> \ --vnet-name <vnet-name> \ --name <subnet-name> \ --query "serviceAssociationLinks[].{link:link, linkedResourceType:linkedResourceType}" \ --output table

Verify there are no remaining resources from the linked service in that subnet The docs emphasize that if any resources from the service tied to the SAL still exist in the subnet, you must delete them first.

Wait for platform cleanup If SALs remain after you’ve deleted the dependent resources; they may take 10–15 minutes to clear automatically. Then retry the delete.

Can you please update us if the action plan provided was helpful?

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.

If these answer your question, click "Upvote" which may be beneficial to other community members reading this thread.

1 answer

Your answer

Vinayteja Lellela 5 Reputation points Microsoft External Staff Moderator

2026-06-26T16:44:50.13+00:00

Hello Jennifer,

Sounds like you’ve hit the classic case where an orphaned Service Association Link (SAL) is left behind after a Managed DevOps Pool deletion, and that SAL keeps the subnet stuck in an “in use / cannot be updated or deleted” state.

When SALs persist (or are orphaned), the platform typically can’t clear them from the customer side immediately, and the subnet deletion remains blocked until the SAL is removed.

What you can try

Even though you mentioned ARM/CLI/PowerShell changes aren’t helping, the standard troubleshooting sequence is:

Check whether the subnet still has Service Association Links
az network vnet subnet show \ --resource-group <resource-group> \ --vnet-name <vnet-name> \ --name <subnet-name> \ --query "serviceAssociationLinks[].{link:link, linkedResourceType:linkedResourceType}" \ --output table

Verify there are no remaining resources from the linked service in that subnet The docs emphasize that if any resources from the service tied to the SAL still exist in the subnet, you must delete them first.

Wait for platform cleanup If SALs remain after you’ve deleted the dependent resources; they may take 10–15 minutes to clear automatically. Then retry the delete.

Can you please update us if the action plan provided was helpful?

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.

If these answer your question, click "Upvote" which may be beneficial to other community members reading this thread.

Answer 1

Hello Koenig, Jennifer,

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

I understand that you are unable to delete a subnet or clear its service association links after unsuccessfully trying to delete a managed DevOps pool.

The failure is caused by an orphaned, service-owned Service Association Link (SAL) left on the subnet by Managed DevOps Pools. In this configuration, Managed DevOps Pools can inject agents into an existing virtual network, and that subnet is reserved for the pool. The fact is when agents are injected into an existing VNet, all pool VMs use that subnet and no other resources can use it.

What you can do is to:

First, confirm the subnet is blocked by serviceAssociationLinks/ManagedAgents.
If the Managed DevOps Pool resource still exists, restore the required DevOpsInfrastructure permissions and delete the pool normally.
If the Managed DevOps Pool resource no longer exists, do not attempt ARM/CLI/PowerShell force updates. Open an Azure Support request for backend cleanup of the orphaned SAL.
After the SAL is removed, delete the subnet normally.

This issue is not solved by removing NSGs, route tables, service endpoints, or subnet delegation alone. Azure subnet troubleshooting guidance confirms that subnet deletion/modification can be blocked by dependencies such as private endpoints, IP configurations, delegations, and serviceAssociationLinks, and these must be identified before deletion.

Use the below resource links for more reading and implementation steps:

Do not hesitate to let me know if you have any other questions, steps or clarifications.

I hope this is helpful. Please close the thread by upvoting and accepting the answer if any part of it is helpful.

Share via

Unable to delete a subnet or clear its service association links after unsuccessfully trying to delete a managed devops pool

1 answer

Your answer