macOS MDM Command Reference

This reference exists so the other guides on this site can stop re-explaining the same eight or nine commands. They show up everywhere — browser policy verification, FileVault troubleshooting, PPPC investigation, any time you need to know what your MDM has actually delivered to a Mac. The trick is to learn them as patterns rather than memorising specific incantations. Most of these commands have one variable part and a lot of boilerplate; once the shape is clear you can apply them to anything.

Settings delivered by Jamf Pro and Microsoft Intune both land in the same place on the device, so everything here works identically regardless of which MDM owns the Mac. The variable parts of each command are highlighted in orange.

1. Reading Any Managed Preference

An MDM writes its policy values into /Library/Managed Preferences/ as plist files, one per preference domain — the reverse-DNS identifier for the application or service the settings belong to.

defaults read /Library/Managed\ Preferences/<preference-domain>.plist

If the domain is not currently managed, the command returns "Domain ... does not exist". That itself is useful information — it means nothing is currently managing that setting, so you have a clean slate before pushing your own policy.

# Browsers
defaults read /Library/Managed\ Preferences/com.google.Chrome.plist
defaults read /Library/Managed\ Preferences/com.google.Keystone.plist
defaults read /Library/Managed\ Preferences/com.brave.Browser.plist
defaults read /Library/Managed\ Preferences/com.microsoft.Edge.plist
defaults read /Library/Managed\ Preferences/org.mozilla.firefox.plist

# Microsoft AutoUpdate (manages Office and Edge updates)
defaults read /Library/Managed\ Preferences/com.microsoft.autoupdate2.plist

# Common Apple-managed domains
defaults read /Library/Managed\ Preferences/com.apple.applicationaccess.plist
defaults read /Library/Managed\ Preferences/com.apple.SoftwareUpdate.plist
defaults read /Library/Managed\ Preferences/com.apple.security.firewall.plist
defaults read /Library/Managed\ Preferences/com.apple.MCX.FileVault2.plist

Reading a single key from within a domain

defaults read /Library/Managed\ Preferences/<domain>.plist <key-name>

defaults read /Library/Managed\ Preferences/com.google.Chrome.plist RelaunchNotificationPeriod

2. Inspecting Profiles Delivered by MDM

These commands work above the level of any one preference domain, looking at the configuration profiles themselves.

# Full content of every installed profile (long)
sudo profiles show -all

# Short list of installed profiles
sudo profiles list

# MDM enrolment status
sudo profiles status -type enrollment

# Search the full output for any term
sudo profiles show -all | grep -i "<search-term>"

sudo profiles show -all | grep -i "microsoft"
sudo profiles show -all | grep -i "filevault"
sudo profiles show -all | grep -i "autoupdate"

# For longer investigations: dump once, grep many times
sudo profiles show -all > /tmp/profiles_dump.txt
grep -i "edge" /tmp/profiles_dump.txt
grep -i "wifi" /tmp/profiles_dump.txt

3. Forcing a Check-in

After making a change in your MDM console, the device may take up to around eight hours to pick it up on its own schedule. To trigger a sync immediately:

sudo jamf recon     # update inventory
sudo jamf mdm       # pull configuration from MDM
sudo jamf policy    # run any pending Jamf policies (not just MDM)

sudo profiles renew -type enrollment

You can also open the Company Portal app, click the device, and choose Check Status or Sync.

4. Investigating the Source of an Existing Setting

When the managed-preferences check reveals a domain you did not expect, work outward from the file to find which profile delivered it.

# File metadata: timestamp and ownership
ls -la "/Library/Managed Preferences/<preference-domain>.plist"
stat "/Library/Managed Preferences/<preference-domain>.plist"

# User-level file with the same name (written by the app itself, not the MDM)
ls -la ~/Library/Preferences/<preference-domain>.plist

# Hunt for the source profile in the full profiles dump
sudo profiles show -all > /tmp/profiles_dump.txt
grep -i "<search-term>" /tmp/profiles_dump.txt

What the output tells you

The modification date tells you how long the policy has been there — a date from your last fleet rollout, an Office deployment, or a security project are all clues to which team owns it. Root ownership confirms the file is MDM-managed rather than something set locally. A user-level file with the same name is normal: it is the application's own state, a different file with a different purpose.

For the definitive source, the MDM console is faster than command-line archaeology. Open the device record and read through the list of profiles scoped to it.

5. Confirming What Applications Are Installed

Useful before deploying app-specific policies. The pattern is just list /Applications and filter, which generalises to whatever you need to find.

ls /Applications | grep -i -E "<app1>|<app2>|<app3>"

# Browsers
ls /Applications | grep -i -E "chrome|brave|firefox|edge"

# Microsoft suite
ls /Applications | grep -i -E "outlook|teams|word|excel|powerpoint"

# Security tools
ls /Applications | grep -i -E "defender|crowdstrike|sentinel|jamf"

Include /Applications/Utilities in the search if you need to:

ls /Applications /Applications/Utilities | grep -i "<app-name>"

6. Application-Level Policy Verification

The device-level defaults read only confirms the MDM delivered the policy. To confirm the application is actually honouring it, every modern browser exposes an internal policy page. The same idea exists for a few other apps too.

For non-browser applications, check the vendor's documentation for an equivalent diagnostic view. Otherwise the proxy test is functional: change a setting in the MDM, force a check-in, and see if the app's behaviour changes accordingly.

7. Validating a .mobileconfig Before Uploading

A malformed .mobileconfig fails silently in Intune and in many other contexts. The simplest sanity check is whether the file parses as a valid plist at all, which catches the most common issues such as mismatched tags or missing closing elements.

plutil -lint <path-to-file>.mobileconfig

plutil -lint ~/Downloads/browser-update-policy.mobileconfig

A response of OK means the file is structurally valid. Anything else is the parser telling you exactly where it broke (line number, expected tag, etc).

For deeper inspection, convert the file to a readable representation:

plutil -convert xml1 -o - <path-to-file>.mobileconfig

The -o - writes the converted output to stdout rather than overwriting the original file.

8. FileVault Diagnostics

A small but commonly-needed cluster of read-only commands. These are all safe to run; anything that changes FileVault state is a different category and should be approached deliberately.

# Overall FileVault status
fdesetup status

# Volume-level encryption / decryption progress
diskutil apfs list

# Which users are enabled for FileVault on this Mac
fdesetup list

# Whether a specific user holds a SecureToken
sysadminctl -secureTokenStatus <username>

9. File Locations at a Glance

10. Note on Permissions

Most read commands work without sudo, but a few profile-related ones require it (profiles show -all, profiles status, anything writing to system paths). When in doubt, prefix with sudo — the worst case is a re-prompt for your password. Read commands that touch your own user-level files in ~/Library/Preferences/ never need elevated privileges.

---

Closing Thoughts

Almost every macOS MDM problem comes down to the same few questions. What is the device currently configured with? Which profile delivered that configuration? Is the application actually honouring it? Has my latest change synced down yet? The commands above answer all of those, and the patterns generalise to whatever app or setting you happen to be debugging. Bookmark this page; the rest of the guides on this site will keep pointing back to it whenever they mention reading a preference or forcing a check-in, rather than re-explaining the basics every time.

← All guides