Setup guide · from scratch
Create the Apple ADE enrolment policy (out-of-box experience)
This policy controls what a corporate iPhone/iPad shows during first-boot setup and locks it to management. Set it as the token's Default Policy or synced devices fail with 'Invalid Profile'.
≈ 15 min
Apple — iPhone, iPad & Mac · step 4 of 12 · ≈ 15 min‹ PreviousNext ›
Do these first — this guide assumes you already have:
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 15 min of clicking, every build. The Decolla way: part of one tenant connect, then automatic.
Before you start
- A valid ADE enrolment program token already created in Intune - this policy hangs off it and cannot exist without one.
- Intune Administrator credentials.
- A decision already made: user-affinity (personal-to-user) or shared/kiosk - it shapes the entire policy and can't be flipped later without a wipe.
- If you want enrolment-time grouping, a STATIC Entra security group ready - dynamic groups don't evaluate in time for first-boot.
The steps
- In Intune go to Devices > Enrollment > Apple mobile tab > Enrollment program tokens…
- Click 'Enrollment policies' (the new experience, not the retiring 'Profiles'), then…
- On Basics give it a Name/Description (admin-only), Next.
- Optionally pick a STATIC Entra security group for enrolment-time grouping, Next.
- Choose User Affinity: 'Enroll with User Affinity' (personal-to-user, gets Company…
- If user affinity, set authentication to 'Setup Assistant with modern…
- Set Supervised = Yes, Locked enrollment = Yes, Await final configuration = Yes.
- Optionally set a device name template such as {{DEVICETYPE}}-{{SERIAL}}.
- Under Setup Assistant, set each of the ~40 panes to Show or Hide (hide…
- Back on the token click 'Set Default Policy' and choose this policy so every synced…
- Confirm Enrollment Restrictions > Device Type Restrictions does not block iOS, or…
0 of 11 done
Step 1. In Intune go to Devices > Enrollment > Apple mobile tab > Enrollment program tokens and pick your token.
Screenshot: Token selected under Enrollment program tokens (captured during a live customer build — coming to this page)
Why: An enrolment policy always belongs to one token - it only ever reaches devices assigned to that token's MDM server in ABM.
Watch for: No token listed here? The ADE token step isn't finished, and a policy has nothing to attach to until it exists.
Step 2. Click 'Enrollment policies' (the new experience, not the retiring 'Profiles'), then 'Create policy' > iOS/iPadOS.
Screenshot: Create policy iOS/iPadOS Basics tab (captured during a live customer build — coming to this page)
Why: 'Enrollment policies' is the replacement for the legacy 'Profiles' node - same purpose, but it's where new Setup Assistant settings now appear first.
Don’t: Do NOT build this under the retiring 'Profiles' node - work there and you'll be maintaining an object Microsoft is winding down.
Step 3. On Basics give it a Name/Description (admin-only), Next.
Screenshot: Basics name/description fields (captured during a live customer build — coming to this page)
Why: These fields are admin-facing only - the user never sees them, so encode the intent (e.g. 'iOS - User Affinity' vs 'iOS - Shared') so the next admin isn't left guessing.
Step 4. Optionally pick a STATIC Entra security group for enrolment-time grouping, Next.
Screenshot: Device group step (captured during a live customer build — coming to this page)
Why: This stamps group membership at enrolment, so device-targeted config and apps can hit the device the instant it appears.
Don’t: Do NOT point this at a DYNAMIC group - it won't have evaluated in time for first-boot, and everything you targeted at it silently misses the new device.
Step 5. Choose User Affinity: 'Enroll with User Affinity' (personal-to-user, gets Company Portal) or 'without' (kiosk/shared).
Screenshot: User Affinity selector (captured during a live customer build — coming to this page)
Why: Affinity binds the device to one user so per-user apps, mail and Company Portal work; 'without' is for shared or kiosk kit that nobody owns.
Watch for: This isn't a toggle you revisit - flipping affinity later means wiping and re-enrolling every affected device.
Don’t: Do NOT choose affinity for shared or single-purpose devices - you'll force a personal sign-in onto kit that has no owner.
Step 6. If user affinity, set authentication to 'Setup Assistant with modern authentication'.
Screenshot: Authentication method dropdown (captured during a live customer build — coming to this page)
Why: Modern authentication runs the user through Entra sign-in - MFA and Conditional Access included - during Setup Assistant, not the legacy basic prompt.
Watch for: The device lands enrolled but registration only completes once Company Portal is installed and the user signs in - so Company Portal must be assigned to these devices.
Don’t: Do NOT fall back to the legacy authentication option if you depend on MFA or Conditional Access - it can't enforce either.
Step 7. Set Supervised = Yes, Locked enrollment = Yes, Await final configuration = Yes.
Screenshot: Supervised / Locked enrollment / Await toggles (captured during a live customer build — coming to this page)
Why: Supervised unlocks the supervised-only controls (hard restrictions, silent app install, web content filtering); Locked enrollment stops the user stripping management from Settings; Await holds first-boot until your day-one config lands.
Watch for: 'Await final configuration' is exactly what strands a device on 'Awaiting final configuration' if an assigned policy or app never completes - keep the day-one payload lean and reliable.
Don’t: Do NOT ship corporate devices with Locked enrollment off - the user can then remove the MDM profile in Settings and walk away unmanaged.
If this step errors: Intune iOS restrictions not applying? Check supervision
If this step errors: Mac stuck at 'Awaiting final configuration' in Intune
If this step errors: Activation Lock: save the bypass code before you wipe
Step 8. Optionally set a device name template such as {{DEVICETYPE}}-{{SERIAL}}.
Screenshot: Device name template field (captured during a live customer build — coming to this page)
Why: Stamps every device with a predictable, unique hostname at enrolment instead of a wall of identical 'iPhone' entries.
Watch for: The name is applied once at enrolment - changing the template later does not rename devices already out in the field.
Step 9. Under Setup Assistant, set each of the ~40 panes to Show or Hide (hide Passcode/Apple ID panes on iOS 14.5+), then Next > Create.
Screenshot: Setup Assistant Show/Hide pane list (captured during a live customer build — coming to this page)
Why: Every pane you Hide is one fewer screen the user taps through - this is where the 'ready to work out of the box' experience is actually built.
Watch for: Hiding the Passcode pane does not mean 'no passcode' - if a compliance or configuration policy requires one, iOS still enforces it, just after setup rather than during it.
Step 10. Back on the token click 'Set Default Policy' and choose this policy so every synced device gets it automatically.
Screenshot: Token overview with 'Set Default Policy' (captured during a live customer build — coming to this page)
Why: This is the step that makes the policy do anything - a synced device with no Default Policy has no profile to receive and fails with 'Invalid Profile'.
Watch for: Easily the most-missed step: the policy exists and looks done, but nothing uses it until it's set as the token's Default.
Don’t: Do NOT assume creating the policy was enough - an unset Default Policy is the classic 'I built the profile but devices still error' cause.
Step 11. Confirm Enrollment Restrictions > Device Type Restrictions does not block iOS, or ADE shows 'Invalid Profile'.
Screenshot: Device Type Restrictions allowing iOS (captured during a live customer build — coming to this page)
Why: Device Type Restrictions are checked at enrolment - block iOS/iPadOS there and the whole ADE flow dies, however perfect the policy is.
Watch for: A hardened tenant may block the iOS platform or personally-owned devices - ADE devices are corporate-owned, so confirm the platform itself is allowed, not just the ownership type.
If it goes wrong
The failures people actually hit on this process, each with the diagnosis and fix:
- Intune iOS restrictions not applying? Check supervision — Half of Intune's iOS restrictions only apply to supervised devices. See the supervised-only capability split, how to check, and why the fix needs a wipe.
- Mac stuck at 'Awaiting final configuration' in Intune — Why Intune's Await Final Configuration locks the Mac after Setup Assistant, how long is normal, how to trim the enrolment payload, and triage when stuck.
- Activation Lock: save the bypass code before you wipe — Activation Lock survives a wipe and Intune's bypass code dies with the device record. The offboarding order that stops a returned iPhone being a brick.
‹ Create the Apple ADE (Automated Device Enrolment) program tokenDownload the Apple location (VPP content) token from ABM ›
See it on a real device.
Decolla is in private build — early-access members see a build defined, deployed and rolled back first.
Get early access