Autopilot device preparation in Intune: provision a new Windows 11 PC

Which Autopilot do you need? Start here

Windows Autopilot is two products that share a name, which is how a perfectly reasonable search ends up on the wrong tutorial. Classic Windows Autopilot registers each device's identity with Microsoft first, then downloads a deployment profile when the PC connects. Windows Autopilot device preparation skips registration. The PC finds out it belongs to you when someone in your user group signs in during the out-of-box experience (OOBE), and the policy follows from that sign-in. This article builds the second one, because it is the shorter route to a working first test.

Hardware identity is the real dividing line. Classic Autopilot relies on a hardware hash: a fingerprint that includes details such as manufacturer, model, device and disk serial numbers, uploaded by the supplier or by you. Device preparation needs no hash and no registration. If your tenant blocks personal Windows enrolments, it instead needs one of two things for each device before first boot: a corporate identifier (manufacturer, model and serial number uploaded to Intune) or device association (a TPM-backed link between the PC and your tenant, stamped into the firmware). You only need one of them.

The Enrollment Status Page (ESP) is another quick giveaway. Classic Autopilot uses it. Device preparation does not, and shows its own round progress screen instead. If a test PC shows the ESP, it is running a classic profile, not this policy.

Independent write-ups, including a Petri article by a Microsoft Security MVP, reach the same practical conclusion: for a cloud-native estate device preparation is a sensible starting point, and classic Autopilot covers the gaps. Those gaps are real. Stay with classic Autopilot if you need any of the following:

• Microsoft Entra hybrid join. Device preparation supports Entra join only.
• Pre-provisioning, self-deploying mode or the existing-devices scenario. Device preparation currently offers user-driven and automatic modes only, and automatic mode is for Windows 365 Cloud PCs.
• Windows 10 devices. Device preparation is Windows 11 only.
• Autopilot Reset, HoloLens, Teams Meeting Room devices, DFCI firmware management or Autopilot into co-management.
• More than 25 apps or 10 scripts during setup, or a hard block on reaching the desktop until user-targeted settings have applied. Classic Autopilot's ESP can block on up to 100 apps.
• A registered classic device behaves differently from an unregistered one. If a device is registered with classic Autopilot and not associated with your tenant, the classic profile wins and this policy is ignored. If it is associated, device preparation runs. To use device preparation on a registered device without associating it, deregister it first.

Before you begin

Use a pilot user, dedicated security groups and one Windows 11 test device. Start in a non-production environment where possible, keep assignments restricted to pilot users and check the current device-preparation labels in your tenant before making changes.

Use a new or spare physical PC with nothing on it you want to keep. First boot joins it to Entra ID and enrols it in Intune, and this article does not cover wiping or reinstalling an in-use machine. Microsoft describes the user-driven scenario as being for physical devices, so plan on real hardware rather than a virtual machine.

• Licences: Microsoft's list includes Microsoft 365 Business Premium, F1/F3, Academic A1/A3/A5, Enterprise E3/E5, Enterprise Mobility + Security E3/E5, Intune for Education, or Entra ID P1/P2 plus Intune. Business Basic and Standard are not on that list. The lab user must have a licence assigned so they can enrol devices.
• Windows: Windows 11 24H2 or later, or 23H2 or 22H2 with KB5035942 or later. Check that the build the PC ships with or your installation media already includes that update, because a missing update is the classic reason the experience never starts. Windows 10 is not supported.
• Tenant settings: automatic MDM enrolment configured for the lab user, and the lab user allowed to join devices to Microsoft Entra ID. Section 3 covers both.
• Admin access: an account that can change Entra device settings, create groups and add owners, plus an Intune role holding the permissions Microsoft lists for device preparation administrators (Device configurations: Read, Delete, Assign, Create, Update; Enrollment programs: Enrollment time device membership assignment; Managed apps: Read; Mobile apps: Read; Organization: Read). In a throwaway lab tenant, Global Administrator is the quick option. Do not copy that habit into production.
• Network: working internet with DNS, ports 80 and 443 (HTTPS) and UDP 123 (time) open to all hosts, login.live.com reachable, and lgmsapeweu.blob.core.windows.net not blocked if you want failure diagnostics to upload. Smart card and certificate sign-in do not work during OOBE. Set any proxy on the proxy server, not through Intune policy.
• Apps: at least one app already packaged in Intune, ideally small and quick to install. The Windows apps article in this series covers packaging.
• Tenant impact: nothing here touches existing devices, but the corporate identifier option in section 6 changes how other new Windows devices are classified at enrolment. Read that section before uploading anything to a shared tenant.

