Build 1 publisher2 min readPublished September 13, 2026 at 10:16 PM PDT

Windows 365 flags a Cloud PC Provisioned before Intune has installed Teams

A device preparation policy in automatic mode holds provisioning open until the named apps and scripts install, with one provisioning-policy checkbox deciding whether a Cloud PC that fails preparation still reaches its user.

The Engineer · Build desk

Illustration accompanying Windows 365 flags a Cloud PC Provisioned before Intune has installed Teams

What happened

Windows 365 has traditionally marked a Cloud PC Provisioned as soon as Intune enrollment finishes, letting users connect from that moment while app delivery continues in the background.
The result at first sign-in is a Cloud PC that often has neither Teams nor the line-of-business apps installed yet.
A device preparation policy linked from the provisioning policy holds provisioning open until the specified Intune apps and scripts have finished installing, before the user signs in.
Automatic mode is limited to four SKUs: Windows 365 Enterprise, Flex in shared mode, Flex in dedicated mode, and Cloud Apps.
The Windows Autopilot device preparation deployments report carries per-device status, phase and deployment time, plus each app and script as Installed, In progress, Skipped or Failed.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

cost The alternative that fleets already run, a custom image with the apps baked in, costs the platform team image versioning, update application and re-validation on every release; this path leaves the gallery image alone and moves that work to Intune app delivery.
decision Blocking a Cloud PC that fails preparation turns an app-install failure into a user with no desktop at all; releasing it turns the same failure into a ticket about missing Teams.
constraint Tenants whose device grouping is entirely dynamic cannot reuse it here: this needs a fresh assigned security device group, and whatever policies target that group now apply to Cloud PCs the service adds on its own.
capability A helpdesk chasing one Cloud PC out of a batch can now name the app that failed instead of reimaging and hoping.

A September 2026 walkthrough on dev.to documents the supported path. The device preparation policy is a form of Windows Autopilot device preparation, commonly called Autopilot v2, and it attaches to a Windows 365 provisioning policy ^[3]. In automatic mode the policy has no Assignments page, so the link inside the provisioning policy is the assignment ^[14]. An Intune policy page without an Assignments tab takes some getting used to. Before any of it works, automatic Intune enrollment has to be configured: Entra ID, then Mobility (MDM and WIP), then Microsoft Intune, with MDM user scope set to All or Some ^[17].

Failure behaviour comes from one checkbox in the provisioning policy, named Prevent users from connection to Cloud PC upon installation failure or timeout. Select it and a Cloud PC that fails preparation is marked Failed, and nobody connects ^[7]. Leave it clear and the same Cloud PC is marked Provisioned with warnings, and the user connects to whatever installed in time ^[8]. The walkthrough does not state the timeout length, or which way the box ships by default ^[24].

Automatic mode runs in the background, so there is nothing to watch on screen while setup happens ^[9]. According to the walkthrough, tracking down a single device that is missing its apps gets much faster once the deployments report is the place you look ^[22].

The delivery speed comes from the group. The Cloud PC is added to a predefined device security group at the moment of enrollment and the configuration is delivered immediately, instead of after dynamic group membership has been evaluated ^[11]. Cloud PCs are added during deployment without manual work ^[13]. If the Intune service principal does not appear in the list or in search results, it goes in through PowerShell with Connect-MgGraph -Scopes "Application.ReadWrite.All" ^[19]. In some tenants it shows under the name Intune Autopilot ConfidentialClient, and the AppId to check is f1346770-5b25-470b-88bd-d5744ab7952c ^[18]. Microsoft recommends separate device groups for user-driven and automatic scenarios, the walkthrough says ^[20].

For this to fix a first-login complaint, the apps that make a login useful have to be the ones Intune installs as apps or scripts, since those are the only things provisioning waits on ^[23]. A slow installer on that list makes every Cloud PC in the batch wait for it before anyone can connect ^[23]. The write-up assumes a tenant already licensed for Windows 365 Enterprise or Flex with Microsoft Intune ^[21].

What to watch

