Skip to main content
Get a demo Try it free

G2 Names Nerdio a Leader Across Fall 2026 Reports for Desktop as a Service Read the blog

Blog

How to automate Windows 365 provisioning

Learn how to automate Windows 365 provisioning with policy, group, image, and scripting design for enterprise Cloud PCs.

Table of Contents

In Windows 365, Microsoft automatically provisions Cloud PCs the moment a licensed user lands in a group assigned to a provisioning policy (per Microsoft's  provisioning documentation).

Automating Windows 365 provisioning means designing policy architecture and the supporting group, image, and scripting model around that trigger so 500 Cloud PCs arrive configured correctly without a group-rule mistake silently starting a grace period.

This guide is for IT teams and Windows 365 administrators designing Cloud PC provisioning at enterprise scale.

The trigger is license plus group plus policy

Microsoft's device management documentation states: "When a user is licensed with a Windows 365 license, a new row is automatically created in the All Cloud PCs list. If the user also has a provisioning policy assigned to them, a Cloud PC is automatically provisioned." Windows 365 also provisions Cloud PCs when admins add users to an assigned group after policy creation. Group membership is the deployment interface because provisioning has no deploy button.

The automated flow runs in three stages:

  • Core provisioning builds the Cloud PC from the policy's image and network settings.
  • Post-provisioning configuration applies settings such as Windows Autopilot device preparation.
  • Assignment then connects the finished Cloud PC to its user.

Two rules shape everything downstream. When multiple policies target the same user, "the Windows 365 service always uses the first assigned policy to provision the Cloud PC," per Microsoft's documentation. When a user loses either the license or the policy assignment, a seven-day grace period starts. After it expires, Windows 365 signs the user out and removes access.

Operationally, these rules make policy order and group membership hygiene part of the provisioning design instead of cleanup work after the fact.

For Windows 365 Enterprise, each user needs Windows E3 or E5, Microsoft Intune, Microsoft Entra ID P1, and a Windows 365 license. Both Windows 365 and Azure Virtual Desktop sit under Windows Cloud, Microsoft's umbrella term for its cloud desktop portfolio. Many enterprise customers use both Microsoft products together, with each serving different workload needs.

Because the trigger fires on its own, the provisioning policy's network and image are hard to reverse.

The policy decisions every Cloud PC inherits

A provisioning policy binds assigned Entra ID groups to a network, which dictates join type, and an image. Network and image deserve the most scrutiny because changing them later does nothing for Cloud PCs already provisioned.

Join type and network

Microsoft recommends Microsoft-hosted networks for many new Windows 365 deployments: a fully managed virtual network with no Azure subscription required. An Azure network connection (ANC) is appropriate only for a requirement a Microsoft-hosted network can't meet, such as Microsoft Entra hybrid join, direct network-level connectivity to on-premises resources, or customer-managed network controls on the Cloud PC subnet.

Hybrid join requires the ANC path; Microsoft-hosted networks do not support it, and policy creation with hybrid join can take up to 60 minutes.

For ANCs, IP space planning comes before anything else. Microsoft's network connectivity guidance recommends allocating twice your maximum Cloud PC count and keeping at least 50% free for disaster recovery scenarios where every Cloud PC may need reprovisioning. That headroom is most important during reprovisioning events, when failed retries can consume addresses faster than capacity plans assume.

Microsoft also positions hybrid join as a transitional identity model and recommends Microsoft Entra join for new deployments, with Group Policy settings migrated to Intune.

Gallery versus custom images

Gallery images ship with Microsoft 365 Apps, Teams, and preset policies. Microsoft replicates them to all Azure regions and updates them monthly.

Custom images buy you preinstalled line-of-business apps and specific baselines at the cost of a validation pipeline (Windows 365 copies the image to a temporary subscription, boots a test VM, then replicates it) plus ongoing maintenance. Microsoft made custom images from Azure Compute Gallery generally available the week of February 9, 2026, and removed Windows 10 gallery images for new provisioning policies starting October 14, 2025.

Editing a policy's network, image, region, or single sign-on configuration changes nothing for existing Cloud PCs. Only newly provisioned or reprovisioned Cloud PCs honor the change, and reprovisioning wipes user data and apps. At scale, teams centralize image work. Nerdio Manager for Enterprise handles golden image creation, updates, and distribution for Cloud PCs and Azure Virtual Desktop session hosts through a shared workflow.

Join type, network, and image are effectively locked in per policy. That makes group design, the mechanism that decides who gets which policy, the part of the system you'll actually operate day-to-day.

Assignment automation with groups and licensing

Microsoft documents two assignment models in their provisioning documentation (previously cited):

  • The discrete model, which Microsoft prefers, uses a dedicated group created specifically for a provisioning policy, useful when departments need distinct configurations.
  • The hybrid model assigns the policy directly to the group-based licensing group, which suits smaller deployments with little expected change.

Dynamic Entra ID groups can scale assignment across Cloud PCs. A dynamic device group with the rule deviceModel Starts With Cloud PC captures every Cloud PC in the tenant. Provisioning policy names register as each device's enrollmentProfileName at initial enrollment, so a rule of enrollmentProfileName Equals your policy name scopes Intune targeting per policy.

Policy renames require a matching update to the dynamic rule, because Windows 365 sets enrollmentProfileName only at enrollment.

Dynamic membership cuts both ways. Because it is rules-based, a changed user attribute can silently remove someone from the license group or the policy assignment, which starts the same seven-day grace period and ends in deprovisioning. Microsoft also warns that if a group contains more users than available licenses, some users may never receive an assignment.

On the positive side, Windows 365 now validates both source license removal and target license assignment before triggering a group-based licensing resize, so a mid-transition policy change fails gracefully instead of reprovisioning by accident.

Policy creation with Graph and PowerShell

Microsoft Graph exposes the cloudPcProvisioningPolicy resource in v1.0 at /deviceManagement/virtualEndpoint/provisioningPolicies, with list, get, create, update, delete, and assign operations available through the Graph provisioning policy resource. A handful of properties define most of what a policy actually does.

Property

What it controls

imageId

The gallery or custom image the Cloud PC boots from

imageType

Whether the policy uses a gallery or custom image

provisioningType

Assignment model, dedicated or shared

enableSingleSignOn

Whether Cloud PCs sign in with SSO

localAdminEnabled

Whether the primary user gets local admin rights

 

For REST-based assignment, you post a group assignment target with a groupId to the policy's assign endpoint.

PowerShell wraps the same API. New-MgBetaDeviceManagementVirtualEndpointProvisioningPolicy creates policies from the beta module, and Cloud PC operations run under the CloudPC.ReadWrite.All scope.

Community practitioners Paul Winstanley (SCCMentor) and Niall Brady have published working scripts that discover SKU IDs with Get-MgSubscribedSku, check existing assignments, and assign Windows 365 licenses through Graph. Wire those scripts to an HR or ITSM system so license assignment, the actual provisioning trigger, becomes event-driven.

Graph automation has boundaries worth planning around. Some capabilities live only in Graph beta, including autopilotConfiguration and the cloudPcNamingTemplate property, so stable v1.0 automation can't set them yet. Microsoft states the API "performs the same operations as those available through Microsoft Endpoint Manager," which means anything missing from the Intune portal is missing from Graph too. Rate limits also apply, with the List Cloud PCs API allowing 180 requests per minute per tenant.

Scripting gets the Cloud PC created. Getting it ready before the first sign-in is a separate provisioning-time decision.

Pre-first-sign-in configuration with Autopilot device preparation

An Autopilot device preparation policy, which you select in the Configuration tab of the Cloud PC provisioning policy, installs apps and scripts on the Cloud PC before any user signs in.

On January 30, 2026, Microsoft raised the app limit to 25 per policy. The limit applies to all Cloud PC offerings, and a policy can include up to 10 scripts. Microsoft recommends reviewing deployment timeout settings so larger app sets don't time out. Automatic mode for Cloud PCs entered public preview on November 21, 2025. The preview covers Windows 365 Enterprise, Flex (previously Frontline) dedicated mode, and Windows 365 Cloud Apps.

Autopilot device preparation is the answer for shared-mode Cloud PCs, where sessions reset between users and nothing a user installs persists. Device preparation installs the required app set before sign-in, so the first agent to sign in on a shift finds the required apps already installed.

SKU differences: Enterprise, Flex, and Reserve

Windows 365 Enterprise licenses are per-user, and each user can hold one Cloud PC per Enterprise SKU. Windows 365 Flex (formerly Windows 365 Frontline) works differently. Licenses are pooled at the tenant level rather than assigned to individuals. Dedicated mode gives one user a persistent Cloud PC on a shared license pool; shared mode lets a group of users take turns on one license, with the session reset and no user data retained at each logout. Shared mode also requires a single Azure region in the policy; multi-region selection isn't available for that SKU.

Because Flex ties the Cloud PC size and license into the provisioning policy itself, Flex deployments have to use a single-group model. Microsoft's proven-practice guidance suggests adopting the single-group model for Enterprise too if you want one consistent pattern, and creating empty, policy-aligned groups before you create any policies.

Windows 365 Reserve, launched December 2025, adds a continuity SKU: up to 10 days of Cloud PC access per user per year, with tenant-level licenses assigned through provisioning policies, and user-initiated provisioning in public preview since April 28, 2026.

Where provisioning depends on adjacent systems

Windows 365 blocks provisioning if the associated ANC is unhealthy. In April 2026, required-endpoint failures began returning an Error instead of a Warning. Windows 365 stops new Cloud PC provisioning until admins resolve the endpoint issue. Additionally, VNets created after March 31, 2026 default to private subnets, so Cloud PC provisioning fails unless admins explicitly configure outbound internet access.

ANC health check retries require a manual, role-gated action; Microsoft has not documented an automation path.

Hybrid identity adds a timing dependency. Microsoft Entra Connect must sync AD computer objects every 30 to 60 minutes. Provisioning times out if the Entra object doesn't appear within 90 minutes. IP exhaustion compounds the timing dependency. Failed provisioning can retry three times, and each retry can hold addresses for hours.

Portal sprawl adds another operational layer. Admins jump between three surfaces to run one provisioning stack. License inventory lives in the Microsoft 365 admin center, provisioning policies live in Intune, and ANC configuration lives in the Azure portal. Each surface carries its own role requirements, and creating an ANC needs Azure subscription roles on top of the Intune Administrator or Windows 365 Administrator role.

Any image update to existing Cloud PCs still requires reprovisioning, so the operational tax compounds every time the fleet needs a refresh.

What Nerdio Manager adds on top of native provisioning

Nerdio Manager sits inside your Azure tenant as an automation and management layer for Windows 365, Intune, and Azure Virtual Desktop, with one console across all three.

Provisioning and desktop orchestration

For provisioning, Nerdio Manager extends Windows 365 Cloud PC lifecycle management beyond Intune from the same console used for Microsoft Intune and Azure Virtual Desktop. That keeps Cloud PC management, Intune dependencies, and post-provisioning operations tied to the Windows 365 workflow instead of splitting the work across handoffs. Desktop orchestration applies the centralized image workflow described earlier across both Cloud PCs and session hosts, so image operations stay aligned across Windows Cloud environments.

Intune policy control and application delivery

On the Intune side, Nerdio Manager extends native Intune policy management with backup and restore for deleted policies. Policy baselines group related Intune policies into standardized sets that admins can apply with a single click. For post-provisioning app delivery, Unified Application Management deploys applications to Cloud PCs in approximately 30 seconds, where native Intune delivery can take up to 3 hours, and it auto-patches third-party software such as Adobe Acrobat and Google Chrome through WinGet integration.

Right-sizing with Nerdio Advisor

For right-sizing, Nerdio Advisor analyzes historical performance data to flag oversized and undersized Cloud PCs, surfaces underutilized licenses for reclamation, and identifies users eligible for Flex license conversion. It surfaces resizing recommendations so admins can move Cloud PCs toward a more cost-effective SKU.

Across Windows Cloud, Nerdio Manager covers both paths: Windows 365 Cloud PCs and Azure Virtual Desktop session hosts. Since Nerdio Manager 7.6 features, it also extends to cross-tenant Intune and Windows 365 management for teams that operate more than one tenant. It supports migration paths that include Azure Virtual Desktop to Windows 365 and legacy virtual desktop infrastructure (VDI) to either desktop type, so admins can move users without rebuilding the management model around each desktop type.

Decision order before your first policy

The design work typically follows this sequence so nothing gets locked in by accident.

  1. Identity and join type (Entra join unless a hard requirement forces hybrid)
  2. Network (Microsoft-hosted by default; ANC with 2x IP headroom if required)
  3. Image strategy (gallery unless line-of-business apps demand custom)
  4. Group and naming structure (empty, policy-aligned groups created first)
  5. SKU segmentation (Enterprise, Flex dedicated, Flex shared, Reserve)
  6. Management approach (native portals and scripts, with Nerdio Manager as the automation layer across Windows 365, Intune, and Azure Virtual Desktop)

The automatic trigger makes the sequence matter. It can route users to the correct policy, provision 500 configured Cloud PCs, or trigger unintended reprovisioning and grace periods when design choices drift.

If your provisioning design is solid but the day-two work of images, Intune policies, and license right-sizing is eating your team's week, that's the layer worth automating next. Get a demo to see how Nerdio Manager works across your Windows 365 and Azure Virtual Desktop environment, or try it free in your Azure tenant.

Frequently asked questions about how to automate Windows 365 provisioning

Resources

Learn more about Nerdio Manager

Ready to get started?

Get a demo Try it free