Create the groups and tenant settings

Device preparation needs two groups. The user group decides who receives the policy. The assigned device group is where the PC is placed automatically during enrolment, so that apps and scripts assigned to that group arrive quickly. Microsoft recommends groups created just for this purpose rather than reusing existing ones. The device group needs one unusual detail: its owner must be the Intune Provisioning Client service principal, otherwise the policy will not save the group.

Do these in the Microsoft Intune admin centre unless the step says otherwise. They are quick, and nothing here affects a device yet.

1. Create the user group. Go to Groups, then All groups, then New group. Set Group type to Security, name it something like Lab-AP-DevicePrep-Users, set Microsoft Entra roles can be assigned to the group to No, set Membership type to Assigned, add yourself as owner, and add your lab test user as a member. Select Create. Use users only; do not add devices.
2. Create the device group. Repeat the process, with Group type Security, a name like Lab-AP-DevicePrep-Devices, Microsoft Entra roles can be assigned to the group set to No and Membership type set to Assigned. Under Owners, select No owners selected, search for Intune Provisioning Client (application ID f1346770-5b25-470b-88bd-d5744ab7952c) and select it. Leave the group empty. Devices are added during deployment.
3. Only if the service principal does not appear in the owner search: in some tenants it is named Intune Autopilot ConfidentialClient, and that is fine if the application ID matches. If neither name exists, a Microsoft Entra administrator can add it from an elevated PowerShell window using the Microsoft Graph PowerShell modules. This creates a Microsoft first-party application object in your tenant and consents to the Application.ReadWrite.All permission for your sign-in session. A 409 error means it already exists, and a 403 means your account lacks permission or consent.
   powershellCopy

   Install-Module Microsoft.Graph.Authentication
   Install-Module Microsoft.Graph.Applications
   Connect-MgGraph -Scopes "Application.ReadWrite.All"
   New-MgServicePrincipal -AppId f1346770-5b25-470b-88bd-d5744ab7952c

4. Check automatic enrolment. In the Azure portal, open Microsoft Entra ID, then under Manage select Mobility (MDM and WIP), then Microsoft Intune. Under MDM user scope choose All, or choose Some and select your lab user group. Select Save if you changed anything.
5. Check join permission. In the same Microsoft Entra ID area, go to Devices, then Device settings. Under Users may join devices to Microsoft Entra, choose All, or choose Selected and add your lab user group. Select Save if you changed anything.

Assign the essential apps to the device group

Only apps and scripts you both select in the policy and assign to the device group run during setup. Anything else assigned to that group arrives after the user reaches the desktop. That distinction matters because a failed app or script that you selected fails the whole deployment.

For that reason, keep the first test small: one app, no scripts. If it works, add more one at a time. Supported app types are line-of-business, Win32, Microsoft Store (only apps that support WinGet), Microsoft 365 apps and Enterprise App Catalog apps. Enterprise App Management is separately licensed and not needed for the initial pilot, although Microsoft added the ability on 29 October 2026 to make auto-update catalog apps block setup.

Setup runs before anyone is signed in, so assign to the device group, not the user, and use the System (device) context.

1. In the Intune admin centre go to Apps, then under By platform select Windows, and open your chosen app.
2. Under Manage select Properties, then next to Assignments select Edit.
3. Under Required, select Add group and choose Lab-AP-DevicePrep-Devices. Confirm Group mode is Included and, where the option exists, that Install Context is Device context.
4. Select Review + save, then Save.
5. If you later add a PowerShell script, find it under Devices, then Manage devices, then Scripts and remediations, then Platform scripts. Under Properties and Assignments, add the device group under Included groups, and set Run this script using the logged on credentials to No so it runs as System.

Create the device preparation policy

The policy ties the pieces together: it is assigned to the user group, points at the device group, and lists which apps and scripts are essential. It also sets the account type and what happens on failure. For a first pilot, keep failures visible rather than allowing setup to skip them.

