This chapter covers Microsoft Defender for Endpoint (MDE) onboarding methods, a critical topic for the SC-200 exam. You will learn the various ways to onboard devices—Windows, macOS, Linux, iOS, and Android—into MDE, including using Microsoft Endpoint Manager, Group Policy, local scripts, and third-party integrations. Approximately 15-20% of exam questions touch on deployment and onboarding, making this a high-yield area. Mastering these methods ensures you can configure and manage endpoint sensors effectively, a core skill for a Security Operations Analyst.
Jump to a section
Imagine you are a security manager for a large office building. You need to install a network of security cameras to monitor every room and corridor. Each camera must be properly mounted, connected to the central recording server, and configured to send video feeds. There are three main ways to do this: (1) Use a single, standardized camera model that plugs directly into the building's Ethernet ports (like onboarding via Microsoft Endpoint Manager or Group Policy for Windows devices). (2) Use a universal adapter that connects any existing camera brand to your recording system (like onboarding via a script for third-party or legacy devices). (3) Use a wireless camera that connects via Wi-Fi but requires a special bridge device (like onboarding non-Windows devices via a partner integration or API). Each method has its own setup steps, cabling requirements, and configuration nuances. If a camera is not properly connected, the central system won't receive its feed, leaving blind spots. Similarly, if a device is not onboarded correctly to Microsoft Defender for Endpoint, it won't report telemetry, creating security gaps. The onboarding process ensures each device is registered, configured to send sensor data, and integrated into the unified security portal, just as each camera must be registered in the video management system to provide live and recorded footage.
What is Microsoft Defender for Endpoint Onboarding?
Microsoft Defender for Endpoint (MDE) is an enterprise-grade endpoint security platform that provides preventive protection, post-breach detection, automated investigation, and response. For MDE to protect a device, the device must be onboarded—meaning it has the MDE sensor installed and is reporting telemetry to the Microsoft 365 Defender portal. Onboarding is the process of deploying the sensor package and establishing a trusted connection with the cloud service. Without onboarding, the device is invisible to MDE and cannot be defended.
Why Onboarding is Necessary
MDE operates on a sensor-based architecture. Each endpoint runs a lightweight sensor that collects system events (process creation, network connections, file modifications) and sends them to the cloud for analysis. The sensor must be authenticated and authorized to communicate with the MDE backend. Onboarding provisions this identity and configures the necessary communication channels. It also ensures compliance with organizational security policies.
How Onboarding Works Internally
The onboarding process involves several steps:
Sensor Installation: The MDE sensor package (e.g., WindowsDefenderATPOnboardingPackage.zip for Windows, mdatp_offboard.sh for Linux) is deployed to the device. This package contains the sensor binary and a configuration script.
Registration: The sensor generates a unique device ID and sends a registration request to the MDE cloud service over HTTPS (port 443). The request includes the device's identity and the onboarding package's organization-specific key.
Authentication: The cloud service validates the onboarding package using a pre-shared key (the OrgID). If valid, the device is registered in the tenant and a certificate or token is issued for future communications.
Configuration: The sensor receives configuration policies (e.g., sample collection settings, exclusion lists, cloud-delivered protection level) from the cloud.
Heartbeat: The sensor sends periodic heartbeat signals (every 5-10 minutes by default) to indicate it is still active and reachable. If the heartbeat stops, the device may be marked as stale.
Telemetry Streaming: Once onboarded, the sensor begins streaming events to the cloud in near real-time using a persistent HTTPS connection.
Key Components and Defaults
- Onboarding Package: A ZIP file containing the sensor installer and a .cmd or .sh script that configures the sensor with the tenant's OrgID. The OrgID is a GUID that ties the device to your specific tenant.
- OrgID: A unique identifier for your MDE tenant. It is embedded in the onboarding package. If you create a new package from the portal, it contains a different OrgID.
- Communication Ports: The sensor communicates over HTTPS (TCP 443) to the following endpoints:
- *.events.data.microsoft.com
- *.endpoint.microsoft.com
- *.dm.microsoft.com (for device management)
- *.blob.core.windows.net (for sample uploads)
- *.crl.microsoft.com and *.ocsp.digicert.com (for certificate revocation)
- Heartbeat Interval: Default 5 minutes for Windows, configurable via registry or policy. If no heartbeat for 30 days, the device is considered inactive.
- Sensor Version: The minimum supported sensor version for the latest features is regularly updated. For example, Windows sensor version 10.8047.22439.1045 or later is required for certain EDR capabilities.
- Supported Operating Systems:
- Windows: 7 SP1, 8.1, 10, 11, Server 2008 R2 SP1 and later (with specific servicing stack updates) - macOS: 11 (Big Sur), 12 (Monterey), 13 (Ventura), 14 (Sonoma) - Linux: Ubuntu 16.04 LTS+, RHEL 7+, CentOS 7+, SLES 12+, Debian 9+, Oracle Linux 7+ - iOS: iOS 12.0+ (via Defender for Endpoint on iOS app) - Android: Android 6.0+ (via Defender for Endpoint on Android app)
Onboarding Methods
#### 1. Microsoft Endpoint Manager (Intune)
This is the preferred method for modern managed devices. Intune policies push the MDE sensor to devices automatically.
Windows: Create an endpoint protection profile for Microsoft Defender for Endpoint. The profile includes the onboarding package (converted to a policy). Devices enrolled in Intune receive the policy and install the sensor.
macOS: Use a device configuration profile for system extensions and kernel extensions, then deploy the MDE package via Intune as a line-of-business app.
Linux: Intune does not natively support Linux device management; use a script or third-party MDM.
iOS/Android: Deploy the Defender for Endpoint app via Intune app protection policies or managed app configuration.
#### 2. Group Policy (Active Directory)
For on-premises Windows devices joined to an on-premises AD domain. Group Policy can deploy the onboarding script.
- Steps:
1. Download the onboarding package from the MDE portal (Settings > Endpoints > Onboarding).
2. Extract the ZIP and place the WindowsDefenderATPOnboardingScript.cmd in a network share.
3. Create a Group Policy Object (GPO) that runs the script at startup or via scheduled task.
4. The GPO should also configure the Windows Defender service to start automatically.
- The script writes the OrgID to the registry: HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status\OrgId.
#### 3. Local Script (Manual)
For testing or small-scale deployments. Run the onboarding script locally with administrative privileges.
- Windows: Right-click the .cmd script and run as Administrator.
- macOS: Run sudo ./mdatp_onboard.sh from terminal.
- Linux: Run sudo ./mdatp_onboard.sh.
- The script exits with code 0 on success, non-zero on failure.
#### 4. Microsoft Configuration Manager (SCCM)
For devices managed by Configuration Manager. Use the MDE onboarding policy in the Configuration Manager console (Assets and Compliance > Endpoint Protection > Microsoft Defender for Endpoint Policies). - The policy includes the onboarding package and can be deployed to collections. - Configuration Manager also supports co-management with Intune for hybrid environments.
#### 5. Third-party SIEM/SOAR
MDE can receive alerts from third-party tools via APIs, but onboarding still requires one of the above methods. The SIEM integration is separate.
#### 6. Non-Windows Devices
macOS: Onboarding via Intune or script. Requires granting system extension and full disk access permissions to the sensor.
Linux: Onboarding via script or using a configuration management tool like Puppet, Chef, or Ansible. The sensor is installed as a .deb or .rpm package.
iOS/Android: Onboarding via Intune app deployment. The app registers the device with MDE and enforces mobile threat defense policies.
Verification Commands
Windows: Run Get-MpComputerStatus in PowerShell to check the AMProductVersion and AMServiceEnabled. For MDE-specific status, use Get-MpComputerStatus | Select-Object -Property * and look for AntispywareEnabled, AntivirusEnabled, BehaviorMonitorEnabled, etc. Also check HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status for OnboardingState (1 = onboarded).
macOS: Run mdatp health in terminal. Look for healthy: true. Also check mdatp connectivity test to verify cloud communication.
Linux: Same as macOS—mdatp health and mdatp connectivity test.
Portal: In the Microsoft 365 Defender portal, navigate to Assets > Devices. The device should appear within a few minutes of onboarding. If not, check the sensor status (Active/Inactive).
Interaction with Related Technologies
Microsoft 365 Defender: MDE is the endpoint component of the broader XDR solution. Onboarded devices contribute to incidents and alerts in the unified portal.
Microsoft Defender for Cloud: For Azure VMs, you can enable MDE via Defender for Cloud's integrated vulnerability assessment and endpoint protection recommendations.
Microsoft Sentinel: MDE can stream events to Sentinel for advanced SIEM capabilities.
Azure AD: Devices can be hybrid Azure AD joined or Azure AD registered, which simplifies onboarding via Intune.
Troubleshooting Common Issues
Sensor not installing: Check OS version and prerequisites (e.g., KB4052623 for Windows 7). Ensure the device has internet access to the required endpoints.
Device not appearing in portal: Verify the onboarding package matches the correct tenant. Check firewall logs for blocked outbound HTTPS traffic. Wait up to 15 minutes for initial registration.
Heartbeat missing: The sensor may be stopped or crashed. Restart the service: net start WinDefend (Windows) or sudo systemctl restart mdatp (Linux).
OrgID mismatch: If you onboard with a package from a different tenant, the device will not appear. Use the correct package.
macOS permissions: The sensor needs full disk access and system extension approval. These must be granted manually or via MDM profile.
Best Practices
Use Intune for modern, cloud-managed devices.
For legacy devices, use Group Policy or Configuration Manager.
Test onboarding with a pilot group before broad deployment.
Monitor device health using the MDE portal's device inventory and health reports.
Regularly update the onboarding package (e.g., after tenant migration or security key rotation).
For non-persistent VDI environments, use a shared onboarding package or script that runs at each session start.
Download Onboarding Package from Portal
Navigate to Microsoft 365 Defender portal > Settings > Endpoints > Onboarding. Select the operating system (Windows 10, macOS, Linux, etc.) and deployment method (local script, Group Policy, Intune, etc.). Click 'Download onboarding package'. The package is a ZIP file containing the sensor installer and a configuration script with the tenant's OrgID embedded. For Windows, the script is named `WindowsDefenderATPOnboardingScript.cmd`. For macOS/Linux, it's `mdatp_onboard.sh`. Ensure you download the correct package for your environment; using a package from another tenant will cause the device to not appear in your portal.
Deploy the Onboarding Package to Devices
Depending on your chosen method, distribute the package to endpoints. For Intune, upload the package as a policy or app. For Group Policy, copy the script to a network share and configure a GPO to run it at startup. For local script, execute it manually with admin rights. The script performs several actions: it writes the OrgID to the registry (Windows) or a configuration file (macOS/Linux), installs the sensor service (if not already present), and starts the service. The sensor then attempts to contact the MDE cloud to register the device. If the device cannot reach the internet, the script will fail and the device will not onboard.
Verify Onboarding on the Device
After running the script, verify the sensor is active. On Windows, open PowerShell as admin and run `Get-MpComputerStatus`. Check that `AMProductVersion` shows a Defender for Endpoint version (e.g., 10.8047.22439.1045) and `AMServiceEnabled` is True. Also check the registry key `HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status` for `OnboardingState` = 1. On macOS/Linux, run `mdatp health` and look for `healthy: true`. Run `mdatp connectivity test` to ensure the sensor can reach the cloud endpoints. If the health check fails, verify network connectivity and that the required endpoints are not blocked by a firewall or proxy.
Confirm Device Appears in Defender Portal
In the Microsoft 365 Defender portal, go to Assets > Devices. The device should appear within 5-15 minutes after successful onboarding. If it does not appear, check the device's sensor status. Look for the device name, OS, and sensor health (Active). If the device shows as 'Inactive', the sensor may have stopped sending heartbeats. Common causes: network issues, sensor crash, or the device was offboarded. You can also use the 'Add filter' to search for the device by name. If the device is missing entirely, re-run the onboarding script and ensure the OrgID matches your tenant. You can verify the OrgID in the portal under Settings > Endpoints > Onboarding > 'Copy' the OrgID value.
Troubleshoot and Validate Connectivity
If the device does not appear or shows as inactive, perform connectivity tests. On Windows, use the 'MDATP client analyzer' tool (download from Microsoft). On macOS/Linux, use `mdatp connectivity test`. This test checks DNS resolution and HTTPS connectivity to required endpoints like `*.events.data.microsoft.com`. Ensure the device can resolve these domain names and that no SSL inspection or proxy is breaking the TLS handshake. If using a proxy, configure the sensor to use it via registry (Windows: `HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Proxy`) or environment variables (Linux: `http_proxy`). Also verify the sensor service is running: on Windows, `net start WinDefend`; on Linux, `sudo systemctl status mdatp`. Restart the service if needed.
Enterprise Scenario 1: Large Financial Institution with Hybrid Environment
A global bank with 50,000 endpoints—70% Windows 10/11, 20% macOS, and 10% Linux servers—needs to onboard all devices to MDE. The Windows devices are managed via Intune and Configuration Manager (co-management). The macOS fleet is managed by Jamf Pro. The Linux servers are managed via Ansible.
Solution: For Windows, the team uses Intune policies to push the MDE onboarding package to all Azure AD-joined devices. For on-premises domain-joined devices, they use Configuration Manager to deploy the onboarding script. For macOS, they integrate Jamf Pro with MDE using the Microsoft Defender for Endpoint Jamf integration, which deploys the sensor and configuration profiles. For Linux, they use Ansible playbooks to install the mdatp package and run the onboarding script. The team monitors device health via the MDE portal's device inventory and sets up alerts for devices that have not sent a heartbeat in 24 hours.
Common Pitfall: The bank initially used a single onboarding package for all devices, but later realized that the macOS and Linux packages are different. They had to download separate packages for each OS. Also, they forgot to allow the required endpoints on their proxy, causing onboarding failures. They resolved this by adding the endpoints to the proxy allow list and configuring the sensor to use the proxy via environment variables.
Enterprise Scenario 2: Healthcare Provider with Legacy Systems
A hospital network has 10,000 Windows 7 and Windows Server 2008 R2 machines that cannot be upgraded due to legacy medical software. They need to onboard these to MDE for EDR coverage.
Solution: Microsoft supports Windows 7 SP1 and Server 2008 R2 SP1 with the latest servicing stack updates. The team downloads the appropriate onboarding package for Windows 7/Server 2008 R2. They use Group Policy to deploy the script across the domain. They also install the required KB4052623 update via WSUS. After onboarding, they verify the sensor is active by checking the registry.
Common Pitfall: Some devices failed to onboard because the sensor required TLS 1.2, which is not enabled by default on Windows 7. The team had to enable TLS 1.2 via registry (HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client). They also had to install the Microsoft Update for SHA-2 code signing support (KB4474419).
Enterprise Scenario 3: Retail Chain with Mobile Devices
A retail company with 5,000 iOS and Android devices used for point-of-sale and inventory management wants to protect them with MDE mobile threat defense.
Solution: They deploy the Microsoft Defender for Endpoint app on iOS and Android via Intune. They create app protection policies that require the Defender app to be active and healthy. They also configure mobile threat defense connectors to block access to corporate resources if a device is compromised.
Common Pitfall: The initial deployment did not include the required iOS configuration profile (VPN and content filter) to enable web protection. Devices showed as 'not onboarded' in the portal until the profile was deployed via Intune. Also, on Android, the app needed the 'Accessibility' permission to detect phishing URLs, which users had to grant manually.
SC-200 Exam Focus on Defender for Endpoint Onboarding Methods
The SC-200 exam objective 1.1 (Deploy and manage Microsoft Defender for Endpoint) specifically tests your ability to onboard devices using various methods. Expect 2-3 questions directly on onboarding methods, and several more on related topics like sensor health and troubleshooting.
What the Exam Tests:
- You must know which onboarding method is appropriate for a given scenario (e.g., Intune for modern managed devices, Group Policy for on-premises AD, local script for testing).
- You must understand the steps to download and deploy the onboarding package.
- You must know how to verify successful onboarding (PowerShell command Get-MpComputerStatus, registry key OnboardingState, portal device list).
- You must know the required communication endpoints and ports (HTTPS 443, specific domains like *.events.data.microsoft.com).
- You must know the default heartbeat interval (5 minutes) and what happens if a device stops sending heartbeats (marked inactive after 30 days).
- You must know the differences between onboarding for Windows, macOS, Linux, iOS, and Android.
- You must know common troubleshooting steps (proxy configuration, TLS 1.2, permissions on macOS).
Common Wrong Answers and Why: 1. 'Use Azure AD Join to onboard devices' – Wrong. Azure AD Join is an identity integration, not an onboarding method. Onboarding requires the sensor installation and registration, which is separate from Azure AD Join. However, Azure AD Join simplifies Intune management, which can then deploy the onboarding package. 2. 'Onboarding is automatic for all domain-joined devices' – Wrong. Domain-joined devices are not automatically onboarded. You must deploy the onboarding package via Group Policy or another method. The exam may present a scenario where a domain-joined device is not appearing in the portal, and the correct answer is to deploy the onboarding script via GPO. 3. 'The onboarding package contains the sensor binary and is OS-agnostic' – Wrong. The onboarding package is OS-specific. Windows, macOS, and Linux have different packages. Using the wrong package will fail. 4. 'After onboarding, the device immediately appears in the portal' – Wrong. There is a delay of up to 15 minutes for initial registration. The exam may ask how long to wait before troubleshooting.
Specific Numbers and Terms:
- OrgID (GUID)
- Heartbeat interval: 5 minutes (default)
- Inactive threshold: 30 days without heartbeat
- Communication port: TCP 443
- Required domains: *.events.data.microsoft.com, *.endpoint.microsoft.com, etc.
- Windows sensor version: 10.8047.22439.1045 or later (for certain features)
- macOS/Linux health command: mdatp health
- Windows verification command: Get-MpComputerStatus
Edge Cases: - Onboarding non-persistent VDI: Use a shared onboarding package or script that runs at each session start. The sensor must be reinstalled each time. - Onboarding servers without internet: Use a proxy or a dedicated egress point. The sensor must have outbound HTTPS access. - Onboarding devices with strict firewall rules: You may need to allow specific IP ranges (Microsoft publishes the Azure IP ranges for Defender for Endpoint).
How to Eliminate Wrong Answers: - If the question mentions 'modern managed devices', think Intune. - If the question mentions 'on-premises AD', think Group Policy. - If the question mentions 'testing a few devices', think local script. - If the question mentions 'device not appearing', first verify the onboarding package is correct and the device has internet access. - If the question mentions 'sensor not starting', check for missing prerequisites (e.g., KB update, TLS 1.2, permissions).
Onboarding is the process of installing the MDE sensor and registering the device with the cloud; it is not automatic even with a license.
The onboarding package is OS-specific; always download the correct package for Windows, macOS, or Linux.
The OrgID is a GUID that ties the device to your tenant; using a package from another tenant will not work.
The sensor communicates over HTTPS (TCP 443) to specific Microsoft domains; firewalls must allow outbound traffic to *.events.data.microsoft.com and others.
Default heartbeat interval is 5 minutes; if no heartbeat for 30 days, the device is marked inactive.
Verify onboarding on Windows with Get-MpComputerStatus (check OnboardingState=1) and on macOS/Linux with mdatp health.
Intune is the recommended method for modern, cloud-managed devices; Group Policy for on-premises AD; local script for testing.
Non-Windows devices (macOS, Linux, iOS, Android) require separate onboarding procedures and may need additional permissions (e.g., full disk access on macOS).
Troubleshooting: Check network connectivity, proxy settings, TLS 1.2, and required KB updates (e.g., KB4052623 for Windows 7).
For non-persistent VDI, the sensor must be reinstalled at each session; use a shared onboarding script.
These come up on the exam all the time. Here's how to tell them apart.
Intune (Microsoft Endpoint Manager)
Requires Azure AD-joined or hybrid-joined devices.
Deploys onboarding package as a policy or app; no script needed.
Supports Windows, macOS, iOS, Android.
Centralized cloud management; no on-premises infrastructure needed.
Automatic policy refresh; devices check in every 8 hours.
Group Policy
Works with on-premises AD domain-joined devices.
Deploys onboarding script via GPO startup script or scheduled task.
Only supports Windows (client and server).
Requires on-premises domain controllers and network connectivity.
Policy refresh depends on Group Policy refresh interval (default 90 minutes).
Local Script
Manual execution on each device; not scalable.
Suitable for testing a few devices.
No dependency on management infrastructure.
No reporting or compliance monitoring.
Must be run with administrative privileges.
Configuration Manager (SCCM)
Supports large-scale deployment to on-premises Windows devices.
Integrates with existing Configuration Manager infrastructure.
Provides deployment monitoring and reporting.
Can be combined with Intune for co-management.
Requires Configuration Manager console and client.
Mistake
Onboarding a device to MDE is the same as installing Microsoft Defender Antivirus.
Correct
Installing Microsoft Defender Antivirus is only part of the process. MDE onboarding includes installing the EDR sensor, registering the device with the cloud, and configuring advanced features like attack surface reduction rules and automated investigation. Simply having antivirus enabled does not mean the device is onboarded to MDE.
Mistake
All Windows devices are automatically onboarded to MDE if they have a Microsoft 365 E5 license.
Correct
A license is required but not sufficient. The device must have the MDE sensor installed and configured. Even with an E5 license, you must deploy the onboarding package via Intune, Group Policy, or script. The license enables the service; onboarding activates it on the endpoint.
Mistake
The onboarding package from the portal is universal and works for any operating system.
Correct
Each operating system requires a specific onboarding package. Windows, macOS, and Linux have separate packages. Using a Windows package on macOS will fail. The portal requires you to select the OS before downloading.
Mistake
Once a device is onboarded, it will stay onboarded forever regardless of changes.
Correct
If the device's sensor is uninstalled, the OrgID is changed, or the device is offboarded via the portal, it will stop reporting. Also, if the device does not send a heartbeat for 30 days, it is marked as inactive and may be removed from the device inventory. Periodic verification is necessary.
Mistake
Onboarding via local script is the recommended method for large-scale deployments.
Correct
Local script is intended for testing or small-scale deployments (fewer than 10 devices). For large-scale deployments, use Intune, Group Policy, or Configuration Manager to automate the process and ensure consistency.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Typically, the device appears within 5-15 minutes after successful onboarding. The sensor must register with the cloud, which involves DNS resolution, TLS handshake, and authentication. If it takes longer, check network connectivity and ensure the onboarding package is correct. You can expedite troubleshooting by running `Get-MpComputerStatus` (Windows) or `mdatp health` (macOS/Linux) to verify the sensor is active.
No. The MDE sensor requires outbound HTTPS connectivity to Microsoft cloud endpoints. Without internet access, the sensor cannot register or send telemetry. For air-gapped environments, consider using Microsoft Defender for Cloud (for Azure VMs) or a third-party EDR solution. If a device has intermittent connectivity, it will still attempt to send data when connected, but prolonged disconnection will result in the device being marked inactive after 30 days.
Onboarding installs the sensor and registers the device; offboarding removes the sensor and deregisters it. Offboarding is done via the portal (Settings > Endpoints > Offboarding) and generates an offboarding script that must be run on the device. After offboarding, the device stops sending telemetry and is removed from the device inventory. Offboarding is necessary when decommissioning a device or migrating to a new tenant.
Yes, Windows Server Core is supported for MDE onboarding. However, you must use the appropriate onboarding package for Windows Server. The sensor can be installed via script or Configuration Manager. Note that Server Core does not have a GUI, so verification must be done via PowerShell commands like `Get-MpComputerStatus`.
Yes, the same onboarding package can be used for multiple devices of the same OS. The package contains the tenant's OrgID, which is the same for all devices in your tenant. However, each device gets a unique device ID during registration. For large-scale deployments, it is common to use a single package distributed via management tools.
First, check if the device has been offline for more than 30 days (the default inactivity threshold). If it has been offline for less than 30 days, it may be a temporary network issue. Verify the sensor is running on the device (Windows: `net start WinDefend`, macOS/Linux: `sudo systemctl status mdatp`). Check network connectivity to the required endpoints. If the sensor is stopped, restart it. If the issue persists, re-run the onboarding script or consider offboarding and re-onboarding the device.
Yes, you can onboard macOS devices using a local script or a third-party MDM like Jamf Pro. Microsoft provides a script (`mdatp_onboard.sh`) that can be run manually or pushed via Jamf. The script requires sudo privileges. Additionally, you must grant the sensor full disk access and system extension permissions, which can be done via MDM profile or manually.
You've just covered Defender for Endpoint Onboarding Methods — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?