DEV Community: KY3095

How to connect Intune with Apple Business Manager (ABM) and enroll iPhones with Automated Device Enrollment (ADE)

KY3095 — Mon, 14 Sep 2026 07:13:13 +0000

About this article

Intended audience: IT and endpoint management admins who want to manage corporate-owned iPhones / iPads with Intune
What you'll learn
- The concrete steps for the prerequisites (MDM authority and the APNs certificate) you need before you can start with ADE
- How to issue the enrollment program token that connects ABM and Intune
- How to create an enrollment profile for Automated Device Enrollment (ADE)
- What actually happens from the moment you power on an iPhone until it becomes managed
Test environment: Microsoft Intune admin center / Apple Business Manager (as of September 2026)
Assumptions: The devices are new, purchased through ABM, or have been wiped

With Automated Device Enrollment (ADE), a device enrolls in Intune automatically during the initial setup the first time it's powered on. No manual staging is required, and because the device becomes Supervised, you can apply stronger controls such as restricting app installation, automatically configuring Wi-Fi, and disabling features you don't need.

Why use ADE

When you hand out corporate-owned iPhone, you could set each one up by hand and have users enroll them from the Company Portal. But that approach has problems.

Staging effort grows linearly with the number of devices
Users can remove the management profile on their own
The devices don't become supervised, so the range of what you can control is limited

ADE solves all of these at once. Once devices are linked to ABM, you can get to a state where you take them out of the box and hand them straight to the user.

Overall workflow

Getting the order wrong means rework, so let's take in the big picture first.

#	Where	What
1-1	ABM	Set up the ABM account and register purchase information
1-2	Intune	Set the MDM authority to Intune
1-3	Intune ⇔ Apple	Get the APNs certificate (Apple MDM push certificate)
1-4	Intune	Check licenses
2	Intune ⇔ ABM	Create the enrollment program token (exchange the public key and the token)
3	ABM	Assign devices to the MDM server
4	Intune	Create the enrollment profile
5	Intune	Assign the profile to devices
6	Intune	Create a dynamic group
7	iPhone	Initial setup → verify automatic enrollment

[Step 1] Prerequisites

If this is your first time building this out, this is where you can get stuck. Let's walk through it one operation at a time.

1-1. Set up the ABM account and register purchase information

If you don't have an ABM account at all, sign up at business.apple.com. You need a D-U-N-S Number (a company identifier), and because Apple reviews the request it can take anywhere from a few days to a few weeks. If you're planning for ADE, start here first.

Once you have the account, you need to link your devices to ABM. There are two main ways to do that.

Route	Description
Through a reseller (recommended)	Devices purchased from Apple, an Apple Authorized Reseller, or a carrier are automatically added to your ABM account at the time of purchase
Through Apple Configurator	Devices you already have on hand are added to ABM manually using Apple Configurator on a Mac

If you go through a reseller, you need to register the reseller's customer number (purchase information) in ABM under Settings → Enrollment Information → Device Management Settings. If that isn't registered, the devices you purchase never flow into ABM.

If you add devices you already purchased to ABM later using Apple Configurator, the user gets a 30-day provisional period, and during that window they can release the device from management themselves. Devices procured through a reseller don't have this provisional period. If you want to manage corporate-owned devices properly, the rule of thumb is to assume ABM integration from the procurement stage.

1-2. Set the MDM authority to Intune

The MDM authority is the setting that declares which service manages the devices in this tenant. Until an IT admin sets the MDM authority, users can't enroll any devices at all.

First, check the current setting

Sign in to the Microsoft Intune admin center
Tenant administration → Tenant status
Open the Tenant details tab
Check the MDM authority entry

If it shows Microsoft Intune, you're already set. Move on to 1-3 below.

In relatively recently created tenants, the MDM authority is almost always already set to Intune.

Note that you also need an Intune license assigned in order to set the MDM authority.

1-3. Get the Apple MDM push certificate (APNs certificate)

