'Awaiting final configuration': what holds the screen, how long is normal, and how to unstick a Mac

Intune's Await Final Configuration setting locks a Mac at the end of Setup Assistant for as long as the enrolment-time payload takes to land — and Microsoft sets no upper limit. Here is what actually holds the screen, how to shrink it, and what to do when a device never releases.

The problem

You enrol a Mac through Apple Business Manager and Microsoft Intune, the user works through Setup Assistant, and then — just before the desktop should appear — the screen locks on "Awaiting final configuration". There is nothing to click and no meaningful progress indicator. On one device it clears quickly; on the next it sits and sits; occasionally it never releases at all, and the only escape is a wipe.

You hit this when the enrolment policy's Await final configuration setting is Yes — the default for new Intune macOS enrolment policies, and silently forced on whenever the policy configures local admin or user accounts (Microsoft's documentation notes that in that case it is "always enabled in the background"). The screen is not a bug: Intune is deliberately holding the device until its enrolment-time policies install. The pain is that Microsoft sets no upper bound on the hold, and most tenants assign far more to the device at enrolment than the locked phase was designed to carry.

Why it happens

With Await final configuration enabled, Setup Assistant pauses just before the home screen loads and lets Intune check in. The lock holds while the device downloads the configuration policies and apps assigned to it. Microsoft's documentation is explicit that the duration is a function of payload size:

"The amount of time that users are held on the Awaiting final configuration screen varies, and depends on the total number of policies and apps you assign to the device. […] The more policies and apps assigned, the longer the waiting time. Setup Assistant and Intune don't enforce a minimum or maximum time limit during this portion of setup."
— Microsoft Learn, Set up automated device enrollment (ADE) for macOS

Three details in that paragraph do the damage:

• Everything targeted at the device counts. If your security baseline, your app estate and your nice-to-haves are all assigned to All devices or a broad device group, the entire pile becomes enrolment-blocking payload.
• There is no timeout. A payload that cannot finish holds the screen indefinitely. Microsoft's own product validation says only that "most devices we tested were released and able to access the home screen within 15 minutes" — an observation, not a ceiling.
• Assignment resolution is asynchronous. Dynamic Microsoft Entra device groups (for example, membership rules keyed on enrollmentProfileName) evaluate on their own schedule. A freshly enrolled device can join groups mid-enrolment, dragging extra payload into the locked phase — or miss its baseline entirely on the first pass.

The permanently stuck case is usually different in kind: a broken network path (captive portal, TLS-inspecting proxy, blocked Apple Push Notification service), an enrolment that failed after the MDM profile landed, or a single wedged profile. Reports of devices that never release go back years on Apple's own community forums.

The fix

1. Shrink what blocks: split enrolment-time from post-login

1. Use a static enrolment-time group. The macOS enrolment policy's Device group setting (enrolment-time grouping) accepts only static Microsoft Entra security groups — deliberately. Devices land in the group at enrolment, before any dynamic evaluation has a chance to lag.
2. Assign only the security-critical baseline to that group: FileVault, firewall, password and compliance policy, platform SSO, the Company Portal app. The test for each item is "must this be in place before a user can touch the desktop?" If not, it does not belong in the locked phase.
3. Let the long tail flow after first login. Target the bulk of apps and convenience configuration at user groups, make apps available in Company Portal rather than required on the device, or use groups the device joins later. The user reaches a working desktop and the rest arrives in the background.
4. Prefer assignment filters over dynamic device groups for enrolment-relevant targeting. Filters are evaluated when the device checks in; dynamic group membership is calculated separately and can lag a fresh enrolment, which either delays the baseline or pulls extra payload into the lock.
5. Decide whether you need the lock at all. Setting Await final configuration to No releases devices to the desktop regardless of policy state — acceptable for low-risk fleets, a compliance and Conditional Access gap for others. Note the trap: if the policy configures local admin or user accounts, the setting is forced on in the background, so switching it to No changes nothing.

2. How long is too long: triage the stuck Mac

The thresholds below are working rules of thumb — the only sourced anchor is Microsoft's 15-minute validation observation, and Intune enforces no limit in either direction.

Working through a genuinely stuck device:

1. Restart the Mac. Hold the power button, then start it again. Setup Assistant resumes where it left off and triggers a fresh Intune check-in; transient check-in failures often clear on the retry.
2. Rule out the network path. The device needs the Apple Push Notification service (TCP 5223, falling back to 443, to Apple's 17.0.0.0/8 range) and the Intune service endpoints. Captive portals and TLS-inspecting proxies break both. Re-test on a phone hotspot or a clean VLAN — if it releases there, the fix is a firewall or proxy exception, not an Intune one.
3. Check the tenant from another machine. In the Intune admin centre, confirm the ADE token is valid and that the device record actually appeared and shows as enrolled. If the record never arrived, enrolment itself failed and waiting will not help.
4. Erase and re-enrol with a trimmed payload. On Apple silicon and T2 Macs running macOS Monterey or later, use Erase All Content and Settings; otherwise reinstall from macOS Recovery. Before re-running Setup Assistant, cut the enrolment-time assignments to the baseline — re-enrolling into the same over-assignment reproduces the hang.
5. Bisect if it still reproduces. If a lean baseline still hangs, a specific profile is wedging. Enrol with the minimum, then add assignments back in batches until the hang returns — the last batch added contains the culprit.

How Decolla handles it

Straight answer first: Decolla provisions Windows devices over your own Intune and Autopilot tenant — it does not manage Macs, so it cannot release a Mac held at this screen. The steps above are the fix for the machine in front of you.

This article lives on our site because the failure mode is identical on the Windows side, where we work: the Enrollment Status Page holds a Windows device during OOBE for exactly the same reason — everything targeted at the device competes for the blocking phase, and over-assignment turns provisioning into limbo. Decolla's build plans are designed around the split this article describes. The wizard produces a written, itemised plan — drawn from a curated catalogue of 260+ items across 21 sections — in which every item declares its delivery method and reversibility class before anything runs, with the blocking phase carrying the security-critical minimum and the long tail landing after first sign-in. You approve the plan before deployment starts, so "what exactly is the device waiting for?" is never a mystery: it is a named list. Decolla is currently pre-launch, with a waitlist at decolla.app.

Sources

• Microsoft Learn — Set up automated device enrollment (ADE) for macOS (Await final configuration)
• Apple Support Communities — device stuck at "Awaiting final configuration"