DEV Community: KojiYamada3095

Device Preparation Policy for Windows 365 CloudPC in Intune

KojiYamada3095 — Mon, 14 Sep 2026 04:38:12 +0000

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.

Reference links (official Microsoft documentation)

Overview and requirements

Procedure (the 6-step tutorial for Windows 365 automatic mode)

Endpoint management and virtual desktop admins who are considering Azure NetApp Files (ANF) as the profile storage location for AVD

KojiYamada3095 — Mon, 14 Sep 2026 04:25:09 +0000

About this article

What you'll learn
- How to use ANF as the storage location for FSLogix profile containers
- The FSLogix registry settings
- How to verify that it works
Test environment: Azure Virtual Desktop / Azure NetApp Files (as of September 2026)
Assumptions: An Active Directory Domain Services (AD DS) environment

FSLogix stores a user profile in a VHD(X)-based container and attaches it to the session host at sign-in. You use it to persist user settings and data in non-persistent VDI and multi-session environments.

FSLogix containers are placed on an SMB file share. There are various options, such as a shared file server in an on-premises environment, but this article covers storing them on Azure NetApp Files (ANF). As a managed SMB file server, Azure NetApp Files delivers low latency and high throughput.

Container types

Type	Description
Profile Container	Stores the complete user profile in a VHD(X). This is what this article uses
ODFC Container	Separates only Office-related data into a different container
Cloud Cache	Not a type, but an optional configuration for the containers above

Overall workflow

#	Where	What
1	Azure portal	Create a NetApp account
2	Azure portal	Create a capacity pool
3	Azure portal	Configure an Active Directory connection
4	Azure portal	Create an SMB volume
5	Session host	Configure the registry
6	Session host	Verify that it works

Other prerequisites

An Azure account with contributor or administrator permissions
A subnet delegated to Azure NetApp Files
ANF can be accessed only from the same VNet, or a peered VNet in the same region
Only one subnet per VNet can be delegated to ANF
One AD connection per NetApp account

[Step 1] Create a NetApp account

Select Create a resource → search for Azure NetApp Files → select Create

Setting	Description
Name	The display name of the NetApp account
Subscription	Any subscription
Resource group	Any resource group
Location	The same region as the session hosts

A NetApp account must be created in the region where the volumes will be deployed.

[Step 2] Create a capacity pool

In the NetApp account you created → Capacity pools → + Add pool

Setting	Description
Name	The display name of the capacity pool
Service level	Standard / Premium / Ultra
Size (TiB)	Set as needed
QoS type	Auto / Manual

[Step 3] Configure an Active Directory connection

Before creating an SMB volume, you need to create an Active Directory connection.

3-1. Prepare the account used for the domain join

An AD DS domain user account in the same domain where the ANF computer accounts are created
Permissions to create computer accounts in the specified OU

3-2. Create the Active Directory connection

NetApp account → Active Directory connections → Join

Required fields

Setting	Description
Primary DNS	The IP address of the DNS server required for the domain join
Secondary DNS	Same as above
AD DNS Domain Name	The fully qualified domain name of the AD DS (for example, `contoso.com`)
AD Site Name	The default is `Default-First-Site-Name`
SMB server (computer account) prefix	The naming prefix for the computer accounts that ANF creates in AD DS
Username / Password	The account used for the domain join, and its password

Organizational unit path

Specify the LDAP path for the organizational unit (OU) where the SMB server computer accounts will be created. The format is OU=second level, OU=first level. If no value is provided, the CN=Computers container is used.

Optional fields

Setting	Description
AES Encryption	Enables AES encryption authentication support for the admin account of the AD connection
LDAP Signing	Integrity verification for SASL LDAP binds between ANF and AD DS
LDAP over TLS	Secures communication between ANF and the AD LDAP server. Don't enable it with Microsoft Entra Domain Services
Backup policy users	Grants privileges such as `SeBackupPrivilege`
Security privilege users	Grants `SeSecurityPrivilege`. Supported only for SQL Server

Registration complete

[Step 4] Create an SMB volume

NetApp account → Volumes → + Add volume

4-1. Basics tab

Setting	Description
Volume name	Any name
Capacity pool	The pool created in step 2
Quota	Regular volumes are 50 GiB to 100 TiB
Virtual network	The Azure virtual network from which you want to access the volume
Subnet	The subnet delegated to ANF
Availability Zone	None / the same zone as the session hosts

4-2. Protocol tab

Setting	Value
Protocol type	SMB
Active Directory	The connection created in step 3
Share name	The share name that users see
Enable Continuous Availability	✅ Enable it (recommended for FSLogix)
SMB3 Protocol Encryption	When enabled, clients that don't use SMB3 encryption can't access the volume
Access Based Enumeration	Hides directories from users who don't have access permissions

After creation, the Mount path is shown on the volume's Overview.

[Step 5] Configure the registry

Configure the following registry settings on the VMs that act as session hosts.

Registry path: HKEY_LOCAL_MACHINE\SOFTWARE\FSLogix\Profiles

Below is a list of settings taken from the official Microsoft documentation. Enabled and VHDLocations are required.

