Microsoft Defender for Endpoint Device Stuck Onboarding or Inactive

#Context

A device can be onboarded yet show as Inactive, or never appear in the portal. The usual causes fall into three layers: the Sense service is not running, the onboarding state is missing or incorrect, or the endpoint cannot reach the cloud service. Diagnose in that order and change nothing until you know which layer has failed. Version-specific behaviour, service names and URL requirements should be confirmed in the Microsoft Defender for Endpoint documentation.

Assumptions: a Windows device, local administrator rights, and a non-production or pilot device for first validation. Facts here come from the vendor documentation; the diagnostic order is a recommendation.

#Architecture

The endpoint sensor runs as the Sense service and sends telemetry to the cloud service. The portal can only show a device that completed onboarding and keeps reporting. Inactive therefore means that reporting has stopped or never started, not necessarily that the device is offline.

MDEClientAnalyzer is Microsoft’s client diagnostic tool. It collects service, onboarding and connectivity evidence so that the failing layer can be identified rather than guessed. Confirm the current download location and usage in the documentation.

#Implementation

Work through the layers in order.

1. Service layer: query the Sense service and record its state and start type. A stopped or disabled service explains Inactive status directly.
2. Onboarding layer: confirm the device received the onboarding configuration for the correct tenant, and check which method was used (policy, script, management tooling). Conflicting methods can leave the state unclear.
3. Connectivity layer: run MDEClientAnalyzer and review its connectivity results. Proxy settings, TLS inspection and blocked endpoints are common reasons a device cannot report.
4. Correct the cause: fix only the failed layer, such as the proxy or firewall rule, or re-apply the onboarding configuration through your standard management route.

For wider detection context, see detecting DNS tunnelling via resolver entropy, which also depends on understanding resolver and network paths.

#Validation

Success is observable: the Sense service is running, the analyser reports no connectivity failure, and the device moves from Inactive to a recent last-seen time in the portal. Allow time for reporting to resume, and confirm the expected interval in the documentation. Record the before and after evidence.

#Failure modes

• Service running but device still Inactive: usually a connectivity or proxy issue.
• Onboarding applied but device missing: wrong tenant configuration or conflicting onboarding method.
• Intermittent reporting: network inspection or unstable proxy authentication.
• Analyser itself fails: insufficient privilege or a blocked download; escalate to a human administrator.

#Security

Use least privilege and a pilot device first. Do not weaken security controls, such as disabling TLS inspection globally or adding broad firewall allowances, to make a device report; scope exceptions to the documented endpoints. Treat analyser output as sensitive, since it may contain hostnames and network details, and avoid sharing it publicly. Residual risk: a device that cannot report is unmonitored until fixed.

#Recovery

Before any change, record the current service configuration, proxy settings and onboarding method. If a change makes things worse, revert to the recorded settings and re-test. Do not offboard a device as a first response.

#Operational checks for inactive Defender devices

• Sense service running and set to its expected start type.
• Analyser connectivity results clean.
• Portal last-seen time recent after the fix.
• Rollback notes recorded.

#Prerequisites and permissions

#

Access needed on the endpoint

Use an elevated PowerShell session under a named administrator account, not a shared one. Confirm the session is elevated before collecting evidence:

1([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

The command should return True. If it returns False, stop and re-open the shell with elevation rather than working around the limitation.

#

Access needed elsewhere

• Read access to the Defender portal device inventory, so that you can compare last-seen time before and after.
• Read access to the management tool that delivers onboarding (Intune, Configuration Manager, Group Policy
  The KBY Lexicon

  Group Policy

  Group Policy centrally manages Windows computer and user configuration through GPOs linked to Active Directory containers, with a defined processing order, refresh cycles, and rollback via unlinking rather than deletion.

  Read Full Context
  or a script host), so you can see which method targets the device.
• Firewall or proxy read access, or a named contact who can read the logs for the device’s source address.
• An approved change record number before you alter any configuration.

#Implementation detail for each layer

#

Service layer evidence

Capture the state and start type, and keep the output in the ticket:

1Get-Service -Name Sense | Select-Object Name, Status, StartType
2Get-CimInstance Win32_Service -Filter "Name='Sense'" | Select-Object Name, State, StartMode, StartName, PathName

Then read recent service events for start failures:

1Get-WinEvent -LogName 'Microsoft-Windows-SENSE/Operational' -MaxEvents 50 | Format-List TimeCreated, Id, LevelDisplayName, Message

Record event identifiers exactly as they appear on the device and look them up in the vendor documentation. Do not infer meaning from an identifier you have not verified. If the service is stopped but its start type is Manual or Automatic, attempt a single start with Start-Service -Name Sense, then re-read the operational log. If the start type is Disabled, find what set it (policy, hardening script, third-party tool) before restoring it, otherwise the setting will be reapplied.

#

Onboarding layer evidence

Check the onboarding state held in the registry, read-only:

1Get-ItemProperty 'HKLM:SOFTWAREMicrosoftWindows Advanced Threat ProtectionStatus' | Select-Object OnboardingState, LastConnected

Whether these values are present, and how to interpret them, depends on the platform version, so verify against the documentation for your build. Alongside this, identify delivery sources: list the applicable Group Policy results with gpresult /h C:Tempgp.html, and check the management tool’s assignment report for the device. Two methods targeting one device is the usual source of an unclear state. Pick one authoritative method and remove the other through change control, not on the endpoint itself.

#

Connectivity layer evidence

Run the analyser from an elevated prompt and keep its output folder intact. Before that, capture the effective proxy configuration for both user and system contexts, because the sensor does not necessarily use the same route as an interactive browser:

1netsh winhttp show proxy
2Get-ItemProperty 'HKCU:SoftwareMicrosoftWindowsCurrentVersionInternet Settings' | Select-Object ProxyEnable, ProxyServer, AutoConfigURL

Compare the endpoint list in the analyser result with the list published in the vendor documentation for your region and tenant. Ask the network team to search proxy and firewall logs for the device address over the same time window and report whether connections were allowed, denied or reset. A reset or certificate substitution points towards inspection; a denial points towards a rule gap; no traffic at all points towards routing or a local proxy mis-setting.

#Expected evidence after correction

Note the time zone of every timestamp. Portal and endpoint times frequently differ, and mismatched zones waste investigation time.

#Monitoring

#

Fleet-level detection

Do not wait for individual reports. Review the device inventory on a schedule and filter on devices whose health state is Inactive. If you use advanced hunting, a query against the device information table can list devices by last report time; confirm table and column names in the current schema before saving it as a scheduled check, since schemas change.

#

Trend signals worth tracking

• Count of Inactive devices per site, so a single proxy or branch firewall fault stands out.
• Devices that flip between active and inactive more than once in a week, which suggests authentication or inspection instability.
• Devices inactive since a particular date, which can be matched against patch, image or policy changes in the change calendar.
• Newly built devices that never appear within the reporting interval the vendor documents.

#Realistic failure symptoms

• Many devices at one site go Inactive together: suspect a shared network change, such as a proxy certificate renewal or a firewall rule rollback, before suspecting the sensor.
• Only recently imaged devices are missing: the image may carry stale onboarding material, or the build process runs before the management agent applies configuration.
• Service starts then stops again: read the operational log for the reason, and check for security hardening that blocks the service or its dependencies.
• Analyser works interactively but the device still fails: the user proxy differs from the system proxy; compare the WinHTTP output above with the user settings.
• Device appears twice in the portal: a rebuild or rename may have produced a duplicate record; handle this as an inventory question and do not offboard the live device to clear it.

#Change-control records

#

Minimum content of the change record

• Device name, serial or asset tag, and operating system build.
• The failed layer, with the evidence that identified it.
• The exact setting, rule or assignment to be changed, and who owns it.
• Pre-change values captured as text: service configuration, WinHTTP proxy, onboarding method and portal last-seen time.
• Planned verification steps and the time at which they will be checked.
• Named approver and the person performing the change.

#

Handling network changes

A firewall or proxy exception is a change to a shared control. Raise it as a separate request that cites the vendor’s published endpoint list, states the source scope (the pilot device or subnet, not all clients) and carries an expiry or review date. Close the request only when the analyser result confirms the exception works and no wider access was granted.

#Escalation thresholds

• Within the working day: a single pilot device still Inactive after all three layers show healthy evidence. Escalate to the endpoint security owner with the analyser output.
• Same day, to the network owner: two or more devices on one network path fail the connectivity checks, or logs show resets on connections to the documented endpoints.
• Immediate, to the security operations lead: a server or other high-value asset, or a group of devices, has been unmonitored beyond the period your policy allows. Agree a compensating control, such as heightened network monitoring, while the fix proceeds.
• To Microsoft support: all local layers pass and the device remains Inactive beyond the documented reporting interval. Attach the analyser output, the change record and the timeline of attempts, after checking the files for information you are not permitted to share.

#Safe rollback actions

1. Restore the recorded service start type only if your change altered it, using Set-Service -Name Sense -StartupType <recorded value>.
2. Reinstate the previous WinHTTP proxy setting from your notes; if it was direct access, netsh winhttp reset proxy returns that state. Confirm that was the original value first.
3. Withdraw a firewall or proxy exception through the same change route that created it, and confirm the removal in the logs.
4. Return a device to its previous management group or policy assignment if a re-assignment caused conflicts, then wait for policy refresh and re-run the evidence capture.
5. After each rollback, repeat the service, onboarding and connectivity checks and add the results to the record, so the closing state is documented rather than assumed.

Avoid rollback steps that remove the onboarding configuration or uninstall the sensor. Those actions end monitoring and are not reversible without redeployment.

If the device remains Inactive after all three layers pass, escalate to Microsoft support with the analyser output rather than making further changes.