1. In the Intune admin centre go to Devices, then under By platform select Windows, then under Device onboarding select Enrollment. Under Windows Autopilot device preparation select Device preparation policies.
2. Select Create, then User Driven. On the Introduction page select Next.
3. On Basics, enter a name such as Lab-AP-DevicePrep-UserDriven and select Next.
4. On Device group, search for Lab-AP-DevicePrep-Devices and select it. Take care to choose the device group, not the user group. A policy can be saved without a device group, and it then simply never launches. Select Next.
5. On Configuration settings, expand Deployment settings. Set Deployment mode to User-driven, Deployment type to Single user and Join type to Microsoft Entra joined. For User account type, choose Standard User unless you have a reason not to. An Entra join normally makes the signing-in user a local administrator, and this setting removes them from the Administrators group before they reach the desktop.
6. Expand Out-of-box experience settings. Minutes allowed before showing installation error covers the whole deployment, not a single app, and accepts 15 to 720. For a first lab run we would pick a generous value such as 60 and tighten it once you know how long your apps take. That figure is our judgement, not a Microsoft recommendation. Leave Allow users to skip setup after multiple attempts on No so a failure stays visible, set Show link to diagnostics to Yes, and add a Custom error message if you like.
7. Leave the remaining OOBE options alone for now. Language (Region), Automatically configure keyboard, Hide Microsoft Software License Terms, Hide privacy settings, Hide change account options and Apply device name template only take effect on associated devices.
8. Expand Apps, select Add under Allowed Applications, add your test app and select Save. Expand Scripts only if you are testing one. The limits are 25 apps and 10 scripts.
9. On Scope tags, select Next. On Assignments, search for Lab-AP-DevicePrep-Users and select that user group, not the device group. Select Next.
10. On Review + create, check the settings and select Save. The policy should now appear in the list. If several policies are assigned to the same user, the one at the top with the smallest Priority number wins, and you can drag to reorder.

Make the test PC trusted if personal devices are blocked

Skip this section if your tenant does not block personal Windows enrolments. Device preparation then works without any pre-registration. If a device platform restriction does block personal Windows devices, however, a PC with no corporate identifier and no association is treated as personal and enrolment fails. Pick one method per device.

Our recommendation for a first lab is the corporate identifier. It is simple, it lives entirely in Intune, and it is easy to delete. Device association is worth the extra effort when you want device-targeted policy assignment, OOBE page hiding or device naming, but it needs a physical Windows 11 PC and writes a marker into its firmware. Microsoft says removing an association cannot be done from Intune; it needs a script run on the device itself.

One side effect to know about before you upload anything to a shared tenant: once Windows corporate identifiers exist, Intune marks Windows devices enrolling through this route that are not on the list as personal at enrolment time. In a blocked-personal tenant, those other devices will then be refused. Add the identifiers for any other legitimate new PCs you expect.

Corporate identifier steps:

• Device association, if you choose it instead: in OOBE, stop at the region page, press the Windows key five times, select Export device information with an NTFS-formatted USB drive, then in Intune go to Devices, then Enrollment, then Device association, then Devices, and select Add. Upload the CSV (one device per file) and optionally assign your policy. The state shows Pre-associated, then Associated once the PC connects to a network in OOBE and reports Association complete. An FAT32 or mixed-partition USB drive can cause the error Export of device link information timed out.

1. Find the PC's manufacturer, model and serial number. The label on the box or the supplier paperwork is safest for a brand-new PC. If Windows is already running on a spare PC, Microsoft provides a read-only PowerShell command that prints all three, shown here. Run it in PowerShell on that PC.
   powershellCopy

   Get-CimInstance -ClassName Win32_ComputerSystem | ForEach-Object {$_.Manufacturer, $_.Model, (Get-CimInstance -ClassName Win32_BIOS).SerialNumber -join ','}

2. Create a plain text CSV file with no header row, one line per device, in the form manufacturer, model, serial number. Remove any full stops from the serial number. The example uses invented values, so replace them with your own.
   textCopy

   ExampleMaker,ExampleModel 1,SERIAL0123456789

3. In the Intune admin centre go to Devices, then Enrollment, and open the Corporate device identifiers tab. Select Add, then Upload CSV file, and choose Manufacturer, model, and serial number (Windows only) as the identifier type. Under Import identifiers select your file, wait for validation to show a count, then select Add.
4. Confirm the success notification appears and the entry is listed. The status shows Not contacted until the PC enrols.

Run the first-boot test

Now the part you cannot learn from a policy screen. How long the PC takes depends on your connection, the size of the apps and how many updates Windows fetches. Microsoft listed installing monthly security updates during setup as a delayed planned feature. Allow for variable enrolment time and check progress on the device instead of relying on a fixed duration.

