Bring Your Own Network for Windows 365: A Practical Guide to Azure Network Connections (ANC)

What it is, when to choose it, what you need in place, and the mistakes to avoid.

When you provision a Cloud PC, the first question is not about the OS image or the SKU. It is about the network: where will this Cloud PC live, and what will it be able to reach?

Windows 365 gives you two answers. You can let Microsoft host the network, or you can bring your own. This post covers the second option, known as Bring Your Own Network (BYON) and configured through an Azure Network Connection (ANC).

Two networking models

What is an Azure Network Connection?

An ANC is the object in the Intune admin center that links Windows 365 to a specific subnet in your Azure subscription. You create it once and reference it from one or more provisioning policies. It holds the subscription, resource group, vNET and subnet. For hybrid scenarios it also holds the AD domain name, the organizational unit (OU) and the domain join credentials.

The ANC also drives the Cloud PC’s location. Cloud PCs created through it land in the Azure region of the vNET, so choosing the vNET is also choosing the region for your users.

Requirements

The requirements depend on the join type.

For Microsoft Entra joined Cloud PCs

• Azure virtual network (vNET): must be in the same region as the Windows 365 desktops. Pick the region closest to your users and confirm Windows 365 is supported there.
• Network bandwidth: make sure your network is configured to meet your needs. Cloud PC traffic is remoting traffic plus whatever the user’s apps pull from your network, so size for both.
• Subnet and IP address space: a subnet within the vNET with available IP addresses. Each Cloud PC consumes one address.

Additional requirements for Microsoft Entra hybrid joined Cloud PCs

• DNS resolution: the Azure vNET must resolve Active Directory Domain Services (AD DS) DNS entries, usually by pointing the vNET’s DNS settings at your domain controllers or a DNS forwarder that can reach them.
• Domain controller access: the vNET must have network access to an enterprise domain controller, in Azure or on-premises. Without it, domain join fails.
• Domain join account and OU: an account with rights to create computer objects in the target OU, and an OU that is synced to Entra ID through Microsoft Entra Connect.

Permissions and service connectivity

The Windows 365 service needs permission to place network interfaces in your subscription. In practice you grant the Windows 365 service principal Reader on the subscription, a network interface role on the resource group, and a network user role on the vNET. The admin who creates the ANC needs enough rights to see and use those resources.

The Cloud PC must also reach the Windows 365 and Azure Virtual Desktop service endpoints, plus Microsoft Entra ID and Intune. If you use a firewall, proxy or forced tunneling, allow the documented endpoints and ports. Most “stuck in provisioning” tickets come from a blocked endpoint.

Connectivity options and trade-offs

BYON does not require a hybrid link. An Entra joined Cloud PC in your own vNET works without one. But if you need to reach on-premises systems, you have two main options.

Some teams start with a VPN and move to ExpressRoute as the user count grows. For a few hundred Cloud PCs that only need light access to file shares and line-of-business apps, a VPN is often enough.

When should you choose BYON?

Choose it when one or more of these is true:

• Cloud PCs must reach on-premises apps, file servers, databases or licensing servers.
• You need Microsoft Entra hybrid join, for example for Group Policy or legacy authentication.
• Security policy requires traffic to pass through your own firewall, NSGs or inspection appliances.
• You need control over IP addressing, DNS or the Azure region.
• You want Cloud PCs in the same vNET topology (hub and spoke, peering) as your other Azure workloads.

Stay on the Microsoft hosted network when users mostly work with Microsoft 365 and SaaS apps, you have no Azure networking team, and speed of rollout matters more than control.

Setting it up: the short version

1. Plan the network. Choose the region, address space and subnet size. Azure reserves five addresses in every subnet, and you will want headroom for reprovisioning, resizing and growth. A dedicated subnet for Cloud PCs makes NSG rules and capacity planning much simpler.
2. Prepare DNS and, for hybrid, AD. Point the vNET at the right DNS servers, confirm domain controllers are reachable, and prepare the OU and the join account.
3. Grant permissions. Give the Windows 365 service principal the roles it needs on the subscription, resource group and vNET.
4. Create the ANC in the Intune admin center under Devices, Windows 365, Azure network connection. Select the subscription, vNET and subnet, and choose the join type.
5. Wait for the health checks. Windows 365 validates the connection on creation and re-runs the checks periodically. Fix any failed check first, because provisioning will not succeed against an unhealthy ANC.
6. Reference the ANC in a provisioning policy, assign it to a group, and let the Cloud PCs provision.

Common pitfalls

• Region mismatch. The vNET must be in the same region as the Cloud PCs. Planning the region after the network is built is a common cause of rework.
• Undersized subnets. A /26 looks generous until you add a second policy, a Frontline pool and reprovisioning headroom.
• DNS that cannot resolve the domain. For hybrid join, this is the most common cause of domain join failures.
• Firewall and forced tunneling surprises. Sending all traffic through a central firewall can block required endpoints and hurt user experience. Allow the required endpoints, and where policy permits, keep remoting traffic off the inspection path.
• Expecting a VPN to behave like ExpressRoute. Test with real user workloads before committing to a design.
• Ignoring cost. The Cloud PC licence is only part of the bill. Gateways, ExpressRoute circuits, firewalls and data transfer in your Azure subscription are on top.

Wrapping up

The Microsoft hosted network gets you running fast. Bring your own network, through an Azure Network Connection, gets you control: your region, address space, DNS, security controls and path to on-premises. The price is a little more planning up front. Get the vNET region, subnet size, DNS and endpoint access right, and the rest of the Windows 365 rollout is much smoother.

Ready to build it? I have written a hands-on walkthrough covering the whole deployment: Deploying an Azure Network Connection (ANC) for W365: A Step-by-Step Guide.

NoteAlways check the current Microsoft Learn documentation on Windows 365 network requirements before you build, because supported regions, endpoint lists and role names change over time.