The APNs certificate is a hard requirement for managing iOS/iPadOS/macOS with Intune. It's what Intune uses to deliver instructions to devices through Apple's push notification service. Without it you can't do ADE — you can't even do regular enrollment.

You'll be going back and forth between the Intune side and the Apple side, so let's follow it step by step.

① Open the settings page in Intune and give consent

Sign in to the Microsoft Intune admin center
Go to Devices
Select Device onboarding → Enrollment
Select the Apple tab
Select Apple MDM Push Certificate
Select I agree to give Microsoft permission to send data to Apple

② Download the CSR (certificate signing request)

Select Download your CSR and save the request file locally. You upload this file on the Apple side to have the certificate issued.

③ Create the certificate in the Apple Push Certificates Portal

Select Create your MDM push Certificate to go to the Apple Push Certificates Portal
Sign in with your organization's Apple ID
Select Create a Certificate
Read and accept the terms and conditions
Select Choose File and choose the CSR file you downloaded in ②
Select Upload
On the confirmation page, select Download and save the certificate file (.pem)

Do not get the choice of Apple ID here wrong.

The certificate is associated with the Apple ID used to create it. You need the same Apple ID to renew it, so if you create it with an individual admin's personal Apple ID, you lose the ability to renew the moment that person changes roles or leaves.

Microsoft's own guidance recommends using a company email address and making sure the mailbox is monitored by more than one person, such as through a distribution list. Avoid using a personal Apple ID.

④ Enter the Apple ID in Intune

Return to the Intune admin center and enter the Apple ID you used to create the certificate. This is needed so you get reminded when the certificate needs to be renewed.

⑤ Upload the certificate

Select the Folder icon
Select the .pem file you downloaded in ③
Select Upload

You're done once the status shows as active.

[Important] The APNs certificate must be renewed every year

The Apple MDM push certificate is valid for 365 days. You must renew it annually to keep managing iOS/iPadOS/macOS.

If it expires, you can still renew it within the 30-day grace period
You must renew it with the same Apple account you used to create it
The renewal steps are nearly identical to creating it (download the CSR → select Renew on the relevant certificate in the Apple portal → upload the new CSR → upload the downloaded certificate to Intune)
When you renew in the Apple portal, entering a unique note about the certificate makes it easier to identify if you have more than one

💡 How to figure out which certificate is which

Each certificate has a unique UID. In the certificate details, look for the subject ID, which shows the GUID portion of the UID.

You can also check from an enrolled iOS/iPadOS device.
Go to Settings → General → Device Management → Management Profile → More Details → Management Profile, and match the GUID contained in the Topic value against the certificate in the Apple Push Certificates Portal.

1-4. Check licenses

If you enroll with user affinity, each user must have an Intune license assigned
If you enroll without user affinity (shared devices and so on), management is per device

That completes the prerequisites. Now we can finally move on to connecting with ABM.

[Step 2] Create the enrollment program token

There's a round trip here: issue the public key in Intune → upload it to ABM → issue the token in ABM → come back to Intune and upload it.

Don't close the Microsoft Intune admin center browser tab while you're doing this.
After you finish the work in ABM, you need to come back to the same tab to upload the token. If you close it, you have to start over.

2-1. Download the public key in Intune

Intune admin center → Devices
Expand Device onboarding → Enrollment
Apple → Enrollment program tokens → Create
Select I agree to grant permission to Microsoft to send user and device information to Apple
Select Download your public key (a .pem file is saved)

2-2. Upload the public key to ABM and get the token

Leave the Intune tab open and open ABM in a separate tab.

