An Azure network connection is the moment you take ownership of the path your Cloud PCs travel. Build it deliberately, because the service will hold you to it every one to six hours for the life of the connection.
The design article’s position stands: Microsoft-hosted network until a specific resource forces your hand. This article assumes something forced it, an application that needs private line of sight, a hybrid join requirement, a firewall your compliance regime insists Cloud PC traffic traverse, and walks the build the way I do it, prerequisites first, because the ANC wizard is short and everything that goes wrong with ANCs goes wrong in the things the wizard merely references.
Prerequisites: the part that is actually the work
You need an Azure subscription containing a virtual network in a supported Windows 365 region, placed close to the users, not close to the datacenter. The subnet needs headroom: plan roughly one and a half times your maximum Cloud PC count, because provisioning, resizing, and service maintenance consume addresses transiently, and a subnet run tight will fail operations in ways that look mysterious. The admin center now shows available IP capacity per ANC, which is worth checking quarterly once you are live.
Identity and permissions next. You need the Intune Administrator or Windows 365 Administrator role to run the wizard, and, for the first ANC in a subscription, Owner rights on that subscription, because the wizard grants the Windows 365 service principal three permissions on your infrastructure: Reader on the subscription, Windows365 Network Interface Contributor on the resource group, and Windows365 Network User on the virtual network. That is the entire footprint, and it is worth being able to recite it, because sooner or later a security review will ask what a Microsoft service principal is doing in your subscription. The honest answer is: creating network interface cards in one resource group and attaching them to one virtual network, nothing more. Subsequent ANCs in the same subscription need only Reader.
If this is a hybrid join ANC, two more items. The virtual network’s DNS servers must resolve your Active Directory domain, which in practice means pointing the vNet at your AD DS DNS servers, and the network must reach a domain controller. And you need a domain join service account: a dedicated account whose only job is joining computers to the domain and, if you specify one, the target OU, with the computer-account limit on that OU raised through proper delegation rather than by handing the account broad rights. Its credentials are stored in the Windows 365 service, so treat the account accordingly: long random password, no interactive sign-in, no other purpose.
The build, and the health check that gates it
In the Intune admin center, go to Devices, Provision Cloud PCs, Azure network connection, Create, and choose Microsoft Entra Join or Hybrid Microsoft Entra Join. Give the connection a name that is unique in the tenant and descriptive of its network, select the subscription and resource group, then the virtual network and subnet. For a hybrid ANC, provide the domain DNS name, the OU if you use one, and the join account in UPN format with its password. Review and create.
Then wait, on purpose. The service immediately runs its first battery of health checks against everything you referenced, DNS resolution, domain join, endpoint reachability, permissions, and the ANC cannot be assigned to a provisioning policy until that first pass succeeds. Do not fight this gate; it is the product telling you about a problem before the problem becomes forty stuck provisioning jobs. The same checks then re-run every one to six hours forever, and since April 2026 an unreachable required endpoint fails as an error that blocks new provisioning outright, where it used to be a warning you could ignore. An ANC is infrastructure with a heartbeat.
Never write a firewall rule against a Cloud PC’s private IP. The addresses are dynamic, and every reprovision and resize is a chance for that rule to silently stop matching anything.
Operating rules worth writing down
A handful of behaviors will save you incidents if the team knows them in advance. Firewall by subnet or by tag, never by Cloud PC IP, per the pull quote, and secure traffic at the network boundary rather than the individual NIC. Do not put SSL inspection or traffic interception in the Cloud PC’s path; provisioning and the health checks break under it, and Microsoft is explicit that it is unsupported. Leave port 3389 alone; it ships closed on new Cloud PCs and should stay that way, since the supported connection path does not need it. Configure at least one alternate ANC in priority order on any provisioning policy that matters, because a policy whose only ANC is unhealthy simply stops provisioning. Editing an ANC follows the same change model as provisioning policies: existing Cloud PCs keep the settings they were built with until reprovisioned. An ANC that is in use cannot be deleted, and an ANC that sits unused long enough will be deactivated by the service, its health checks paused, so do not build spares ahead of need. And remember the money: egress from your virtual network is billed to your subscription now, which is part of what taking ownership of the path means.
The tenant limit is fifty ANCs, raisable by support ticket with a business case, which is another way of saying: scope them to genuine need, one per region and join type that actually requires the private path, and let the Microsoft-hosted network carry everyone else.
Windows 365
‹ Previous: [W365 3.1] Building the Provisioning Policy
Next: [W365 4] Operating Cloud PCs: The Endpoint You Already Know How to Manage ›
