Identify Defender for Endpoint Onboarding Method using PowerShell - Part 2
In its simplest form, what the script does is, interrogate a list of computers in a .txt file, run a detection logic to find indicators that points to what method was used to do the onboarding e.g., Intune, LocalScript, GPO or MCM and present the results in a .csv file. As described in Part 1 of this article, onboarding devices in Defender for Endpoint can be done via different methods like Intune, MCM, GPO or LocalScript. Each method has its own requirements, intricacies, and purpose. Nonetheless, when doing troubleshooting on a subset of devices, it becomes an important piece of information to have to help determine what onboarding method was used for a quicker analysis. This script's purpose is to complement the enriched information provided by the MDE Client analyzer tool and offer an additional piece of information to aid the troubleshooting process. The script may be used on a large scale, but its performance may not be optimal. It is recommended to use it only on a subset of devices that may be experiencing issues related to Defender for Endpoint onboarding process. NOTE: Although not covered in detail in this article, If the script is used on persistent VDI devices that were onboarded, for example via GPO; The onboarding method will be highlighted as GPO. Outcome will be equivalent if onboarding is done by MCM or LocalScript. For non-persistent VDIs the script will show that those endpoints were onboarded using a LocalScript which in essence is what the option shown from the Defender portal stands for. The script used for non-persistent VDIs is an optimized version of the regular LocalScript, as an effort to minimize the onboarding processing time on these devices. Fig 1 reference. Figure 1. onboarding script for non-persistent VDI devices. High level execution of the script: Scans computers to determine onboarding method in MDE: This is done via PowerShell remoting: Ensure remote computers have enabled PS remoting. Doing so at scale via GPO / policy is recommended. This command can enable remoting on a given computer: Enable-PSRemoting -Force Improvements since inception: - Computer names were being truncated if they were longer than 15 characters. - Run the script with local admin rights on the machine from where the script is executed and if running remotely on multiple machines using a .txt file - The account used on the remote devices needs to have local admin rights too. For further troubleshooting script execution refer to this link: PowerShell Remote troubleshooting Parameters used in the script: The script contains different parameters to evaluate with a great level of certainty if a device was onboarded using one of the known methods: ComputerList Path to a text-file, containing all the computers to scan, one computer per line. - Leading and trailing whitespaces will be trimmed - Lines starting with a "#" symbol will be skipped OutPath Path where to export the results to, should point at a CSV file. ComputerName List of computers to process. In case you do not wish to externally prepare a list of computer names in a file. Credential Credentials to use for remote access. By default, the current user's credentials will be used. LogPath All scanned machines write a LOCAL logfile with the scan results. This allows tracking local changes over time. Defaults to: C:\temp\MDE-Onboarding-Detection.log Set to "" (empty string) to disable the log. HOW TO RUN - EXAMPLE PS C:\> .\MDEOnboardingScan.ps1 -ComputerName “computername” (single computer) PS C:\> .\MDEOnboardingScan.ps1 )Script will prompt for missing parts - what files with computer names to read, where to store the results. Then it will scan the computers and write the results to a .csv file) Now, interrogating each of the variables I described in Part 1 of this article, the script goes hunting for the clues defined below, on the devices specified in the computer list text file. OnboardingKey = "HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status" LocalScriptKey = "HKLM:\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection" IntuneKey = "HKLM:\SOFTWARE\Microsoft\Windows Defender" MCMLogPath = "C:\Windows\CCM\Logs\EndpointProtectionAgent.log" The outcome of this process can be one of the ones described below: LocalScript: If only the latency regkey with a value of “demo” was detected the device was onboarded using the LocalScript option offered from Defender portal. Intune: If the regkey called MdmSubscriberIds is present with a value and no regkey “latency” key is present, the device was onboarded using Intune. LocalScript + IntuneManaged: Not an onboarding method per-se but wanted to highlight that whenever the “latency” regkey with the value of “demo” is present the onboarding happened using the LocalScript. If the regkey “latency” is present with a value of “demo” and the MdmSubscriberIds regkey is also present, it means the device was onboarded via LocalScript and Intune is managing the device. In this scenario, the regkey “latency” wins because it is a value that get sets only when onboarding is done via the LocalScript. MCM: The presence of the following log file “EndpointProtectionAgent.log” in the following path: “C:\Windows\CCM\Logs\” indicates device was onboarded using MCM. GPO: If the onboarding State regkey has a value of 1 and no latency regkey is present, nor MdMSubscriberId regkey exists, it is determined that the device was onboarded using a GPO. PowerShell scripting code: Code disclaimer: The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages. NOTE: When using your scripting editing tool of choice, be aware of any additional spaces added by the copy/past operation. If you have issues copy/pasting the script in your script editing tool, I am attaching a copy of the script in zip format. Bottom of the article. <# .SYNOPSIS Scans computers to determine how the devices were onboarded in Defender for Endpoint (MDE). .DESCRIPTION Scans computers to determine onboarding method in MDE. This is done via PowerShell remoting: Ensure remote computers have enabled remoting. Doing so at scale via GPO / policy is recommended. This command can enable remoting on a given computer: Improvements: computer names were being truncated if they were longer than 15 characters. Run the script with local admin rights on the machine from where the script is executed and if running remotely on multiple machines using a .txt file the account used on the remote devices needs to have local admin rights too. For further troubleshooting script execution refer to this link: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_remote_troubleshooting?view=powershell-7.5 Enable-PSRemoting -Force .PARAMETER ComputerList Path to a text-file, containing all the computers to scan, one computer per line. - Leading and trailing whitespaces will be trimmed - Lines starting with a "#" symbol will be skipped .PARAMETER OutPath Path where to export the results to. Should point at a CSV file. .PARAMETER ComputerName List of computers to process. In case you do not wish to externally prepare a list of computernames in a file. .PARAMETER Credential Credentials to use for remote access. By default, the current user's credentials will be used. .PARAMETER LogPath All scanned machines write a LOCAL logfile with the scan results. This allows tracking local changes over time. Defaults to: C:\temp\MDE-Onboarding-Detection.log Set to "" (empty string) to disable the log. .EXAMPLE PS C:> .\defenderOnboardingScan.ps1 Script will prompt for missing parts - what files with computernames to read, where to store the results. Then will scan the computers and write the results. .NOTES Author: Edgar Parra, Friedrich Weinmann Company: Microsoft Version: 3.1.1 #> [CmdletBinding()] param ( [string] $ComputerList, [string] $OutPath, [string[]] $ComputerName, [PSCredential] $Credential, [AllowEmptyString()] [string] $LogPath = 'C:\temp\MDE-Onboarding-Detection.log' ) $ErrorActionPreference = 'Stop' trap { Write-Warning "Script failed: $" throw $ } function Show-OpenFileDialog { [OutputType([string])] [CmdletBinding()] param ( [string] $InitialDirectory = '.', [string] $Filter, [string] $Title, [switch] $MultiSelect ) Add-Type -AssemblyName System.Windows.Forms -ErrorAction SilentlyContinue $dialog = [System.Windows.Forms.OpenFileDialog]::new() $dialog.InitialDirectory = Resolve-Path -Path $InitialDirectory $dialog.MultiSelect = $MultiSelect.ToBool() $dialog.Title = $Title if ($Filter) { $dialog.Filter = $Filter } $null = $dialog.ShowDialog() $dialog.FileNames } function Show-SaveFileDialog { [CmdletBinding()] param ( [string] $InitialDirectory = '.', [string] $Filter = '.', $Filename ) Add-Type -AssemblyName System.Windows.Forms -ErrorAction SilentlyContinue $saveFileDialog = [Windows.Forms.SaveFileDialog]::new() $saveFileDialog.FileName = $Filename $saveFileDialog.InitialDirectory = Resolve-Path -Path $InitialDirectory $saveFileDialog.Title = "Save File to Disk" $saveFileDialog.Filter = $Filter $saveFileDialog.ShowHelp = $True $result = $saveFileDialog.ShowDialog() if ($result -eq "OK") { $saveFileDialog.FileName } } function Resolve-ComputerTarget { [CmdletBinding()] param ( [AllowNull()] [AllowEmptyCollection()] [string[]] $ComputerName, [AllowEmptyString()] [string] $Path ) if ($ComputerName) { return $ComputerName | Where-Object { $_ -and $_ -notlike "#*" } | ForEach-Object { $_.Trim() } } if ($Path) { return Get-Content -Path $Path | Where-Object { $_ -and $_ -notlike "#*" } | ForEach-Object { $_.Trim() } } $filesSelected = Show-OpenFileDialog -Filter 'Text files (*.txt)|*.txt|All files (*.*)|*.*' -MultiSelect -Title "Select Text-File with list of Computer Names!" if (-not $filesSelected) { throw "No file with computers to scan selected!" } $computers = foreach ($filePath in $filesSelected) { Get-Content -Path $filePath } $computers | Where-Object { $_ -and $_ -notlike "#*" } | ForEach-Object { $_.Trim() } } function Resolve-ExportFile { [CmdletBinding()] param ( [AllowEmptyString()] [string] $Path ) if ($Path) { $parent = Split-Path -Path $Path if (-not (Test-Path -Path $parent)) { $null = New-Item -Path $parent -ItemType Directory -Force } return $Path } $result = Show-SaveFileDialog -Filename "mdeOnboarding-$(Get-Date -Format 'yyyy-MM-dd_HH-mm').csv" -Filter "CSV Files (*.csv)|*.csv" if (-not $result) { throw "No export path selected, cannot write report!" } $result } function Get-MdeOnboardingInfo { [CmdletBinding()] param ( [AllowEmptyCollection()] [string[]] $ComputerName, [AllowNull()] [PSCredential] $Credential, [AllowEmptyString()] [string] $LogPath ) $code = { param ( [string] $TargetName, [string] $LogPath ) function Write-Log { param ( [string] $Message, [AllowEmptyString()] [string] $Path ) if (-not $Path) { return } $parent = Split-Path -Path $Path if (-not (Test-Path -Path $parent)) { $null = New-Item -Path $parent -ItemType Directory -Force } '{0:yyyy-MM-dd HH:mm:ss} {1}' -f (Get-Date).ToUniversalTime(), $Message | Add-Content -Path $Path } $paths = @{ OnboardingKey = "HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status" LocalScriptKey = "HKLM:\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection" IntuneKey = "HKLM:\SOFTWARE\Microsoft\Windows Defender" SccmLogPath = "C:\Windows\CCM\Logs\EndpointProtectionAgent.log" } $status = @{ LatencyDetected = $false MdmDetected = $false SccmDetected = $false GpoDetected = $false Onboarded = $false } $result = [PSCustomObject]@{ ComputerName = $TargetName Status = "" Success = $true Error = $null } $onboardingData = Get-ItemProperty -Path $paths.OnboardingKey -ErrorAction Ignore $localScriptData = Get-ItemProperty -Path $paths.LocalScriptKey -ErrorAction Ignore $intuneData = Get-ItemProperty -Path $paths.IntuneKey -ErrorAction Ignore if (-not $onboardingData -and -not $localScriptData) { Write-Log 'Device is not onboarded.' $LogPath $result.Status = 'NotOnboarded' return $result } if ($onboardingData.OnboardingState -eq 1) { $status.Onboarded = $true Write-Log 'Device is onboarded' $LogPath } if ($localScriptData -and $localScriptData.latency -eq 'demo') { $status.LatencyDetected = $true Write-Log "Detected 'latency' = 'demo'." $LogPath } if (@($intuneData.MdmSubscriberIds | Where-Object { $_ }).Count -ge 1) { $status.MdmDetected = $true Write-Log "Detected non-empty 'MdmSubscriberIds'." $LogPath } if (Test-Path $paths.SccmLogPath) { $status.SccmDetected = $true Write-Log "Detected SCCM log file." $LogPath } if ($status.LatencyDetected -and -not $status.MdmDetected) { $result.Status = "Local Script" } elseif (-not $status.LatencyDetected -and $status.MdmDetected) { $result.Status = "Intune" } elseif ($status.LatencyDetected -and $status.MdmDetected) { $result.Status = "Local Script + Intune managed" } elseif ($status.SccmDetected) { $result.Status = "MCM" } elseif ($status.Onboarded) { $result.Status = "GPO" Write-Log "Device was onboarded via GPO" $LogPath } else { $result.Status = "NotOnboarded" } return $result } if (-not $ComputerName) { throw "No computer names provided." } $results = @() foreach ($name in $ComputerName) { $param = @{ ComputerName = $name ScriptBlock = $code ArgumentList = @($name, $LogPath) } if ($Credential) { $param.Credential = $Credential } try { $output = Invoke-Command param $results += $output } catch { $results += [PSCustomObject]@{ ComputerName = $name Status = "" Success = $false Error = $_.Exception.Message } } } return $results } $computers = Resolve-ComputerTarget -ComputerName $ComputerName -Path $ComputerList $outFile = Resolve-ExportFile -Path $OutPath Get-MdeOnboardingInfo -ComputerName $computers -Credential $Credential -LogPath $LogPath | Select-Object ComputerName, Status, Success, Error | Export-Csv -Path $outFile -NoTypeInformation Ensuring Effective Onboarding and with Microsoft Defender for Endpoint Understanding the specific onboarding method used for Microsoft Defender for Endpoint (MDE) on your devices is crucial for efficient troubleshooting and ongoing management. Identifying the onboarding path—whether through LocalScript, Intune, MCM, or GPO—not only allows administrators to pinpoint configuration issues more rapidly but also helps in verifying compliance with organizational security policies. By quickly determining the onboarding method, administrators can tailor their remediation steps, ensure proper policy application, and minimize endpoint security gaps. This knowledge streamlines support efforts, reduces downtime, and fosters a more secure and resilient environment for users and data alike. Explore additional resources: For further insights and guidance on MDE onboarding and troubleshooting, consider reviewing these related articles: Onboard Windows devices to Microsoft Defender for Endpoint. Troubleshoot onboarding issues for Microsoft Defender for Endpoint on Windows. Microsoft Defender for Endpoint onboarding status reporting. Manage Microsoft Defender for Endpoint with Intune. Onboarding methods for Microsoft Defender for Endpoint. Identify Defender for Endpoint onboarding method - Part 1.Determine Onboarding Methods in Defender for Endpoint - Part 1
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.
