What you'll learn
What the Automatic mode of a device preparation policy solves for Windows 365 (the benefits)
The supported Windows 365 SKUs and the prerequisites
The end-to-end flow: create the Entra group → assign apps/scripts → create the device preparation policy → create the provisioning policy
How to monitor provisioning, and the pitfalls that trip people up
Written as of: September 2026 Assumptions: A tenant with Windows 365 Enterprise / Flex (formerly Frontline) licenses and Microsoft Intune
What a device preparation policy in Automatic mode is
It's a form of Windows Autopilot device preparation (commonly known as Autopilot v2), and it's a dedicated policy that you link to a Windows 365 provisioning policy. By including the device preparation policy in the provisioning policy, you guarantee that the essential Intune apps and scripts are installed on the Cloud PC before the user signs in.
The SKUs you can provision in automatic mode are:
Windows 365 Flex in shared mode
Windows 365 Enterprise
Windows 365 Flex in dedicated mode
Windows 365 Cloud Apps
Benefits
1. The Cloud PC is "ready for productive use" the moment the user first signs in
Traditionally, a Cloud PC is marked Provisioned as soon as Intune enrollment finishes, and users can connect from that point. App delivery runs afterward, so right after the first sign-in the Cloud PC often has neither Teams nor the line-of-business apps installed yet.
With a device preparation policy, Windows 365 waits to complete provisioning until the specified apps and scripts have finished installing.
2. You're freed from building and maintaining custom images
Building your own "custom image with the required apps preinstalled" and keeping it updated piles up cost: image versioning, applying updates, and re-validating. A device preparation policy keeps the standard configuration of a gallery image plus Intune app delivery, while reducing the management overhead that comes with custom images.
3. You can choose not to hand a failed Cloud PC to the user
If you enable Prevent users from connection to Cloud PC upon installation failure or timeout in the provisioning policy, a Cloud PC that fails preparation is marked Failed and users can't connect to it. If you leave it unselected, the Cloud PC is marked Provisioned with warnings and users can connect. The key point is that you get to decide, as an operational policy, whether to hand out a half-configured device or block it.
4. Near real-time visibility at the individual app and script level
In automatic mode, Cloud PC setup happens in the background, so you can't "watch" it on screen. Instead, the Windows Autopilot device preparation deployments report lets you track the deployment status, phase, and deployment time per device, and even the status of each individual app and script (Installed / In progress / Skipped / Failed). Isolating "why is this one device missing its apps?" gets dramatically faster.
5. Enrollment Time Grouping makes delivery fast and reliable
The device is added to a predefined device security group at the moment of enrollment, and the configuration is delivered immediately. Compared with the traditional approach of waiting for dynamic group membership to be evaluated, apps, scripts, and policies are delivered more quickly and efficiently.
6. Assignment management is simpler
A device preparation policy in automatic mode has no Assignments page. Assignment is handled when you create the Cloud PC provisioning policy, so there's no double management of "which group do I target this policy at?"
Overall workflow
| # | Where | What |
|---|---|---|
| 1 | Azure portal (Entra ID) | Set up Windows automatic Intune enrollment (MDM user scope) |
| 2 | Intune admin center (Groups) | Create an assigned security device group and set Intune Provisioning Client as the owner |
| 3 | Intune admin center (Apps / Scripts) | Assign the apps and PowerShell scripts you want to deliver to the device group from step 2 |
| 4 | Intune admin center (Enrollment) | Create the device preparation policy with Automatic and specify the apps/scripts |
| 5 | Intune admin center (Windows 365) | Select the policy from step 4 in the Cloud PC provisioning policy |
| 6 | Intune admin center (Monitor) | Monitor the deployment status |
[Step 1] Set up Windows automatic Intune enrollment
If automatic Intune enrollment is already set up, skip this step and move on to step 2.
Sign in to the Azure portal and select Microsoft Entra ID
Under Manage in the left hand pane, select Mobility (MDM and WIP)
Under Name, select Microsoft Intune
Under MDM user scope, select either All or Some
* If you select **Some**, specify the target Entra **user** groups from the link under **Groups**
- Select Save
[Step 2] Create an assigned device group
Dynamic groups can't be used.
Sign in to the Microsoft Intune admin center
In the left hand pane, select Groups → All groups → New group
Configure it as follows
| Setting | Value |
|---|---|
| Group type | Security |
| Group name | e.g. Windows Autopilot device preparation device group
|
| Group description | Optional |
| Microsoft Entra roles can be assigned to the group | No |
| Membership type | Assigned |
| Owners |
Intune Provisioning Client (AppId: f1346770-5b25-470b-88bd-d5744ab7952c) |
| Members | None |
- Select Create
Important
The group specified in the device preparation policy needs to be an assigned security device group. Dynamic groups aren't used.
In some tenants, the service principal is displayed as Intune Autopilot ConfidentialClient. As long as the AppId is
f1346770-5b25-470b-88bd-d5744ab7952c, it's the correct service principal.Cloud PCs are automatically added to this group during the deployment. Adding them manually isn't necessary.
Microsoft recommends using separate device groups for user-driven scenarios and automatic scenarios. :::
If you can't find Intune Provisioning Client
If it appears neither in the list nor in search results, add it with PowerShell.
Install-Module Microsoft.Graph.Authentication
Install-Module Microsoft.Graph.Applications
Connect-MgGraph -Scopes "Application.ReadWrite.All"
New-MgServicePrincipal -AppID f1346770-5b25-470b-88bd-d5744ab7952c
[Step 3] Assign applications and PowerShell scripts to the device group
During OOBE (that is, while no user is signed in), you can deploy up to:
25 managed applications
10 PowerShell scripts
The official tutorial's "Step 3" and the overview page state 25 apps / 10 scripts, while the "Step 4 (create the policy)" page states up to 10 apps, so the numbers differ between articles. Check the admin center UI for the actual limit.
Supported application types:
Line-of-business (LOB)
Win32
Microsoft Store (only apps that support WinGet)
Microsoft 365
Enterprise App Catalog
Assigning applications
Intune admin center → Apps → Windows
Select the target app → Properties → Edit next to Assignments
Under the Required section, select Add group → select the device group from step 2
Verify that Group mode is set to Included
When applicable, verify that Install Context is set to Device context (so the app installs in the System context)
Select Review + save → Save
Assigning PowerShell scripts
Intune admin center → Devices → Scripts and remediations → Platform scripts
Select the target script → Properties → Edit next to Assignments
Add the device group from step 2 under Included groups (also make sure it isn't listed under Excluded groups)
Select Review + save → Save
Because no user is signed in during OOBE, applications must be configured to install in the System context. A PowerShell script runs in the System context when you set Run this script using the logged on credentials to No in its properties.
[Step 4] Create the device preparation policy in Automatic mode
Intune admin center → Devices → under By platform, select Windows
Under Device onboarding, select Enrollment
Under Windows Autopilot device preparation, select Device preparation policies
Select Create → Automatic
Introduction page: select Next
Basics page: enter a name and description → Next
Device group page: search for and select the device group created in step 2 → Next
-
Configuration settings page:
Apps section → Add → select the essential apps → Save (they appear under Allowed applications)
Scripts section → Add → select the essential scripts → Save (they appear under Allowed scripts)
Scope tags page: specify if needed (optional) → Next
- Review + create page: review the settings and select Save
Unlike user-driven mode, a policy in automatic mode has no deployment settings or OOBE settings sections, and no Assignments page. Assignment is handled in step 5 (the provisioning policy).
Also, the apps and scripts you select here must already be assigned to the device security group from step 2.
[Step 5] Create the Cloud PC provisioning policy
Intune admin center → Devices → Cloud PC provisioning
Provisioning policies → Create policy
General page
* Enter a name and description
* **Experience**: Access a full Cloud PC desktop
* **License type**: select the SKU you're using
* **Join type**: Microsoft Entra Join or Hybrid Microsoft Entra Join
* **Network**: Microsoft hosted network or Azure network connection
* Select **Geography** / **Region**, and enable **Use Microsoft Entra single sign-on** if needed
Image page: select the image you want
Configuration page
* Select **Language & Region**
* Configure **Apply device name template** if needed
* Under **Windows Autopilot**:
* For **Autopilot device preparation policy**, select the policy from step 4
* For **Minutes allowed before device preparation fails**, enter a value between **30 and 360 minutes** (**minimum 30 minutes**, e.g. 60)
* Select **Prevent users from connection to Cloud PC upon installation failure or timeout** if needed
Scope tags page: optional
Assignments page
* Select **Add groups** and choose the target user group
Review + create → Create
Intune admin center → Devices → All Cloud PCs, and wait for the Cloud PC to be provisioned.
Once the Cloud PC is provisioned, connect to it and verify that the apps and scripts configured in the Autopilot device preparation policy are installed.
Monitor the deployment
Monitoring is done in the admin center.
Status per Cloud PC
Check the Status column under Devices → All Cloud PCs.
| Status | Meaning |
|---|---|
| Provisioning | The Cloud PC is being created and isn't ready for use yet |
| Preparing | Device preparation configuration is underway; not ready for use yet |
| Provisioned | Completed successfully and ready to use |
| Failed | The connection-blocking option is enabled and preparation failed, so it can't be used |
| Provisioned with warnings | Provisioning succeeded but some configuration failed; the Cloud PC can still be used |
Per-app and per-script details
Open Devices → Monitor → Windows Autopilot device preparation deployments in the list of reports.
Information shown: Device name / Enrollment date / Deployment status (In progress, Success, Failed) / Phase (Policy installation, Script installation, App installation) / Serial number / Deployment time / UPN
Below is an example of a failed deployment.
Selecting a device name opens Device deployment details, which lists the apps and scripts with their individual statuses, in addition to device information (Intune device ID, Entra device ID, deployment policy and policy version, OS version).
| Status | Meaning |
|---|---|
| Installed | Installed / ran successfully |
| In progress | Currently running |
| Skipped | Selected in the policy, but not assigned to the device group specified in the policy (or not applicable to the device) |
| Failed | Installation / execution failed. Check the logs |
Checklist recap
The device group is dynamic → it won't work unless it's an Assigned security group.
Intune Provisioning Client isn't set as the group owner, or was removed later → security group membership updates can fail and the device can fall out of compliance. Changing the group from static to dynamic after configuring the policy, or deleting the group, are also causes of failure.
The apps/scripts aren't assigned to the device group → they're reported as Skipped. Selecting them in the policy alone doesn't deliver them.
The script is still running in the user context → set Run this script using the logged on credentials to No.
Top comments (0)