Stay near the PC. It will ask for language or network details on a non-associated device, and a failure needs someone to read the message and press Retry.

1. Rule out classic registration. In the Intune admin centre go to Devices, then Windows, then under Device onboarding select Enrollment, then under Windows Autopilot select Devices, and search by the PC's serial number. A new lab PC should not be listed. If a supplier registered it, deregister it or associate it first, or the classic profile will take over.
2. Start the PC from its fresh Windows 11 installation and connect it to the network. Make sure it is running a supported build, because setup cannot launch on older ones.
3. Select the region and keyboard options if prompted, then sign in with the lab user's work account. If that user is in the user group and licensed, a Setting up for work or school screen with a round progress indicator should appear. The Enrollment Status Page should not.
4. Let it work through joining Entra ID, enrolling in Intune, installing the Intune Management Extension and then your selected apps and scripts. When it succeeds, a Required setup complete page appears. Dismiss it and the user is signed in and sent to the desktop.
5. If an error appears, note it and use Retry once. Do not enable Continue anyway for this test, because it would hide the very failure you want to see. Use the diagnostics link if you enabled it.

Check that it worked

A desktop is not proof by itself. Check from both sides: what Intune recorded, and what the PC thinks about itself. Anything assigned to the device group but not selected in the policy keeps installing in the background after the desktop appears, so judge the selected apps by the report, not by what is visible on screen.

1. In the Intune admin centre go to Devices, then Monitor, then under Report name select Windows Autopilot device preparation deployments. Find the PC by name or serial number. Deployment status should read Success. Select the device name to open the Device deployment details pane and confirm the policy name, the Apps listed as Installed, and the Scripts if any.
2. Treat an app marked Skipped as a configuration fault: it usually means it was selected in the policy but not assigned to the device group.
3. Open Groups, then Lab-AP-DevicePrep-Devices, then Members. The PC should be there, added automatically.
4. Under Devices, then All devices, open the PC and check that it is shown as corporate-owned and checking in. Remember that Windows corporate identifiers only affect ownership at enrolment time.
5. On the PC, open Command Prompt and run the first command shown. In the output, AzureAdJoined should read YES. This confirms an Entra join, not a registration.
   cmdCopy

   dsregcmd /status

6. Still on the PC, run the second command to list local administrators. If you chose Standard User, the lab user should not appear. Other accounts, such as the built-in administrator and Entra administrator roles, may still be listed.
   cmdCopy

   net localgroup Administrators

If it did not work, and how to undo the lab

Most failures come down to a missing piece of plumbing rather than a subtle bug. Work from the top of this list, and use the deployment report first, as it names the phase where the deployment stopped. Policy installation is initial setup and line-of-business apps, script installation covers scripts, and app installation covers Win32 and Store apps. For a failed run, Intune offers a log download in the device deployment details, and failed-deployment diagnostics are available for 28 days.

• Setup never starts: check the Windows build and update level, that the signing-in user is in the user group, that the policy has a device group selected, that automatic enrolment and Entra join permission are on, and that a corporate identifier or association exists if personal devices are blocked. If the Enrollment Status Page appears, the PC is running classic Autopilot because it is registered or has a profile assigned.
• The device group will not save in the policy, with a message about the device security group: the Intune Provisioning Client service principal is probably not the group owner, or Microsoft Entra roles can be assigned to the group was set to Yes.
• The PC is not added to the device group: confirm the owner, confirm the group is Assigned rather than Dynamic, and confirm your admin account has the Enrollment time device membership assignment permission.
• Apps or scripts are Skipped or fail: confirm they are assigned to the device group, set to run in the System context, and for Store apps that they support WinGet. If a Win32 app uses a managed installer policy, Microsoft added support for that in April 2026, so check your tenant is not on an older workaround.
• Enrolment is refused with Enrollment restriction not met: the PC was classed as personal. Add its corporate identifier or associate it. The Enrollment failures view shows the reason.
• To undo the lab configuration: remove the lab user from the user group or delete the policy, which stops new deployments. Delete the corporate identifier if you added one, noting that this does not change the ownership of a device that has already enrolled. Delete the test device from Intune only when you are finished with it. Microsoft advises against manually deleting devices from Entra ID. Re-provisioning that PC means reinstalling Windows, which erases it, and is a separate decision.