Why the profile arrives and the script does not
They travel on different channels, and only one of them is fast. A configuration profile is delivered by macOS device management itself. It arrives on the device’s normal check-in — usually minutes. An install script is not. Your MDM’s own scripting agent runs it, and on macOS that agent is a separate piece of software that has to be installed on the Mac first. Assigning your first script is what triggers that install. Once present, the agent checks in on its own schedule, independently of device management — in Microsoft Intune, up to 8 hours. So for some hours after you assign a script, “no status” is the normal, healthy state. It is not evidence that anything is wrong.Decide which problem you have
Nothing has run yet
1
Give it the first check-in
Wait out the agent’s own check-in window — up to 8 hours on Intune — with
the Mac awake and online. Most fleets see the first run well before that.
2
Force a check-in on one test device
On Intune, open Company Portal on the Mac, select the device, and choose
Check status. That triggers both a device-management check-in and an
agent check-in.If Company Portal is not installed — common on Macs enrolled without a
primary user — restart the agent from Terminal instead:It restarts immediately and checks in.
3
Confirm the agent is actually installed
4
Read the agent's own log
It runs and fails at once
The installer installs a signed package, so it must run as root. In Intune, open the script policy and check Run script as signed-in user. Its default is No, which is what you want — the script runs as root. Set to Yes, it runs as the signed-in user instead. Unless that account can already elevate without being prompted for a password, the installer stops before downloading anything and reports a failure — every device, every time. It checks first on purpose, so a run that was going to fail does not transfer several hundred megabytes to find out. On a Mac whose signed-in account does have passwordless administrator rights the install still succeeds, which is why the setting can look inconsistent across a fleet: fix the setting rather than the devices that happen to work. On any other MDM, find the equivalent setting in your vendor’s documentation and confirm the script runs with root privileges before looking further.A script assigned as a signed-in-user script also reports its result under
User status rather than Device status. On a Mac enrolled without a
primary user there is no user for it to report against, so both views can look
empty even though the script did run.
Your MDM rejects the script
If your MDM console shows a generic error when you open or save the script policy — with no useful detail, and a support identifier that is all zeros — the problem is the script content, not the device. Two things fix it:- Assign the short install command, not the installer it downloads. The campaign gives you a two-line command; that is what belongs in the script field. The full installer is long and contains formatting characters that script editors do not reliably preserve.
- Create a new script policy rather than editing the broken one. Editing content resets the run state anyway, and a fresh policy avoids the record the MDM console is failing on.
When to escalate
Collect these before contacting support:- The script policy’s run status, and how long ago it was assigned.
- Whether the agent exists at
/Library/Intune/Microsoft Intune Agent.app. - The last 100 lines of
/Library/Logs/Microsoft/Intune/IntuneMDMAgent*.log. - Whether Run script as signed-in user is set to No.
- If the script did run:
/var/log/agenshield-install.logfrom the Mac.