This is the build companion to the deployment design article. The decisions were argued there; here we make them real, in the order the wizard asks and with the traps called out before you hit them.
One navigation note before anything else. Microsoft reorganized the Windows 365 experience in the Intune admin center in April 2026. The old Devices, Device onboarding, Windows 365 path is gone; everything now lives under Devices in a dedicated Manage Windows 365 Cloud PCs area, with provisioning policies, custom images, and Azure network connections grouped under Provision Cloud PCs. If your runbooks or muscle memory predate April 2026, update both. Nothing functional changed, but every path in this article uses the current structure.
Before the wizard: groups and a name that works for a living
Two things get decided before you open the portal. First, groups: create a dedicated Entra security group for provisioning policy assignment, separate from the group that assigns Windows 365 licenses. The licensing article covered why; the short version is that resize operations are license operations, and discrete groups turn a delicate sequencing exercise into a membership change. Name both to your convention so their purpose is legible in a group list.
Second, the policy name itself, and this deserves more thought than a name usually gets. The provisioning policy name is registered on every Cloud PC it creates as the device’s enrollmentProfileName property in Entra ID and Intune, and that property is the anchor for dynamic device groups and Conditional Access device filters downstream. A deliberate name like CPC-Standard-EastUS becomes infrastructure; a careless one becomes a string you are stuck matching on for years. The property is stamped at initial enrollment only, so renaming the policy later does not retroactively fix existing devices, and any dynamic group rules built on the old name must be updated by hand. Name it once, correctly.
The build
Sign in to the Intune admin center with the Intune Administrator or Windows 365 Administrator role, then go to Devices, Provision Cloud PCs, Provisioning policies, Create policy.
On the General page: enter the name you decided above. Select the license type; for this build that is Enterprise. You may still see Frontline in parts of the admin center where the Flex rename has not fully landed; they are the same thing. Choose the join type, Microsoft Entra join unless you documented the hybrid exception in your design, and the network, Microsoft hosted network with a geography and region near your users, or your Azure network connection if one exists and is healthy. Check the box for Microsoft Entra single sign-on. There is no defensible reason to leave SSO off in a new deployment, and purpose-built endpoints like Windows 365 Link will refuse to connect without it.
On the Image page: select Gallery image and pick the current Windows 11 Enterprise image with Microsoft 365 Apps. The design article made the argument; the wizard is where you hold the line against the custom-image reflex.
On the Configuration page: set the language and region pack. If you are licensed for Windows Autopatch, enable it here so every Cloud PC this policy creates is enrolled into managed updates at birth. Set the device name template using the macros, for example CPC-%USERNAME:5%-%RAND:5%. The randomization portion must be five to fifteen characters, and the name should make a Cloud PC recognizable as one in any device list. If you use Autopilot Device Preparation for Cloud PCs, still in preview as I write this, it attaches here as well.
Assign scope tags if your RBAC design uses them, then on the Assignments page select the dedicated provisioning group and create the policy. From the moment a licensed user lands in that group, provisioning starts on its own; there is no provision button, which is exactly the point.
A user in two provisioning policies gets the first one, silently. Non-overlapping targeting is not a style preference; it is the only way the fleet’s configuration stays deterministic.
What edits do and do not do
Understand the change model before you rely on it, because it surprises people in both directions. Editing a policy’s network, image, region, or single sign-on setting changes nothing on Cloud PCs that already exist; only newly provisioned or reprovisioned machines honor the new values. For network, region, and SSO changes there is an apply-current-configuration action that pushes the new settings onto existing devices without a rebuild; an image change, by contrast, only ever reaches existing machines through reprovisioning, which destroys them. And removing users from the assignment group has teeth: Enterprise Cloud PCs enter their grace period, and Flex dedicated machines are deprovisioned immediately. Treat assignment group membership with the same care as the license group, because in this platform, group membership is provisioning.
That is the whole build. The policy is small because the design work happened before the wizard opened, which is how it should be. If your deployment needs the bring-your-own-network path, the Azure network connection build is the companion piece to this one.
Windows 365
‹ Previous: [W365 3] Designing the Enterprise Deployment
Next: [W365 3.2] Building the Azure Network Connection ›
