Diagnosing & Fixing Slow or Failed App/Script Installs During macOS ADE Enrollment in Intune

If you run a macOS fleet through Automated Device Enrollment (ADE) at any real scale, you've seen this ticket: a MacBook comes out of Setup Assistant, the user logs in, and then… nothing. Required apps sit in "Pending" for two hours. Sometimes twelve. Sometimes the shell script that's supposed to rename the machine and join it to the right Entra group never runs at all. This is not a bug you patch — it's a symptom of four or five architectural decisions colliding, and almost every case I've triaged in production traces back to one of a small set of root causes: APNs reachability, assignment scoping against the wrong principal, or check-in interval mechanics that admins assume behave like Windows Autopilot ESP. They don't.

The Three-Phase Enrollment Reality

Every "slow install" incident on macOS ADE decomposes into three distinct phases, each with its own failure modes. Diagnosing the wrong phase is the single biggest time-waster in support escalations — engineers spend hours staring at app assignment blades when the actual problem is that the device never received an APNs wake signal in the first place.

Root Cause #1 — APNs Is the Single Point of Failure You're Not Watching

macOS doesn't use a persistent WNS-style channel the way Windows does. Every "go check in now" nudge from Intune to a Mac rides on Apple Push Notification service. If your egress firewall or proxy is doing TLS inspection or blocking the 17.0.0.0/8 range on ports 443, 2195, 2196, and 5223, the push simply never arrives. The device doesn't error — it just silently falls back to its default MDM check-in interval, which on macOS can be several hours. This is functionally indistinguishable from "app install is slow" to the end user, but it's actually "the device has no idea it has new work to do."

Root Cause #2 — Assignment Scoped to User Group Instead of Device Group

This is the most common misconfiguration, full stop. During Setup Assistant, there is no signed-in user context yet — Entra ID user-group membership cannot be evaluated until the user authenticates post-enrollment (or, in some ADE flows, until account-driven enrollment binds identity). If your Required app or platform script is assigned to a user group, it will not install during the pre-login window, and depending on your build sequence, it may not install for a long time afterward either, since group membership evaluation itself has propagation latency in Entra ID (typically under an hour, but combined with the next MDM check-in cycle it compounds).

Root Cause #3 — Serial Script Execution & No Native Dependency Chaining

Intune's macOS platform scripts and shell script policies do not have Win32-style detection rules, supersedence, or dependency graphs. They run in whatever order the client processes the assigned policy set, which is not guaranteed to match your intended sequence. If Script B assumes Script A already installed Rosetta or a helper binary, and B runs first, it fails — often silently, since exit codes aren't always surfaced clearly to the admin without explicit Graph queries.

Diagnostic Walkthrough

1. Check device-level app status. Intune admin center → Devices → All devices → filter OS macOS → select device → Managed apps. Look for install state Pending vs Failed vs Not applicable. "Not applicable" almost always means an assignment scope mismatch (wrong OS filter or wrong group type).
2. Confirm assignment group type on the app itself. Apps → All apps → select app → Properties → Assignments → click into the Required group and verify in Entra ID whether it's a Security group with Device members or User members. This is the #1 five-minute check that resolves half of these tickets.
3. Pull platform script run state. Devices → Scripts and remediations → Platform scripts → select script → Device status. Cross-reference "Last check-in" against "Script run time" — a large gap confirms an APNs/check-in delay, not a script execution failure.
4. Validate the APNs certificate hasn't lapsed. Devices → Enrollment → Apple MDM Push certificate → check expiration. An expired cert doesn't cause slow installs — it causes total enrollment failure for every device attempting ADE that day. Rule it out immediately, then move to network-level checks.
5. Validate egress reachability from the actual network segment the device enrolls on (VLAN matters — many orgs have a clean corporate VLAN but a locked-down "onboarding" VLAN for new devices that hasn't been updated with the same firewall exceptions).
6. Correlate with local device logs if you have physical or remote-hands access:

   sudo log stream --predicate 'subsystem == "com.apple.ManagedClient"' --info
   sudo log show --predicate 'subsystem == "com.apple.mdmclient"' --last 1h
   sudo profiles status -type enrollment

Graph API Reference Calls

Device-level app install status and shell script run-state reporting are exposed primarily on the beta Graph endpoint. There is no v1.0 equivalent for per-device granularity as of this writing — plan your automation accordingly and don't ship beta dependencies into change-controlled production runbooks without a documented exception.