Defender for Endpoint provides multiple methods for onboarding devices to its platform. These methods allow administrators to choose the best approach based on the scale of deployment or the specific requirements of their device fleet.
Onboarding Methods
Devices can be onboard using the following methods:
- Local Script: This method is ideal for smaller-scale deployments or proof-of-concept (PoC) scenarios.
- Group Policy (GPO): Suitable for onboarding on-premises devices exclusively.
- Microsoft Configuration Manager (MCM): A scalable option for managing large device fleets.
- MDM/Intune: Perfect for Mobile Device Management suites, enabling large-scale device onboarding.
- VDI scripts for non-persistent devices: This method is not covered in this article.
Best Practices and Insights
After devices are onboarded, we can track how each device was onboarded. This practice, although not critical, is essential because:
- It streamlines future deployments.
- It ensures visibility on devices that can only be onboard via specific methods, such as GPO for on-premises devices.
- It provides insights into the number of devices managed by Mobile Device Management suites like Microsoft Intune. This can also be tracked via the Microsoft Intune portal, but the guidelines described in this article are provided from a troubleshooting perspective.
Tracking onboarding methods also proves useful for troubleshooting errors that may arise during the onboarding process.
On a side note, one question I have always got ask is, what is the difference between using the local script versus the GPO option?
The main difference is that the LocalScript when executed on the device will run a license agreement banner that you will need to click on it for the script to continue, while the GPO which is basically the same script, does not show this license agreement banner. When you plan to deploy at scale, using the LocalScript would not be efficient because the license agreement will have to be accepted every first time the script is executed in an endpoint to allow the script to continue with the onboarding process of the endpoint.
Why determine what onboarding method was used?
While it may seem like trivial information, understanding the onboarding method used for devices becomes important when troubleshooting is necessary. As an administrator, determining whether there were onboarding issues with a few devices or hundreds that did not register properly in the Defender portal is essential. Knowing the specific onboarding method allows you to focus on the platform used for onboarding and identify any conflicting policies or policy errors.
The challenge to determine this information:
Trying to retrieve this information directly from the endpoints, can be difficult because of the type of parameters that get set at the machine level when a given method of onboarding is used. In Advanced Hunting, the information you can find is, only if the device is onboarded or not but not specifically what platform was used to do the onboarding which can help the troubleshooting process.
For each method of onboarding, it can be a combination of registry keys, presence of log files, or the absence of registry keys which makes it difficult to determine with a high degree of certainty whether a machine was onboard using Intune, LocalScript, MCM or a GPO.
What are the indicators to look for:
Microsoft Intune: When a device is onboarded using Microsoft Intune, a regkey called “MdmSubscriberIds” is created in the following location:
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender
- REG_MULTI_SZ: MultiString type: MdmSubscriberIds
- Value example: 7CD40C80-3DD6-73E7-80D6-6942E95984B7
LocalScript: When a device is onboarded using the LocalScript downloadable from the Defender portal, a specific regkey called “latency” gets created here:
- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection
- REG_SZ: String type: latency
- Value: demo
MCM: When a device is onboarded in Defender for Endpoint using MCM as the onboarding platform, a specific .log file gets created to leave an audit trail of the device being onboarded.
- Windows folder path: C:\Windows\CCM\Logs\EndpointProtectionAgent.log
GPO: When a device is onboarded in Defender for Endpoint using the GPO method, there are a couple of things to look for:
Onboarding State:
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status
- REG_DWORD: OnboardingState
- Value: 1
Latency registry key:
- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection
- REG_SZ: String type: latency
- Value: not present
The latency registry key is not present in the above parent registry key path.
Co-management scenario to consider:
There is an additional scenario to consider that even though it doesn’t constitute an onboarding method for MDE, it is deeply connected with how the machines are managed after onboarding. enter “co-management”.
This state of co-management only applies to Windows client devices because these devices can be managed by either MCM or Intune. This scenario does not apply for Windows Server operating systems because they are not manageable by the Intune platform.
In this state the machine might be onboard via Intune but there are certain components that are still be delivered from MCM, for example: Device Configuration and Endpoint Protection policies are delivered by MCM and the rest of the settings on the machine are managed by Intune, as shown in the screenshot below (Figure 1).
Since these are “sliders” you can move to have one platform or the other managing everything, normally it can be used as a transitional state before having your client endpoints fully moving into modern workplace management.
Fig. 1
For this scenario, the indicators to be aware of are the following:
This key will be present in the registry hive, which denotes the machine is onboarded using Intune.
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender
- REG_MULTI_SZ: MultiString type: MdmSubscriberIds
- Value example: 7CD40C80-3DD6-73E7-80D6-6942E95984B7
This folder and file will be present in the Windows folder structure, denoting certain management components being delivered by MCM.
- Windows folder path: C:\Windows\CCM\Logs\EndpointProtectionAgent.log
This log file, normally is created when the endpoint is onboarded purely using MCM but it is something that the MCM administrator needs to configure in the Client Settings section in MCM, see Figure 2.
Fig. 2
Ultimately, to determine if the device was onboarded using only MCM and no co-management configuration is done, having only the EndpointProtectionAgent.log present in the folder/path described above and no presence of MdmSubscriberIds registry key can be used as a good indication the machine was onboarded solely using MCM.
On the other hand, to confirm if the device was onboarded using Intune even when the folder/path for MCM log file is present (EndpointProtectionAgent.log) is by checking if the eventID# 1807 exists in the following event viewer section:
Windows Logs – Application and Service Logs – Microsoft – Windows – SENSE, Operational log.
The presence of the Onboarding Blob hash points to Intune because this blob is used when the onboarding policy is created in Intune to onboard your endpoints. This event is only visible on devices that have been onboarded using Intune. Figure 3 and Figure 4.
Fig. 3
Fig. 4
NOTE: It is worth noting that in MCM you can also define for the machine, to use the onboarding blob when onboarding it, however, this will not generate eventId 1807, which is generated when the device is onboarded using Intune.
Onboarding methods highlights:
Intune:
This is the easiest way to onboard machines on Defender for Endpoint in bulk, and it allows administrators to set a simple policy in Intune that gets applied to the affected endpoints you assign to the policy using EntraID groups.
- When a machine is onboarded using Intune, a regkey gets added to the device to stamp the machine as being onboarded by the management platform, this regkey is called “MdmSubscriberIds.”
- It stores subscriber IDs for devices enrolled in MDM, indicating that the device is managed by an MDM solution. This key is used to verify MDM enrollment status. This key is used to verify MDM enrollment status and manage devices through MDM policies.
- This process boards the machine in Defender for Endpoint and creates an object in EntraID and Microsoft Intune.
LocalScript:
The local script can be run manually on a device or subset of devices to start the onboarding process. This process is fairly straightforward and on rare occasions can fail. The scenario where I have seen the script failing is because PowerShell is not executing with administrative privileges or there are organization policies that prevent the use of PowerShell, the onboarding script has been tampered with, the PowerShell execution policy is not correctly set to either RemoteSigned or Unrestricted, etc.
It is always recommended to download a new copy of the onboarding script from the Defender portal and not use an old one. Even though the onboarding script does not have an expiration date like the offboarding script, it is good practice to download a fresh copy from your Defender portal.
GPO:
Onboarding devices in Defender for Endpoint using a GPO is a method that is perfect for on-premises only devices. It is recommended to define a separate GPO for this purpose to keep a clear boundary between your regular Group Policy Objects and Endpoint Security policies.
The reason for this is, if you mix your Endpoint security policies with another GPO that might be applying security settings to your devices, it will make your troubleshooting process more difficult because you will have to focus on two different areas to troubleshoot and depending on the number of settings you have defined in the GPO you are using for both, it can be prone to errors.
MCM:
Onboarding devices using MCM is one of the methods of choice for on-premises Windows servers and it is an all-time favorite of MCM administrators. While the process may require additional steps to prepare the task sequence in MCM, it is a very robust process to onboard your devices in Defender for Endpoint. You may ask why not use GPO instead, if it is also a preferred method and it is easier to do?
Normally, organizations that have a well-established implementation of MCM prefer to use this platform because the device collections where they keep organized their devices by operating system and the task sequences to provision devices in an automated way has been used and maintained by the organization for a long time and it becomes second nature to use the platform to onboard your devices in Defender for Endpoint using a well-known method for MCM administrators.
Considerations when determining what method was used to onboard a Windows device in Defender for Endpoint:
There are certain scenarios where there might be an overlap of some of the indicators, we can leverage to determine the onboarding method, for example, considering this scenario: There are certain scenarios where there might be an overlap of some of the indicators, I mentioned we can leverage to determine the onboarding method, for example, considering this scenario:
Scenario#1:
- A device was onboard using the LocalScript but it is managed by Microsoft Intune:
In this scenario, the prevalent method is the LocalScript because the registry key “latency” will be present with the “demo” value in it. The presence of the Microsoft Intune indicator (MdmSubscriberIds) indicates that the machine is being managed by Intune but not onboarded by it.
The reason for this is because when a machine is onboarded by Intune, the latency registry key is not present on the device, so having the presence of both defines that the device was onboarded using the LocalScript method but it is managed by Microsoft Intune. This scenario, for example, will never happen in a Windows Server device because devices running Windows Server OS cannot be managed by Intune.
The key here is the presence of both registry keys with values:
- latency = demo
- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection, regkey latency = demo
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender
regkey MdmSubscriberIds = 7CD40C80-3DD6-73E7-80D6-6942E95984B7 (example)
Scenario#2:
If the machine was onboarded via GPO, the indicators to evaluate in the Windows Registry are:
The OnboardingState registry key has a value of 1
The latency registry key is not present in the registry.
Scenario#3:
If the machine has not been onboarded to Defender for Endpoint, there will not be any of the mentioned indicators present in the registry or presence of log files, however the folders for Windows Defender and Windows Defender Advanced Threat Protection will be present in the registry hive.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender (Intune onboarding)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status (GPO onboarding)
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\Status (LocalScript)
How PowerShell can help automate this process.
In Part 2 of this article, I will discuss how PowerShell can help automate this discovery at scale for multiple devices.
Explore these additional resources:
Log file reference for Microsoft Configuration Manager (MCM) – Endpoint agent log.
Review MDMDiagReport_RegistryDump.reg file from MDM log collection.
Onboard devices in Defender for Endpoint using a GPO.
Onboard devices using Microsoft Intune.
Troubleshoot issues when onboard devices use a LocalScript.
General troubleshooting for Defender for Endpoint onboarding issues.
Microsoft