Checklist
Defender for Endpoint via Jamf Pro checklist
Based on the article: Deploy Microsoft Defender for Endpoint on Macs with Jamf Pro (and fix mdatp health errors) · 5 min read
Deploying Microsoft Defender for Endpoint to Jamf-managed Macs is mostly about order: an onboarding profile, a settings profile and a set of Apple permission profiles must all land before the package. Get it wrong and users see approval prompts or the sensor reports itself unhealthy. In this post I'll follow Microsoft's Jamf Pro procedure, add a smart group that enforces the order, and decode the mdatp health errors you're most likely to meet.
Before you start
- Defender for Endpoint Plan 1 or Plan 2, and a Defender portal role that can onboard devices.
- A separate Jamf Pro subscription, with rights to create configuration profiles, policies, packages, scripts and smart computer groups. Microsoft documents the Jamf route but doesn't provide troubleshooting support for Jamf Pro itself.
- Macs that meet the Defender for Endpoint on macOS prerequisites for OS version and network access. Deploying with Intune instead? See Onboarding macOS to Defender for Endpoint with Intune.
Checklist
- 1
Download the packages
In the Microsoft Defender portal, open Settings › Endpoints › Device management › Onboarding, select macOS, connectivity type Streamlined and deployment method Mobile Device Management / Microsoft Intune. That's the right choice for Jamf too: the package includes a
jamffolder. - 2
Create the onboarding profile
In Jamf Pro, create a computer configuration profile with an Application & Custom Settings payload: level Computer Level, distribution Install Automatically, preference domain
com.microsoft.wdav.atp, with the onboarding plist uploaded. Scope it to your target computer group. - 3
Choose where Defender's settings come from
- Defender portal: macOS endpoint security policies (Microsoft Defender Antivirus and Endpoint detection and response templates) through security settings management. They take precedence over conflicting Jamf settings.
- Jamf Pro GUI: download Microsoft's
schema.json; in an Application & Custom Settings payload choose External Applications, source Custom Schema, upload it and use preference domaincom.microsoft.wdav. Usecom.microsoft.wdav.extonly for settings not yet in the schema. - Legacy plist: upload the Jamf variant of Microsoft's sample, not the Intune one, which Jamf Pro rejects. Set
passiveModeto true if another antivirus stays, and remove the EICAR entry fromallowedThreatsif you'll test with EICAR.
bashcurl -o ~/Documents/schema.json https://raw.githubusercontent.com/microsoft/mdatp-xplat/master/macos/schema/schema.json - 4
Upload the permission profiles
Download Microsoft's maintained profiles from the Defender for Endpoint macOS repository rather than rebuilding payloads by hand, upload each to Jamf Pro and scope it to the same group:
Profile What it does notif.mobileconfigNotifications for com.microsoft.wdav.trayandcom.microsoft.autoupdate2MAU plist, domain com.microsoft.autoupdate2Update channel; Microsoft's sample sets ChannelNameto Current andHowToCheckto AutomaticDownloadfulldisk.mobileconfigFull Disk Access for com.microsoft.wdav,com.microsoft.wdav.epsextandcom.microsoft.dlp.daemonsysext.mobileconfigApproves com.microsoft.wdav.epsextandcom.microsoft.wdav.netext, Team IDUBF8T346G9netfilter.mobileconfigThe Microsoft Defender Content Filter (socket filter com.microsoft.wdav.netext)background_services.mobileconfigLets Defender's daemons run in the background (macOS 13 and later) bluetooth.mobileconfigOnly for Bluetooth device control (macOS 14 and later) accessibility.mobileconfigOnly if you use Microsoft Purview data loss prevention: Accessibility access for its DLP daemon If your Jamf Pro version strips the Bluetooth payload, sign the file so Jamf treats it as sealed; a self-signed certificate is enough:
bash/usr/bin/security find-identity -p codesigning -v /usr/bin/security cms -S -N "DevCert" -i bluetooth.mobileconfig -o bluetooth-signed.mobileconfig - 5
Gate the package behind the profiles
Jamf Pro usually pushes profiles immediately but runs policies at check-in, and profiles can lag, for example on a locked Mac. Create a smart computer group with one Profile Name criterion per Defender profile, joined with AND, and scope the package policy to it.
- 6
Deploy the package
Upload
wdav.pkgunder Computer management › Packages (no manifest file needed). Create a policy that installs it, triggered by Recurring Check-in and scoped to the step 5 group; optionally offer it in Self Service too.
Verify
- On a test Mac, run
sudo jamf policy, check System Settings › General › Device Management for the profiles, then run:
mdatp health --field healthy
mdatp health --field licensed
mdatp health --field org_id
mdatp health --details system_extensions
systemextensionsctl list
mdatp connectivity test- Good looks like
healthyandlicensedtrue, your organisation ID present, both extensions[activated enabled]and every connectivity test passing. The device should then appear in the Defender portal's device inventory.
Tips & gotchas
- Files under
/Library/Managed Preferencesaren't proof that a payload applied; check MDM delivery, installed profiles and the health output. - Name profiles by purpose and ring, for example FullDiskAccess (piloting) - macOS - Default - MDE.
- If you also deploy Microsoft 365 apps with Jamf, manage
com.microsoft.autoupdate2from a single profile so settings don't conflict; see Microsoft 365 apps and MAU with Jamf Pro. - For Macs that onboard but later go quiet, see Inactive or No sensor data; the wider map is in Jamf Pro and Microsoft Intune in 2026.