In ABM, go to the device management services page ( https://business.apple.com/main/devices/managementservices )
Select Add
Select "Connect external device management" → "Continue"
Enter any service name, upload the public key (.pem) you downloaded in 2-1, and select "Next"
Select "Download Service Token" (a .p7m file is saved)

2-3. Upload the token to Intune

Go back to the Intune tab you left open.

For Apple ID, enter the Apple ID you used to create the token
For Apple token, specify the .p7m file you downloaded in 2-2
Select Next
Apply scope tags if needed (when you want to limit other admins from making changes)
Review + create → Create

That completes the connection between Intune and ABM.

[Step 3] Assign devices to the MDM server in ABM

On the ABM side, assign the devices you want to manage to the MDM server you created. Devices that aren't assigned never sync to Intune.
For how to assign them, see the following Apple documentation.
https://support.apple.com/en-us/guide/business/axmf500c0851/1/web/1

After assigning, run a sync on the Intune side and the device count is reflected under Devices on the enrollment program token.

[Step 4] Create the enrollment profile (enrollment policy)

This defines the settings applied to the device during initial setup.

Select the token you created in [Step 2] → Profiles
Create profile → iOS/iPadOS
Enter a name and description (users don't see these details) → Next

4-1. User affinity and authentication method

First, decide whether to tie the device to a user. The configuration branches from here.

Pattern A: Without user affinity (best when you just want to verify it works)

Setting	Value
User Affinity	Enroll without User Affinity

This is the configuration for use cases that aren't tied to a specific user, such as shared devices or in-store devices. Since it needs neither the Company Portal nor an Intune user license, it's also well suited to isolating and verifying just "is the ADE wiring correct?"

Pattern B: With user affinity (production configuration)

Setting	Value	Notes
User Affinity	Enroll with User Affinity	Use this for corporate-owned devices tied to an individual
Authentication method	Setup Assistant with modern authentication / Company Portal / Setup Assistant (legacy)	See below

How to choose the authentication method

Authentication method	Characteristics
Setup Assistant with modern authentication	Authentication completes inside Setup Assistant. Because it can complete the user association without the Company Portal app, it's the easiest one to try first
Company Portal	Authentication happens in the Company Portal app. The app has to be installed separately (see below)
Setup Assistant (legacy)	The traditional method

4-2. Management options

Setting	Value	Notes
Locked enrollment	Yes	Users can no longer remove the management profile. For corporate-owned devices, "Yes" as a rule
Sync with Computers	Allow all	Restrict according to your requirements

4-3. Device name template (optional)

By default, Apple names devices after the device type (iPad and so on). If you want a consistent naming convention, configure a template.

contoso-{{DEVICETYPE}}-{{SERIAL}}

What the device name looks like after enrollment: contoso-iPhone-XXXXXXXXXX

The device name template applies only to supervised devices.

4-4. Setup Assistant

Department: shown when users tap "About Configuration" while the device is activating
Department Phone: the contact shown when users tap the "Need Help" button
Showing / hiding the various setup screens: if you want enrollment to be as smooth as possible, setting them all to "Hide" is a good move

Review the settings and select "Create" to save.

[Step 5] Assign the profile to devices

Creating the profile isn't enough for it to apply. Assigning it to devices is required.

Go back to Enrollment program tokens and select the token from the list
Select Devices and check the devices you want to assign
Select Assign profile
Choose the enrollment profile you created → Assign

[Step 6] Create a dynamic group (an operational tip)

Since you'll want to target apps and policies only at devices enrolled through ADE, creating a dedicated dynamic device group makes ongoing operations much easier.

Groups → New group
Enter a group name and select Dynamic Device for the membership type
Set the following rule as the dynamic query

(device.enrollmentProfileName -eq "the name of the enrollment profile you created")

Setting	Value
Property	enrollmentProfileName
Operator	Equals
Value	The profile name you created in step 4

With this, devices enrolled with that profile automatically land in the group. From here on, you can target this group for app deployment and configuration profiles.

[Step 7] Set up an iPhone and verify the behavior

Once the Intune side is ready, verify it on a real device. Have a new or wiped iPhone on hand.

How to tell it succeeded

During initial setup, a screen showing "Enroll This iPhone" plus your company name is displayed
The lock screen shows "This iPhone is remotely managed"
The device appears under iOS/iPadOS devices in Intune

Once you've confirmed all of this, the ADE rollout is complete.

References

Device Preparation Policy for Windows 365 CloudPC in Intune

KY3095 — 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

KY3095 — 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.