Whether Microsoft documents a default state and a timeout value for the connection-blocking setting in the provisioning policy.
Whether automatic mode gains SKUs beyond the four currently listed, or drops any of them.
Whether operators running preparation gating report first-connection waits long enough to become their new ticket category.

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[1]
Traditionally a Cloud PC is marked Provisioned as soon as Intune enrollment finishes, and users can connect from that point; app delivery runs afterward.
ReportedSupportedSource: dev.to walkthrough on device preparation policy for Windows 365View cited source
[2]
Right after the first sign-in the Cloud PC often has neither Teams nor the line-of-business apps installed.
ReportedSupportedView cited source
[3]
The device preparation policy is a form of Windows Autopilot device preparation, commonly known as Autopilot v2, and is a dedicated policy linked to a Windows 365 provisioning policy.
ReportedSupportedView cited source
[4]
With a device preparation policy, Windows 365 waits to complete provisioning until the specified apps and scripts have finished installing, guaranteeing essential Intune apps and scripts are installed before the user signs in.
ReportedSupportedView cited source
[5]
The SKUs that can be provisioned in automatic mode are Windows 365 Flex in shared mode, Windows 365 Enterprise, Windows 365 Flex in dedicated mode, and Windows 365 Cloud Apps.
ReportedSupportedView cited source
[7]
If Prevent users from connection to Cloud PC upon installation failure or timeout is enabled in the provisioning policy, a Cloud PC that fails preparation is marked Failed and users cannot connect to it.
ReportedSupportedView cited source
[8]
If that setting is left unselected, the Cloud PC is marked Provisioned with warnings and users can connect.
ReportedSupportedView cited source
[9]
In automatic mode, Cloud PC setup happens in the background, so it cannot be watched on screen.
ReportedSupportedView cited source
[10]
The Windows Autopilot device preparation deployments report tracks deployment status, phase and deployment time per device, and the status of each individual app and script as Installed, In progress, Skipped or Failed.
ReportedSupportedView cited source
[11]
The device is added to a predefined device security group at the moment of enrollment and the configuration is delivered immediately, which the walkthrough contrasts with waiting for dynamic group membership to be evaluated.
ReportedSupportedView cited source
[12]
The group specified in the device preparation policy must be an assigned security device group; dynamic groups cannot be used.
ReportedSupportedView cited source
[13]
Cloud PCs are automatically added to the specified group during deployment, and adding them manually is not necessary.
ReportedSupportedView cited source
[14]
A device preparation policy in automatic mode has no Assignments page; assignment is handled when the Cloud PC provisioning policy is created.
ReportedSupportedView cited source
[15]
Building a custom image with the required apps preinstalled and keeping it updated piles up cost in image versioning, applying updates and re-validating.
ReportedSupportedView cited source
[16]
A device preparation policy keeps the standard configuration of a gallery image plus Intune app delivery while reducing the management overhead of custom images.
ReportedSupportedView cited source
[17]
Automatic Intune enrollment is set up in the Azure portal under Microsoft Entra ID, Mobility (MDM and WIP), Microsoft Intune, with MDM user scope set to All or Some.
ReportedSupportedView cited source
[18]
In some tenants the service principal is displayed as Intune Autopilot ConfidentialClient; it is the correct service principal as long as the AppId is f1346770-5b25-470b-88bd-d5744ab7952c.
ReportedSupportedView cited source
[19]
If the service principal appears neither in the list nor in search results, it can be added with PowerShell using Microsoft.Graph.Authentication and Microsoft.Graph.Applications and Connect-MgGraph -Scopes "Application.ReadWrite.All".
ReportedSupportedView cited source
[20]
Microsoft recommends using separate device groups for user-driven scenarios and automatic scenarios.
ReportedSupportedSource: Microsoft, as reported in the dev.to walkthroughView cited source
[21]
The walkthrough is written as of September 2026 and assumes a tenant with Windows 365 Enterprise or Flex (formerly Frontline) licenses and Microsoft Intune.
ReportedSupportedView cited source
[6]
Automatic mode supports four Windows 365 SKUs.
DerivedSupported1 source— sign in to open
[23]
Because provisioning completes only after every specified app and script installs, the wait before first connection is bounded below by the slowest specified install, and items not on the list are not gated.
DerivedSupported1 source— sign in to open
[24]
The walkthrough describes both states of the connection-blocking setting without stating its default or the timeout duration.
DerivedSupported1 source— sign in to open
[22]
The walkthrough says that isolating why one device is missing its apps gets dramatically faster with the deployments report.
ReportedInsufficientSource: dev.to walkthroughView cited source

Sources

Publishers with included, body-backed reporting in this cluster.

dev.to
1 article · September 13, 2026
Device Preparation Policy for Windows 365 CloudPC in Intune

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Try

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

The setup detail is the reason to read this. Apps must be set to install in Device context and platform scripts need 'Run this script using the logged on credentials' set to No, because no user is signed in during OOBE. Where the Intune Autopilot service principal is missing from the Mobility list, dev.to's walkthrough gives the AppId to check against, f1346770-5b25-470b-88bd-d5744ab7952c, and the four PowerShell lines that create it. One number in the post should not be trusted, and the author says so: Microsoft's overview and Step 3 pages allow 25 apps and 10 scripts during OOBE while the Step 4 page allows 10 apps, so he tells readers to read the limit off the admin center UI.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence45

0100

One practitioner guide, most of it checkable in a tenant

One source, one author, published 14 September 2026 on dev.to. Much of it is falsifiable in an afternoon: the Entra path for MDM user scope, the requirement that the target group be an assigned security device group, the two states a Cloud PC lands in after failed preparation. The soft spot is the OOBE app limit, where the author reports Microsoft saying 25 apps on two pages and 10 on a third and advises trusting the admin center. No other publisher in our coverage has tested any of it.

AdoptionInsufficient

No usage signal

This is a configuration guide, and it does not carry a tenant count, telemetry or a deployment case. The four eligible SKUs are the ones that can use automatic mode, not a record of who has turned it on.

Hype gap+10

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

Entities

build
A GTK app fetches the per-resource .rdp files FreeRDP needs to reach Azure Virtual Desktop
1 publisher
security
Scattered Spider talks help desks into moving MFA onto attacker-controlled devices
1 publisher
security
Microsoft documents helpdesk impostors riding a granted Teams session to domain controllers
2 publishers
security
A CVSS 10.0 in Entra ID was exploited and fixed without you ever touching it
5 publishers

What happened

Why it matters

What to watch

Claim ledger

Sources

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Related stories

Claim ledger

Sources

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Related stories

Perspective Coverage

Reality