A Windows 365 Enterprise deployment is decided in one object: the provisioning policy. Everything it references, the join type, the network, the image, is a question about who holds authority, and the answers are hard to change after the fleet exists.
The provisioning policy is the blueprint from which every Cloud PC in its scope is built. It names the network the machine lands on, the identity join it performs, the image it boots from, the device name it receives, and the Entra group whose members deserve one. When a licensed user appears in that group, a Cloud PC materializes to the policy’s specification, and when the policy is wrong, the wrongness is manufactured at scale. So this article treats each field of that blueprint as the design decision it actually is, in the order I argue them with customers.
One structural rule before the decisions: for Enterprise Cloud PCs, a user assigned to multiple provisioning policies gets the first one, and the rest are silently ignored. There is no merge and no conflict warning. Keep policy targeting non-overlapping and your group design deliberate, or your fleet’s configuration becomes a function of assignment order, which is not a sentence anyone wants to say in an incident review.
Join type: Entra join unless you can defend otherwise
Windows 365 Enterprise supports Microsoft Entra join and hybrid Entra join, and my position mirrors the one I hold for physical endpoints throughout the Intune series: Entra join is the default, and hybrid is a position you should have to defend. A brand-new machine born in Microsoft’s cloud is the single best candidate for cloud-native identity you will ever get. It has no legacy, no GPO inheritance, no attachment to an organizational unit. Hybrid joining it means deliberately teaching a newborn cloud machine to depend on your domain controllers, and every one of those dependencies is a thing that can now break provisioning and sign-in.
Hybrid join also forces your networking decision, because a hybrid Cloud PC requires line of sight to a domain controller, which means it requires an Azure network connection. The legitimate case exists: line-of-business applications that authenticate against Active Directory in ways nobody is ready to rearchitect. When that is true, hybrid join is the honest answer. But it should be a documented exception with an exit plan, not the default you chose because the physical fleet works that way.
The network is the authority boundary
The starkest decision in the policy is the network, because it decides who owns the path your Cloud PCs take to everything. The Microsoft-hosted network means Microsoft owns it: the address space, the egress, the internet path, and the operational burden. You give up routing control and gain the strongest version of the operating model this whole series is about. An Azure network connection means you own it: the Cloud PC’s network interface is injected into your virtual network, in your subscription, and from that moment its traffic routes, its firewall traversal, its VPN or ExpressRoute path to on-premises, and its egress bill are yours.
Choose the Microsoft-hosted network until a specific resource forces your hand, and when it does, scope the ANC to the workloads that need it.
The two options coexist in one tenant, and that is the design I recommend: Microsoft-hosted as the default posture, an ANC for the population that genuinely needs private line of sight. If you do take on an ANC, take it on with open eyes, because it is real infrastructure with real failure modes. The service performs health checks against the connection every one to six hours, and since April 2026 an unreachable required endpoint fails those checks as an error that blocks new provisioning rather than a warning you could ignore. Plan the subnet at roughly one and a half times your maximum Cloud PC count, because provisioning, resizing, and service maintenance consume addresses transiently. Never bind firewall rules to a Cloud PC’s private IP, because the addresses are dynamic and change on reprovision and resize. And configure alternate ANCs in priority order, because a policy whose only ANC is unhealthy simply stops provisioning. None of this is exotic for a team that runs Azure networking; all of it is a standing cost that the Microsoft-hosted option makes disappear.
Images: the gallery is not the compromise, it is the design
The policy’s image field offers Microsoft’s gallery images or a custom image you build and maintain. The pull toward custom images is strong in organizations with a golden-image heritage, and I push back on it almost every time. A custom image is operational debt with a monthly interest payment: you now own its patch currency, its agent versions, its drift from the gallery baseline, and the staleness of every Cloud PC provisioned from it on a bad month. The cloud-native pattern this series has argued from the start is a lean source image with configuration and applications delivered by Intune after enrollment, because that machinery already exists, already runs on your physical fleet, and keeps a reprovisioned Cloud PC identical to a freshly provisioned one. Choose the gallery image with Microsoft 365 Apps included, let your baseline and app deployments do the rest, and reserve custom images for the narrow case where an application genuinely cannot be deployed post-provisioning.
Two smaller fields in the policy deserve deliberate answers rather than defaults. Enable Entra single sign-on, both for the daily experience and because purpose-built endpoints like Windows 365 Link refuse to connect without it. And treat the Windows Autopatch option in the policy as the update answer for the fleet, consistent with the position I took in the update phase of the Intune series: if you are licensed for Autopatch, letting the policy enroll Cloud PCs into it at birth is exactly the kind of decision-made-once that this platform rewards. Device naming, with its username and randomization macros, is a small thing that pays off every time a human reads a device list; name Cloud PCs so their nature is visible at a glance.
What you have at the end is a blueprint that encodes your authority decisions: cloud identity unless defended, Microsoft’s network unless forced, Microsoft’s image unless cornered, updates automated at provisioning. The next article is about what happens after the blueprint runs, when the fleet exists and the levers you reach for are restore, resize, and reprovision.
Windows 365
‹ Previous: [W365 2] Licensing and Sizing: The Four Variables and the Flex Question
Next: [W365 3.1] Building the Provisioning Policy ›
