Azure Managed DevOps Pool: Agent provisioning fails with UnableToDownloadWorkerCheckNetwork and no agents are created

UnableToDownloadWorkerCheckNetwork means the provisioning infrastructure cannot reach a prerequisite download endpoint, so first check whether the new subnet is private (defaultOutboundAccess: false) and, if it has no other working egress path, associate an Azure NAT Gateway or another explicit outbound mechanism.

1. Verify and provide outbound connectivity

Having no NSG or route table does not guarantee Internet egress. For API versions released after March 31, 2026, new virtual networks default to private subnets, and the Azure portal already defaults to creating private subnets. A private subnet cannot reach public endpoints unless it has explicit outbound connectivity.^1^

1. Open Azure portal → Virtual network → Subnets → your MDP subnet.
2. Inspect the subnet configuration/resource JSON for defaultOutboundAccess.
3. Determine whether the subnet already has an explicit egress mechanism:
   • Azure NAT Gateway
   • Azure Firewall or another network virtual appliance with appropriate routing
   • Another supported explicit outbound design
4. If defaultOutboundAccess is false and none exists:
   • Create an Azure NAT Gateway with a public IP.
   • Associate it with the MDP subnet.
   • Queue another pipeline and check whether Provisioned and Ready increase.

A NAT Gateway associated with a subnet provides outbound access through its public IP.^2^ Suitable Azure permissions are required to create the gateway and modify the subnet association.

If explicit egress already exists, do not add another mechanism yet; test the required endpoints and investigate filtering upstream.

2. Allow the worker, agent, and Ubuntu endpoints

Microsoft defines this error as network infrastructure blocking one of the prerequisite endpoints. The unqualified error does not identify which one; only an endpoint-qualified error such as UnableToDownloadWorkerCheckNetwork[<endpoint>], provisioning logs, or connectivity testing can narrow it down.^3^

The worker download is:

• rmprodbuilds.azureedge.net — Managed DevOps Pools worker binaries and startup scripts.
• rm-agent.prod.manageddevops.microsoft.com — agent portion of the worker binaries; covered by *.prod.manageddevops.microsoft.com.
• *.queue.core.windows.net — worker queue communication.

The machine subsequently needs:

• download.agent.dev.azure.com — Azure Pipelines agent package.
• dev.azure.com — Azure DevOps communication.
• Ubuntu provisioning endpoints:
  • azure.archive.ubuntu.com over HTTP 80
  • www.microsoft.com
  • security.ubuntu.com
  • packages.microsoft.com
  • ppa.launchpad.net
  • dl.fedoraproject.org

The remaining documented endpoints use HTTPS unless stated otherwise.^4^

Check for controls outside the subnet itself:

• Azure Firewall or another upstream firewall
• Azure Policy affecting private subnets or egress
• Hub/spoke routing inherited outside the subnet
• DNS filtering
• TLS inspection, particularly if the code changes to UnableToDownloadWorkerCheckNetwork_TLSIssue
• Proxy variables baked into the image; incorrectly configured VSTS_AGENT_INPUT_PROXY* variables cause provisioning failures

3. Validate endpoint reachability correctly

Microsoft provides ValidateMDPEndpoints.ps1, which must run from a resource using the network path being tested.^4^

However, an MDP subnet is delegated for exclusive pool use, so an ordinary customer VM normally cannot be deployed into the already-associated subnet. Use one of these approaches:

1. During a controlled recreation, run the test VM before delegating and associating the subnet.
2. Use a temporary subnet with identical DNS, NSG, route, firewall, policy, and egress settings.
3. Temporarily detach/reconfigure the exact subnet only if operationally safe.

An equivalent subnet is only an approximation. Separately compare every subnet-specific setting on the actual MDP subnet.

4. Why no VMSS appears

This absence is expected. Managed DevOps Pools uses a hosted-on-behalf architecture: agent VMs exist in a Microsoft-owned subscription, while your delegated subnet supplies their network connection. Consequently, no customer-owned VM Scale Set needs to appear in your subscription.^5^

5. Capture evidence before escalation

Configure Managed DevOps Pool → Monitoring → Diagnostic settings → Add diagnostic setting, enable Resource Provisioning Logs, and send them to a storage account or event hub. Reproduce the failure and retain the timestamps, request IDs, endpoint-qualified errors, image, SKU, region, and outbound configuration.^6^

If all required endpoints succeed from an accurately equivalent path and provisioning still fails across regions, open an Azure support request with those logs and request IDs. That separates an upstream service-side failure from an unobserved subnet or egress restriction.

References

1. Default outbound access in Azure
2. What is Azure NAT Gateway?
3. Monitor - Managed DevOps Pools | Microsoft Learn
4. Configure networking - Managed DevOps Pools | Microsoft Learn
5. Microsoft Managed DevOps Pools architecture overview
6. Diagnostics logs