Provisioning Cloud PCs at Scale

Intune had never managed a virtual device the way it managed a physical one. Remote desktops existed before Windows 365, but as separate infrastructure with their own setup and tooling — not something that showed up in Intune’s own device list next to a laptop. Windows 365 changed that: Cloud PCs would be first-class Intune devices, governed by the same policies, compliance checks, and update rings as physical hardware, side by side in one console.

That integration was the whole selling point, but it exposed two problems Intune’s admin model had never had to solve. First, state: a physical device is either enrolled or it isn’t — a Cloud PC has to be created before it can be managed at all, and it moves through its own lifecycle on the way there, a dimension of state physical devices never needed. Second, scale: a physical device gets set up one at a time, by design. Cloud PCs couldn’t work that way — a single policy could need to bring a thousand of them online at once, and provisioning had to be designed for that from the start, not retrofitted onto a one-device-at-a-time model.

The first real finding was that a Windows 365 license is a per-user construct, the same as any other Microsoft 365 license — but provisioning couldn’t be a per-user operation if it needed to scale. The pattern that emerged was translating that individual license into a group-level operation: a policy targets a Microsoft Entra group, not a person, and Cloud PCs get created automatically for whoever is a licensed member. Scale stopped meaning “an admin repeats this workflow a thousand times” and started meaning “the system reacts to group membership.”

The second finding was that state needed its own vocabulary. A Cloud PC that’s mid-creation, one that provisioned with a warning, one sitting in a grace period after its user left the group — none of that mapped onto how Intune already talked about physical devices. I had to help define not just the screens, but the state model itself: what admins actually needed to know and act on at each stage of a Cloud PC’s life, working closely with engineering to get there.

The obvious starting point was the model Intune already had for physical devices: one admin, one device, one setup flow.

A provisioning policy targets a group and carries the settings that scale with it — region, image, naming convention, language — so admins configure once per policy, not once per Cloud PC. Individual customization still had a place: device naming templates and per-user settings meant the system could scale by group while a Cloud PC (and the person using it) still felt configured for them, not mass-produced.

Guided scenarios shipped on top of this foundation — Windows 365 Boot, for instance, walks an admin through letting end users sign directly into their Cloud PC from a physical device, extending the life of aging hardware instead of replacing it. But the wizard was the visible layer; the group-and-state model underneath is what let it, and everything that came after, actually scale.

Each state earned its place by answering one question — has this Cloud PC finished becoming a real, usable thing — not by borrowing Intune’s existing enrolled/not-enrolled vocabulary, which couldn’t tell an admin that.

Shipped Windows 365 provisioning experiences, published by Microsoft — techcommunity.microsoft.com/windows-365-cloud-pc-provisioning-scenarios and windows-365-frontline-cloud-pc-in-shared-mode-quick-start-guide. Reference for the shipped admin surfaces.

Designing a genuinely new state model, instead of stretching Intune’s existing physical-device states to cover Cloud PCs too, cost more time working with engineering to define what each state meant and when it applied. Reusing existing states would have shipped faster, but it would have told an admin a Cloud PC was “enrolled” when what they actually needed to know was whether it had finished being created in the first place — a different question a reused vocabulary couldn’t answer.