Home › Setup guides › Create a Windows Autopilot deployment profile and Enrollment Status Page
Setup guide · from scratch
Create a Windows Autopilot deployment profile and Enrollment Status Page
Creates the deployment profile that shapes a registered device's out-of-box experience, assigns it to your dynamic Autopilot group, and configures the Enrollment Status Page that gates first sign-in until apps and policies land. The trap: the profile only ever reaches a device through that group, and membership can lag hours behind registration, so confirm Profile Status reads Assigned before you touch the machine.
Intune admin center (Devices > Enrollment > Windows)
≈ 20 min
Windows — Autopilot & USB provisioning · step 11 of 12 · ≈ 20 min‹ PreviousNext ›
Do these first — this guide assumes you already have:
Devices already registered with Windows Autopilot (hardware hashes imported, or OEM/reseller-registered)
A dynamic device group whose membership rule captures your Autopilot devices (by group tag/OrderID or the ZTDId attribute)
An Intune role with enrolment and device-configuration rights, e.g. Intune Administrator
Automatic MDM enrolment configured in Microsoft Entra ID, with Windows Enterprise or Pro licensing in place
The Decolla way — skip the clicks.
Every step below can be done by hand. Or connect your Microsoft tenant to Decolla once, and Decolla performs this for you over Microsoft Graph in your own tenant — then hands back a verified result you can see and roll back per item. It also puts the fundamentals this step depends on in place — the target group, the licence allocation — so a build is never blocked half-way by a missing dependency.
⏱ By hand: about 20 min of clicking, every build. The Decolla way: part of one tenant connect, then automatic.
Step 1. Before you build anything, confirm the device is actually there to receive a profile. Go to Devices > Windows > Enrollment, and under Windows Autopilot open Devices; check your target machine is listed by serial number. Then open your dynamic Autopilot device group and confirm the same machine appears under Members.
Screenshot: The Windows Autopilot devices list showing the target device with its serial number, alongside the dynamic group's Members blade listing the same device. (captured during a live customer build — coming to this page)
Why: The profile is delivered through the group, never to the device directly. If the group is empty, nothing you create in the following steps will reach the machine.
Watch for: Membership rules for Autopilot groups usually key off the group tag (OrderID) or the ZTDId/enrolmentProfileName attribute. A device registered minutes ago may not have landed in the group yet.
On a schedule: Allow up to a few hours for dynamic group membership to pick up a newly registered device. It is not instant.
Step 2. Go to Devices > Windows > Enrollment, and under Windows Autopilot select Deployment Profiles, then Create Profile > Windows PC. On the Basics page, give the profile a clear Name and a Description you will still understand in six months.
Screenshot: The Create profile Basics tab with Name and Description filled in, and the platform set to Windows PC. (captured during a live customer build — coming to this page)
Watch for: Microsoft keeps reshuffling the left-hand Devices menu; in some tenants Enrollment now sits under a 'Device onboarding' heading rather than at the top level. If you cannot find it, the Windows enrollment landing page is your anchor, look for the Windows Autopilot section on it.
Step 3. Still on Basics, leave 'Convert all targeted devices to Autopilot' set to No unless you deliberately want every corporate device in the assigned groups auto-registered into the Autopilot service.
Screenshot: The 'Convert all targeted devices to Autopilot' toggle on the Basics tab, shown set to No. (captured during a live customer build — coming to this page)
Why: Set to Yes, it registers every corporate, non-Autopilot device in the assigned groups. Handy for bulk onboarding, but the registration is sticky.
Don’t: Do not flip this to Yes on a group that also holds devices you never intend to wipe. Removing the profile later will not un-register them; you must delete each device from the Autopilot service by hand.
On a schedule: Registration triggered this way can take up to 48 hours to process.
Step 4. Select Next to reach the Out-of-box experience (OOBE) page. For Deployment mode, choose User-driven (the user signs in during OOBE and the device is tied to them) or Self-deploying (no user, for kiosks, shared or single-purpose devices). Set 'Join to Microsoft Entra ID as' to Microsoft Entra joined.
Screenshot: The OOBE page with the Deployment mode dropdown open, and 'Join to Microsoft Entra ID as' set to Microsoft Entra joined. (captured during a live customer build — coming to this page)
Why: User-driven is the usual choice for staff laptops. Self-deploying needs a TPM 2.0 that supports attestation, and applies only device-targeted compliance policies since there is no user to evaluate.
Watch for: Options that appear greyed out for your chosen mode are simply not supported in that mode. That is expected behaviour, not a fault.
Step 5. Configure the rest of the OOBE page: Microsoft Software License Terms (Hide), Privacy settings (Hide), Hide change account options (Hide), User account type (Standard user for most staff), Allow pre-provisioned deployment, Language (Region) with Automatically configure keyboard, and Apply device name template.
Screenshot: The lower half of the OOBE page showing User account type, Allow pre-provisioned deployment, Language (Region), and the device name template field. (captured during a live customer build — coming to this page)
Why: User account type is the setting people regret. Leave it as Standard user unless a person genuinely needs local admin, because Administrator adds the enrolling user to the local Administrators group.
Watch for: Hiding Privacy settings disables location services by default; if you need location, re-enable it with a separate Intune policy. 'Hide change account options' only takes effect once company branding is configured in Entra ID.
Don’t: Do not use spaces, a name over 15 characters, or an all-numbers value in the device name template. Use the %SERIAL% or %RAND:x% macro for uniqueness.
Step 6. Select Next to Assignments. Choose 'Selected groups', select 'Select groups to include', and add your dynamic Autopilot device group. Then Next.
Screenshot: The Assignments page with 'Selected groups' chosen and the dynamic Autopilot device group listed under Included groups. (captured during a live customer build — coming to this page)
Watch for: Assign the profile to a device group, not a user group. Autopilot deployment profiles target devices.
Don’t: Do not combine the All Devices assignment with any exclusion group. Exclusions are unsupported with All Devices and can corrupt assignment, sometimes forcing you to re-upload device hashes.
Step 7. On Review + Create, select Create. Then return to Windows Autopilot > Devices and watch the Profile Status column move from Unassigned to Assigning to Assigned. Open the device and confirm 'Date assigned' is populated.
Screenshot: The Windows Autopilot devices list with the Profile Status column reading Assigned, and the device flyout showing a populated Date assigned value. (captured during a live customer build — coming to this page)
Why: A device will not run your custom OOBE until the profile is genuinely Assigned with a date stamped. Start OOBE earlier and the machine gets the default profile or a half-configured experience.
Watch for: If Profile Status stays stuck on Unassigned, the device is almost certainly not in the assigned group yet. This is the single most common Autopilot trap, and it is a group problem, not a profile problem.
On a schedule: Assignment can take anywhere from minutes to a few hours depending on group evaluation and service processing. Do not begin OOBE until it reads Assigned.
Step 8. Now build the Enrollment Status Page. Still under Devices > Windows > Enrollment, in the Windows Autopilot section select Enrollment Status Page, then Create. Give it a Name and Description on Basics, then Next.
Screenshot: The Enrollment Status Page list with the Create button, and the new profile's Basics tab with Name and Description. (captured during a live customer build — coming to this page)
Why: The ESP is a separate profile from the deployment profile. The deployment profile shapes OOBE; the ESP gates it. You need both for a controlled first-run.
Watch for: There is always a Default ESP profile applied to all devices and users. Your new profile must out-prioritise it (step 12) or the Default wins and your settings never appear.
Step 9. On the Settings tab, set 'Show app and profile configuration progress' to Yes to reveal the remaining options. Set the timeout under 'Show an error when installation takes longer than specified number of minutes' (default 60; raise to 90 or more for large apps or slow links). Set 'Show custom message when time limit or error occur' to Yes with a support contact, and set 'Turn on log collection and diagnostics page for end users' to Yes.
Screenshot: The ESP Settings tab showing Show progress = Yes, the timeout minutes box, the custom message text, and log collection = Yes. (captured during a live customer build — coming to this page)
Why: The custom message and log collection are what stand between a stuck user and a blind support call. A user who can read who to ring and can tap Collect logs is far cheaper to help.
Step 10. Set 'Only show page to devices provisioned by out-of-box experience (OOBE)' to Yes so the page does not reappear for every later user sign-in. Set 'Block device use until all apps and profiles are installed' to Yes for a locked-down first run, then decide whether to allow 'Allow users to reset device if installation error occurs' and 'Allow users to use device if installation error occurs'.
Screenshot: The ESP Settings showing 'Only show page to devices provisioned by OOBE' = Yes, 'Block device use until all apps and profiles are installed' = Yes, and the two Allow users toggles. (captured during a live customer build — coming to this page)
Why: Blocking delivers a clean, fully configured desktop at first login. The reset and use escape hatches decide how stuck a user can get if provisioning fails, balance user rescue against leaving a half-built device in their hands.
Watch for: Blocking set to Yes with a long or fragile app list is the classic cause of ESP timeouts (error 0x800705B4, 'installation took longer than expected'). Keep the blocking scope lean.
Step 11. For 'Block device use until these required apps are installed if they are assigned to the user/device', choose Selected, then Select apps and pick only the handful that must be present before first use. If you use pre-provisioning, review 'Only fail selected blocking apps in technician phase'.
Screenshot: The Blocking apps flyout with Selected chosen and a short list of essential apps added. (captured during a live customer build — coming to this page)
Why: This list only filters which required apps the ESP waits on; it does not deploy anything. Apps not on the list still install, the ESP simply does not block on them.
Watch for: You can pick up to 100 apps, but every extra blocking app adds to the timeout clock. Three or four genuine essentials is usually plenty.
Don’t: Do not mix line-of-business (MSI) apps and Win32 apps as blocking apps. Both use TrustedInstaller and collide, failing the ESP with 'Another installation is in progress, please try again later'.
Step 12. On Assignments, add the same dynamic Autopilot device group (device-targeted), complete Scope tags if you use them, then Review + create. If you run more than one ESP profile, drag this one above the Default so it wins on priority. Finally, reset a test device and walk it through OOBE end to end.
Screenshot: The ESP profile list showing your profile positioned above Default in the priority order, and a test device partway through the Enrollment Status Page during OOBE. (captured during a live customer build — coming to this page)
Why: In self-deploying and pre-provisioning there is no user, so only device-targeted ESP profiles apply. Assigning to a user group would silently do nothing in those modes.
Watch for: A lower priority number means higher priority; the profile set to 1 wins. The Default profile is the fallback used only when nothing else is assigned.
On a schedule: Newly assigned ESP settings apply at the next device check-in, so a real end-to-end OOBE run on a test device is the only true confirmation the profile and ESP behave as intended.
Assignment can take anywhere from minutes to a few hours depending on group evaluation and service processing. Do not begin OOBE until it reads Assigned.
Newly assigned ESP settings apply at the next device check-in, so a real end-to-end OOBE run on a test device is the only true confirmation the profile and ESP behave as intended.
If it goes wrong
The failures people actually hit on this process, each with the diagnosis and fix:
Autopilot ESP: only fail selected blocking apps — Stop the Enrollment Status Page waiting for every app: selected blocking apps, the technician-phase toggle, and the timeout maths for large apps.