Windows 365 Enterprise provisioning is orchestrated through Microsoft Intune. For MD-102 administrators, a provisioning policy ties together the Cloud PC network, Windows image, configuration, and Microsoft Entra user-group assignment. Provisioning then depends on a valid Windows 365 license, healthy networking, successful Intune enrollment, and enough capacity or address space for the selected design.
Microsoft’s September 2026 deployment guidance recommends Microsoft Hosted Network as the simpler default for most organizations and positions Azure Network Connection (ANC) for specialized requirements such as direct access to existing Azure virtual networks or legacy network dependencies. That makes network choice the first major provisioning decision, not a detail added after the image is selected.
A provisioning policy is the blueprint for new Cloud PCs
Windows 365 provisioning policies are created in the Microsoft Intune admin center and define how Cloud PCs are created for assigned users. Required choices include network, image, configuration settings, and assignment to Microsoft Entra user groups. When an eligible licensed user enters the assignment scope, Windows 365 can begin provisioning according to that policy.
Treat the policy as a lifecycle object rather than a one-time wizard. Name policies by network, image family, region, and business purpose so operators can understand the effect of an assignment without opening every property. Keep change history for image and network decisions because a later reprovision can apply a different configuration than the one used to create the original Cloud PC. Changes to assignments affect who receives Cloud PCs, while changes to network, image, region, or single sign-on generally affect newly provisioned or reprovisioned Cloud PCs rather than silently rebuilding existing ones. Administrators should understand which edits are forward-looking and which require reprovisioning.
Microsoft Hosted Network is the recommended default
Microsoft Hosted Network lets Microsoft manage the Cloud PC network and is the simplest choice when users primarily need internet and Microsoft 365 access or can reach private resources through higher-layer access technologies. It avoids the Azure virtual-network permissions and subnet-capacity management required by an ANC.
Even with Microsoft Hosted Network, endpoint connectivity still matters. Microsoft’s current guidance calls MHN the recommended deployment option for most scenarios because Microsoft operates the network path, but local endpoint networks still carry the remote session. Test home networks, office proxies, secure web gateways, and regional latency with representative users before standardizing the design. Secure web gateways, VPN clients, firewalls, proxies, and TLS inspection can degrade the RDP path if Windows 365 service traffic is not routed or optimized correctly. Validate endpoint reachability and RDP behavior during pilot deployments rather than assuming a Microsoft-managed network removes all network dependencies.
Azure Network Connection supports custom network requirements
An Azure Network Connection connects Windows 365 provisioning to an Azure virtual network controlled by the organization. This is useful when Cloud PCs must use custom DNS, route through existing Azure network appliances, access private resources directly, or participate in a network design that cannot be met by Microsoft Hosted Network.
ANC introduces more dependencies: Azure subscription permissions, virtual-network and subnet configuration, DNS, routes, firewall rules, domain connectivity for hybrid scenarios, and subnet IP capacity. Plan address space for growth and failed or pending provisioning. A subnet that is nearly exhausted can turn routine user assignment into an unexpected provisioning incident even when the ANC health check was previously green. Microsoft runs health checks against the ANC, and administrators should treat failed checks as provisioning blockers rather than repeatedly retrying Cloud PC creation.
Gallery images reduce image-management overhead
Windows 365 provides gallery images maintained by Microsoft, including options with Microsoft 365 Apps. Microsoft updates gallery images regularly with current security and optimization changes, which reduces the organization’s responsibility for image patching and maintenance before provisioning.
Use a gallery image unless the business needs custom software or configuration that genuinely belongs in the base image. Gallery images are updated regularly by Microsoft and reduce the risk that a stale custom image enters provisioning with old security patches. Keep security baselines and most business applications in Intune where possible so image maintenance remains small. Many endpoint settings and applications can be delivered through Intune after provisioning, which keeps the image smaller and reduces image lifecycle work.
Custom images are appropriate for stable base requirements
Custom device images can be uploaded for Windows 365 when an organization needs approved base applications, language, or operating-system customization that should exist before the Cloud PC is delivered. Current Windows 365 requirements use supported Windows Enterprise images and newly created custom images are expected to be Generation 2.
Keep custom images generalized and clean: they must not already be joined to Active Directory or Microsoft Entra ID, Intune-enrolled, or co-managed. Current Windows 365 custom-image guidance also requires supported Windows Enterprise and Generation 2 image characteristics. Build images through a repeatable process, retain version metadata, and test new image versions with a pilot provisioning policy before broad use. they must not already be joined to Active Directory or Microsoft Entra ID, Intune-enrolled, or co-managed. Version images and test them before assigning them to a provisioning policy. A large, heavily customized image can lengthen provisioning and create more patching and compatibility work than using Intune application deployment.
Assignment and licensing determine who is provisioned
Provisioning policies are assigned to Microsoft Entra user groups, but assignment alone is not enough. Users also need the appropriate Windows 365 license. Troubleshooting should therefore confirm group membership, license assignment, provisioning-policy scope, and whether another policy creates an unintended overlap.
Keep Cloud PC assignment groups understandable. Also review license assignment automation. If a user leaves the target group but retains a license, or receives a license without the intended provisioning policy, operational teams need a defined deprovisioning or reassignment process. Cloud PC lifecycle should follow identity lifecycle rather than rely on manual cleanup. Dynamic groups can automate provisioning but should use attributes whose ownership and update timing are reliable. A bad dynamic rule can create unexpected Cloud PCs and cost, while an overly complex nested group structure can make it difficult to explain why a user is or is not targeted.
Intune enrollment turns the Cloud PC into a managed endpoint
After provisioning, the Cloud PC is enrolled in Microsoft Intune and receives endpoint configuration, compliance, applications, security baselines, update policy, and other assignments. Provisioning success therefore should include successful Intune management, not merely the creation of a virtual machine.
Review the Cloud PC as part of the same endpoint-management estate as physical Windows devices while accounting for Windows 365-specific network and lifecycle actions. Apply update rings, compliance, Defender, application assignment, configuration, and Conditional Access consistently where appropriate. Use Cloud PC-specific filters or groups only when the virtual endpoint genuinely needs different policy. Conditional Access, Defender, configuration policy, app deployment, and compliance can all participate in the steady-state management model after provisioning.
Provisioning failures should be diagnosed by dependency
Common failure areas include license, provisioning-policy assignment, image compatibility, Intune enrollment restrictions, ANC health, network reachability, Azure permissions, subnet capacity, DNS, and policy conflict. Use the provisioning error code and health-check result as evidence. If an ANC is involved, Microsoft periodically rechecks it; a later failure can reveal environmental drift that did not exist when the connection was first created. Microsoft’s Windows 365 error guidance should be used with the exact provisioning status rather than treating every failure as a generic Intune issue.
For ANC deployments, verify health checks and available IP addresses before reprovisioning. For custom images, validate image state and current requirements. For policy assignment, verify the target group and user license. Reprovisioning destroys and recreates the Cloud PC, so use it as a controlled recovery action rather than the first troubleshooting step.
Operate Cloud PC provisioning as a measured service
Track provisioning duration, failure rate, image version, network type, user assignment, license status, and the reason for reprovisioning. Add user-experience signals such as connection latency and help-desk contacts so architecture teams can tell whether a technically successful Cloud PC is actually usable. Provisioning quality should include the user’s first productive session, not just resource creation. These metrics reveal whether one ANC, custom image, policy, or application set is responsible for repeated failures.
Standardize a small set of supported provisioning policies and document when Microsoft Hosted Network, ANC, gallery image, and custom image are permitted. Windows 365 works best when the provisioning policy expresses an intentional endpoint architecture and Intune takes over a predictable steady-state management lifecycle.
Provisioning operations also need a clear recovery model. A failed Cloud PC can sometimes be corrected by fixing license, group assignment, ANC health, or Intune policy and retrying, while other changes require reprovisioning. Document which actions preserve the user’s Cloud PC and which destroy and recreate it. Before reprovisioning, confirm data-location and user-profile implications so support teams do not solve a management problem by unexpectedly discarding user state.
Use Windows 365 health and provisioning status as service telemetry. Track failures by policy, network type, image version, region, and error category. If one ANC or custom image produces a disproportionate share of failures, stop new provisioning against that dependency and correct the underlying issue. This turns Cloud PC provisioning into a measurable service rather than a series of one-off help-desk cases.