Deploying Microsoft Defender for Endpoint on macOS with Workspace ONE UEM


Complete deployment blog based on Microsoft guidance and field experience.

Executive Summary

This document describes a complete deployment of Microsoft Defender for Endpoint on macOS using Workspace ONE UEM. It covers software deployment, required configuration profiles, onboarding, Defender settings, validation, and troubleshooting. The approach is based on Microsoft's macOS deployment model for third-party MDM solutions and practical implementation experience in Workspace ONE. 

Microsoft References

Deployment guide: https://learn.microsoft.com/en-us/defender-endpoint/mac-install-with-other-mdm

GitHub repository: https://github.com/microsoft/mdatp-xplat

Combined profile: https://github.com/microsoft/mdatp-xplat/blob/master/macos/mobileconfig/combined/mdatp.mobileconfig


Step 1 – Download Defender for macOS

Navigate to Microsoft Defender Portal → Settings → Endpoints → Device Management → Onboarding. 
 
Select: 
• Operating System: macOS 
• Connectivity: Streamlined 
• Deployment Method: Mobile Device Management (MDM) 
 
Download: 
• wdav.pkg 
• Onboarding package ZIP 
 
The Streamlined option is recommended and reduces dependency on legacy networking requirements.

Step 2 – Review the Onboarding Package

The onboarding package contains tenant-specific onboarding artifacts. 
 
Common files include: 
• WindowsDefenderATPOnboarding.mobileconfig 
• WindowsDefenderATPOnboarding.plist 
• WindowsDefenderATPOnboarding.xml 
 
For Workspace ONE UEM the preferred onboarding artifact is WindowsDefenderATPOnboarding.mobileconfig. 
 
This file contains tenant information, onboarding configuration and organization identifiers generated specifically for the tenant.



Step 3 – Deploy Required Profiles

  1. Bluetooth Profile

Download the bluetooth.mobileconfig from Microsoft’s Github - https://github.com/microsoft/mdatp-xplat/blob/master/macos/mobileconfig/profiles/bluetooth.mobileconfig

To import the mobileconfig file, use the ‘Upload Profile’ option in UEM as shown below:



 
 
Important: 
Workspace ONE UEM might reject imported profiles because of duplicate identifiers.

The following error might display:

“A profile with the same identifier already exists, you must change the identifier before uploading this profile” 

 
 
In this case, you should modify only: 
• PayloadUUID 
• PayloadIdentifier 
 
Do NOT modify: 
• Bundle IDs 
• Team IDs 
• Identifier values 
• CodeRequirement values

You can generate new UUID values using the built-in macOS command line utility uuidgen. As long as the duplicate identifiers are changed to unique values, you should be able to upload it.


  2. Combined Profile

  3. Download the mdatp.mobileconfig - https://github.com/microsoft/mdatp-xplat/blob/master/macos/mobileconfig/combined/mdatp.mobileconfig

The combined profile consolidates several Microsoft profiles into a single deployment. 
 
Included payloads: 
• System Extension Policy 
• Web Content Filter / Network Filter 
• Notifications 
• Background Services Management 
• PPPC (Privacy Preferences Policy Control) 
• Full Disk Access related permissions 
 
System Extensions approved: 
• com.microsoft.wdav.epsext 
• com.microsoft.wdav.netext

PPPC / Full Disk Access Payload

The PPPC payload contains SystemPolicyAllFiles permissions for: 
 
• com.microsoft.wdav 
• com.microsoft.wdav.epsext 
• com.microsoft.dlp.daemon

Also with this combined profile, Workspace ONE may reject imported Microsoft profiles due to identifier collisions. 
 
You may change the Top-level PayloadUUID, Top-level PayloadIdentifier, Nested PayloadUUID values, Nested PayloadIdentifier values. 
 
Do not chang the CodeRequirement, Identifier, TeamIdentifier references, Microsoft bundle identifiers

3. Onboarding Profile

Deploy WindowsDefenderATPOnboarding.mobileconfig (This file is included in the zip package you downloaded earlier). 
 
This profile contains: 
• Tenant onboarding information 
• Org ID 
• Defender enrollment information


4. Create Defender Settings Profiles (optional)

Workspace ONE Custom Settings can be used for Defender configuration. 
 
Typical preference domains: 
• com.microsoft.wdav 
• com.microsoft.wdav.ext

Workspace ONE Consideration:

The WindowsDefenderATPOnboarding.plist file included in the onboarding package is not immediately importable as a Workspace ONE Custom Settings payload. Unlike standard Workspace ONE managed preference payloads, the file does not include the managed preference domain structure expected by UEM. The payload must be wrapped with the appropriate preference domain configuration before deployment. 

The PLIST has to be wrap inside a Workspace ONE Managed Preferences payload by specifying the appropriate preference domain and managed preference structure.

This structure alone is not sufficient for Workspace ONE UEM Custom Settings because it does not contain a managed preference domain payload.


Workspace ONE UEM Compatible Version

You should create a macOS custom settings profile, add two different payloads; one for com.microsoft.wdav and one for the extended settings com.microsoft.wdav.ext.

Use the following link for Microsoft documentation about the different settings - https://learn.microsoft.com/en-us/defender-endpoint/mac-preferences

For the actual plist file, A reminder that you can generate new UUID values using the built-in macOS command line utility uuidgen

Example for: com.microsoft.wdav

This example enables cloud protection while disabling automatic sample upload, make sure to adjust the settings based on your requirements. More information can be found at 


Example: com.microsoft.wdav.ext

This example demonstrates EDR tagging and a path exclusion, make sure to adjust based on your requirements.


You should upload both plists contents in a macOS ‘Custom Settings’ profile.



 


Useful Defender Settings

