Deploy Microsoft Defender for Endpoint on Macs with Jamf Pro (and fix mdatp health errors)

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.

Prerequisites#

• 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.

Step-by-step#

Step 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 jamf folder. Download and extract GatewayWindowsDefenderATPOnboardingPackage.zip and keep jamf/WindowsDefenderATPOnboarding.plist. Then select Download installation package to get wdav.pkg.

Step 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. This profile carries the onboarding and licensing information.

Step 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 domain com.microsoft.wdav. Use com.microsoft.wdav.ext only 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 passiveMode to true if another antivirus stays, and remove the EICAR entry from allowedThreats if you'll test with EICAR.

curl -o ~/Documents/schema.json https://raw.githubusercontent.com/microsoft/mdatp-xplat/master/macos/schema/schema.json

Step 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:

If your Jamf Pro version strips the Bluetooth payload, sign the file so Jamf treats it as sealed; a self-signed certificate is enough:

/usr/bin/security find-identity -p codesigning -v
/usr/bin/security cms -S -N "DevCert" -i bluetooth.mobileconfig -o bluetooth-signed.mobileconfig

Step 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. Never do the reverse: profiles that depend on Defender being installed arrive late, causing prompts or an unhealthy sensor.

Step 6: Deploy the package#

Upload wdav.pkg under 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 healthy and licensed true, 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. Microsoft's analyze_profiles.py script, in the same GitHub repository and run with sudo python3, compares installed profiles with the maintained templates and flags missing, duplicate or mismatched payloads.

Fixing mdatp health errors#

When something is missing, the menu bar shield shows an x, and Action needed can open Microsoft Defender needs attention with a Fix button. mdatp health shows why:

healthy                        : false
health_issues                  : ["no active event provider", "network event provider not running", "full disk access has not been granted"]
real_time_protection_enabled   : true
real_time_protection_available : false
full_disk_access_enabled       : false

Tips and gotchas#

• Files under /Library/Managed Preferences aren'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.autoupdate2 from 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.

References#

• Configure Microsoft Defender for Endpoint on macOS with Jamf Pro
• Troubleshoot Defender for Endpoint system extensions on macOS