Value name	Type	Value	Official classification	Default
`Enabled`	DWORD	1	Required	0
`VHDLocations`	MULTI_SZ	`\\<anf-fqdn>\<share-name>`	Required	—
`VolumeType`	REG_SZ	`VHDX`	Recommended	`vhd`
`DeleteLocalProfileWhenVHDShouldApply`	DWORD	1	Recommended	—
`FlipFlopProfileDirectoryName`	DWORD	1	Recommended	0
`LockedRetryCount`	DWORD	3	Recommended	12
`LockedRetryInterval`	DWORD	15	Recommended	5
`ReAttachIntervalSeconds`	DWORD	15	Recommended	10
`ReAttachRetryCount`	DWORD	3	Recommended	60
`ProfileType`	DWORD	0	Default	0
`SizeInMBs`	DWORD	30000	Default	30000

To configure them with PowerShell, use the following.

$regPath = "HKLM:\SOFTWARE\FSLogix\Profiles"

New-ItemProperty -Path $regPath -Name "Enabled" -PropertyType DWORD -Value 1 -Force
New-ItemProperty -Path $regPath -Name "VHDLocations" -PropertyType MultiString -Value "\\<anf-fqdn>\<share-name>" -Force
New-ItemProperty -Path $regPath -Name "VolumeType" -PropertyType String -Value "VHDX" -Force
New-ItemProperty -Path $regPath -Name "DeleteLocalProfileWhenVHDShouldApply" -PropertyType DWORD -Value 1 -Force
New-ItemProperty -Path $regPath -Name "FlipFlopProfileDirectoryName" -PropertyType DWORD -Value 1 -Force
New-ItemProperty -Path $regPath -Name "LockedRetryCount" -PropertyType DWORD -Value 3 -Force
New-ItemProperty -Path $regPath -Name "LockedRetryInterval" -PropertyType DWORD -Value 15 -Force
New-ItemProperty -Path $regPath -Name "ReAttachIntervalSeconds" -PropertyType DWORD -Value 15 -Force
New-ItemProperty -Path $regPath -Name "ReAttachRetryCount" -PropertyType DWORD -Value 3 -Force
New-ItemProperty -Path $regPath -Name "SizeInMBs" -PropertyType DWORD -Value 30000 -Force

Deploying the settings with Group Policy

Get the ADMX / ADML files here: https://learn.microsoft.com/en-us/fslogix/how-to-use-group-policy-templates

File	Destination (domain)
`fslogix.admx`	`%systemroot%\sysvol\domain\policies\PolicyDefinitions`
`fslogix.adml`	`%systemroot%\sysvol\domain\policies\PolicyDefinitions\[MUIculture]`

Policy location: Computer Configuration → Administrative Templates → FSLogix

[Step 6] Verify that it works

6-1. Check the service and the settings

Run the following at a command prompt on the session host.

sc query frxsvc

Confirm that it reports STATE : RUNNING.

Next, run the following.

reg query HKLM\SOFTWARE\FSLogix\Profiles

Confirm that Enabled is 0x1 and that VHDLocations contains the ANF mount path.

6-2. Check the file

Connect to the session host and open the Mount path in File Explorer.

\\<anf-volume-fqdn>\<share-name>\<username>_<SID>\Profile_<username>.vhd

6-3. Check that the profile roams

Sign out of the first session host, sign in to a second session host, and if your desktop changes (wallpaper, file layout, and so on) carry over, it works.

DEV Community: KojiYamada3095

Device Preparation Policy for Windows 365 CloudPC in Intune

What a device preparation policy in Automatic mode is

Benefits

1. The Cloud PC is "ready for productive use" the moment the user first signs in

2. You're freed from building and maintaining custom images

3. You can choose not to hand a failed Cloud PC to the user

4. Near real-time visibility at the individual app and script level

5. Enrollment Time Grouping makes delivery fast and reliable

6. Assignment management is simpler

Overall workflow

[Step 1] Set up Windows automatic Intune enrollment

[Step 2] Create an assigned device group

If you can't find Intune Provisioning Client

[Step 3] Assign applications and PowerShell scripts to the device group

Assigning applications

Assigning PowerShell scripts

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

[Step 5] Create the Cloud PC provisioning policy

Monitor the deployment

Status per Cloud PC

Per-app and per-script details

Checklist recap

Reference links (official Microsoft documentation)

Overview and requirements

Procedure (the 6-step tutorial for Windows 365 automatic mode)

Endpoint management and virtual desktop admins who are considering Azure NetApp Files (ANF) as the profile storage location for AVD

About this article

Container types

Overall workflow

[Step 1] Create a NetApp account

[Step 2] Create a capacity pool

[Step 3] Configure an Active Directory connection

3-1. Prepare the account used for the domain join

3-2. Create the Active Directory connection

Required fields

Organizational unit path

Optional fields

[Step 4] Create an SMB volume

4-1. Basics tab

4-2. Protocol tab

[Step 5] Configure the registry

Deploying the settings with Group Policy

[Step 6] Verify that it works

6-1. Check the service and the settings

6-2. Check the file

6-3. Check that the profile roams

References