Examples of settings commonly managed from UEM: 
 
• Cloud protection 
• Automatic sample submission 
• Exclusions 
• EDR tags 
• Device groups 
• Network protection 
• Device control

Step 5 – Deploy Microsoft Defender

Upload wdav.pkg to Workspace ONE UEM as a macOS application and assign it to the target devices. 
 
Validation: 
mdatp health 
 
Expected: 
• licensed = true 
• engine loaded successfully


Validation and Health Checks

Useful commands: 
 
mdatp health 
systemextensionsctl list 
sudo profiles show 
 
Key indicators: 
• licensed 
• org_id 
• real_time_protection_enabled 
• full_disk_access_enabled

Example:

Microsoft Validation Script

Microsoft publishes a validation script in the mdatp-xplat repository.

https://github.com/microsoft/mdatp-xplat/blob/master/macos/mdm/analyze_profiles.py

The script checks: 
• System Extensions 
• Network Extensions 
• PPPC permissions 
• Full Disk Access 
• Defender health 
• Onboarding status 
 
You can use the script as a validation tool, but I also suggest to confirm results using product functionality and health output.

Final Recommended Deployment Sequence 

  1. Deploy bluetooth.mobileconfig 

  1.  Deploy mdatp.mobileconfig 

  1. Deploy WindowsDefenderATPOnboarding.mobileconfig 

  1. Deploy optional Defender settings profiles 

  1. Deploy wdav.pkg 

  1. Validate: 

  1.  Using mdatp health 

  1. Using Microsoft’s verification script 

  1. Confirm system extension status and onboarding state


Disclaimer

Screenshots and Examples

The screenshots, configuration examples, command outputs, XML snippets, PLIST samples, and Workspace ONE UEM configurations included in this article are provided for educational and demonstration purposes only.

The author and publisher is not responsible for any inadvertent disclosure of sensitive information resulting from the use of screenshots or examples contained in this guide.

Use at Your Own Risk

The information provided in this article is based on practical deployment experience and available documentation at the time of writing. Product behavior, configuration requirements, supported settings, and deployment methods may change over time as Microsoft, Apple, and Omnissa release updates.

All procedures, recommendations, scripts, configuration files, PLIST examples, MobileConfig profiles, and validation steps should be thoroughly reviewed and tested within your own environment before production deployment.

By using any information contained in this document, you acknowledge that you do so at your own risk.

Validation and Operational Responsibility

Successfully deploying Microsoft Defender for Endpoint on macOS requires proper validation after installation and configuration.

It is the responsibility of the administrator to verify that:

  • Microsoft Defender for Endpoint is correctly onboarded.

  • The appropriate licensing is applied.

  • Real-time protection is enabled.

  • Required system extensions are active.

  • Network filtering is functioning as expected.

  • Full Disk Access and PPPC permissions are properly configured.

  • Cloud protection settings align with organizational requirements.

  • Device protection and reporting capabilities are operating correctly.


Recommended validation activities include, but are not limited to:


mdatp health

systemextensionsctl list

sudo profiles show

mdatp scan full

and any additional validation tools or scripts provided by Microsoft.

The successful installation of profiles or applications does not necessarily guarantee that Microsoft Defender is fully operational or providing the intended level of protection. Administrators should perform their own testing and validation to confirm that security controls are functioning as expected within their environment.

No Warranty

This document is provided "as is" without warranty of any kind, express or implied. The author makes no guarantees regarding completeness, accuracy, suitability, performance, security, or fitness for a particular purpose.

Always refer to the latest Microsoft, Apple, and Omnissa documentation and support guidance when designing, implementing, or troubleshooting production deployments.



 

Comments

Post a Comment

Popular posts from this blog

How to Enable DEX (Experience Management) for Omnissa Horizon - Step by Step

Image
In the era of modern distributed work, understanding user experience within virtual desktop infrastructure (VDI) is no longer a luxury - it’s an operational necessity. Omnissa Horizon, coupled with Workspace ONE Experience Management (DEX), gives IT administrators full visibility into VDI performance, from login latencies to application behavior. If you are looking to tap into these rich analytics, here is your definitive, step-by-step guide to enabling and validating DEX for your Omnissa Horizon environment. Step 1: Verify Prerequisites & Licensing Before writing a single line of code or deploying appliances, you must ensure your environment is properly licensed. DEX for Horizon requires a cloud-connected control plane and specific licensing tiers. Supported Core License: You must hold an active Horizon Universal Subscription or Horizon Apps Universal Subscription. The DEX Add-on: Experience Management features require the Workspace ONE Experience Management for Horizon add-on SKU...
Read more
How to access Omnissa's KCD Client tool on Unified Access Gateway To access the Omnissa-KCD-Client tool, you first need to enter the system’s shell either directly on the Linux machine or remotely via SSH using a tool such as PuTTY.  Next, follow the short video below, i've also included the commands below. docker ps docker exec -it {ContainerID} /bin/bash export KRB5CCNAME="MEMORY:" export KRB5_CONFIG="/opt/omnissa/seg/config/kerberos/krb5.conf" cp /opt/omnissa/seg/config/kerberos/kcd-client.conf /opt/omnissa/seg/kerberos-client/kcdclient.conf sed -i 's/log_level 2/log_level 4/' /opt/omnissa/seg/kerberos-client/kcdclient.conf cd /opt/omnissa/seg/kerberos-client/ You can use this syntax for testing KCD: ./Omnissa-KCD-Client -m kerberostest -n HTTP/{Your-SPN} -w {Your-KCD-User}@{your.domain}@YOUR.DOMAIN -u "{your-user}@YOUR.DOMAIN" -p {password} This was demonstrad on UAG version 2503. Good luck! :)
Read more