A Windows device can look fully protected on the desktop and still fail the check that matters most to a security team: appearing and reporting correctly in the Microsoft Defender Portal.
In this case, the device was locally healthy but invisible to the security stack. While a recent device rename looked like the culprit, the root cause was a fundamental change in Windows 11 24H2: the removal of the Sense client from the base image.
1) The issue: what was really happening
On Windows 11 24H2, Microsoft Defender for Endpoint (MDE) is no longer guaranteed to be in the base image. According to KB5043950, if a device moves from Home to Pro, or is an OEM Pro SKU, the MDE sensor may need to be installed manually.
The Symptom:
- Local AV: Green. Real-time protection is ON.
- Onboarding Registry: Says
0x1(Onboarded). - Defender Portal: Device is missing or “Inactive.”
The “Sense” client (the behavioral sensor) was missing or stuck in a Staged state, meaning the onboarding artifacts were there, but there was no “engine” to run them.
2) Diagnostic steps
The only reliable way to diagnose this kind of issue is to separate the stack into layers. For IT admins, that means checking local antivirus, onboarding state, OS build, capability state, service health, and reporting logs rather than assuming one green check proves the whole chain.
Check local Defender health first
The first command was:
#Powershell
Get-MpComputerStatus | Select AMRunningMode,AntivirusEnabled,RealTimeProtectionEnabled,IsTamperProtectedThis showed the endpoint was locally healthy. That mattered because it ruled out a basic Microsoft Defender Antivirus failure. But it did not prove that the device was successfully onboarded and reporting to Defender for Endpoint. Microsoft’s guidance on onboarding validation and event troubleshooting consistently separates these concepts.
Check whether the Sense service exists
The next step was:
#CMD
sc query senseAt first, the system returned 1060, meaning the service did not exist as an installed service. That was a major red flag. Microsoft’s onboarding troubleshooting points to SENSE as the internal name of the behavioral sensor that powers Defender for Endpoint, and it specifically directs admins to the SENSE event log when devices are not appearing correctly. A missing service is therefore not a cosmetic issue. It indicates the sensor path is not healthy.
Check onboarding state in the registry
The next check was:
reg query "HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status" /v OnboardingStateThis returned 0x1. That told us onboarding artifacts were present. But again, it did not prove that the machine was actually reporting to the portal. This was one of the most important clues in the whole investigation: the device looked onboarded on paper, but the sensor that should make that onboarding operational was not healthy.
Confirm the OS version
Then I checked the OS build and found Windows 11 Enterprise build 26100, which Microsoft identifies as Windows 11 version 24H2. That changed the whole troubleshooting angle because it brought KB5043950 directly into scope. Once you know the device is 24H2, you have to consider the Windows capability model for Sense rather than assuming the sensor is part of the old baseline image.
Check the Sense client capability
The key command was:
DISM /Online /Get-CapabilityInfo /CapabilityName:Microsoft.Windows.Sense.Client~~~~The initial result showed State : Staged instead of Installed. That was the breakthrough. Microsoft’s Features on Demand documentation says the SENSE Client for Microsoft Defender for Endpoint on Windows 11 24H2 and later uses the capability name Microsoft.Windows.Sense.Client~~~~, and it specifically notes that the FoD should be added using DISM /add-capability. Microsoft also recommends preinstalling it on editions above Home, including Pro, Enterprise, and Education.
When you compare that with KB5043950, the story becomes very clear: the machine was on a Windows version where the required MDE component is no longer guaranteed in the base image, and the capability had not fully reached the required installed state.
Check whether the SENSE log exists
We also checked:
wevtutil el | findstr /I SENSEAt first, the SENSE log was missing. Later, after remediation, Microsoft-Windows-SENSE/Operational appeared. Microsoft’s onboarding troubleshooting and event review documentation both point admins to that exact log when diagnosing onboarding and service issues. Its appearance was a clear sign that the sensor components had finally been registered properly.
3) The solution steps
Once the real root cause was clear, the fix path became straightforward.
Step 1: Confirm the device is Windows 11 24H2
This matters because the workaround depends on the 24H2 capability model.
systeminfo | findstr /B /C:"OS Name" /C:"OS Version"If you see build 26100, Microsoft identifies that as Windows 11 version 24H2.
Step 2: Check the Sense capability state
Run:
DISM /Online /Get-CapabilityInfo /CapabilityName:Microsoft.Windows.Sense.Client~~~~If the state is anything other than Installed, you have found the likely root cause. In this case it was Staged, which was not enough for a healthy MDE sensor path. Microsoft’s documentation on Features on Demand and KB5043950 both support that conclusion.
Step 3: Install the Sense capability
This was the decisive repair:
DISM /Online /Add-Capability /CapabilityName:Microsoft.Windows.Sense.Client~~~~That command is explicitly given in Microsoft’s KB5043950 as the workaround for affected Windows 11 24H2 devices. Once the capability was installed properly, the missing pieces began to appear.
Step 4: Recheck the capability and the log
After the install, the capability state changed to Installed, and the system began showing:
wevtutil el | findstr /I SENSEwith Microsoft-Windows-SENSE/Operational present. That was a strong sign the endpoint sensor stack had finally been registered correctly.
Step 5: Verify and start the service
Next:
sc query senseand if needed:
sc start senseThe service eventually moved to RUNNING, which was the turning point. Microsoft’s event-error documentation makes clear that devices are not reporting correctly when the service fails onboarding-related startup or configuration steps, so seeing the service healthy again was critical.
Step 6: Validate reporting
After that, the correct final check was Microsoft’s Defender for Endpoint detection test. Microsoft says this validates whether a device is properly onboarded and reporting, and a successful test should create an alert in about 10 minutes.
At that stage, the device appeared in the Defender portal. That is why the fix path should be described as a Sense client repair on Windows 11 24H2, not as a rename correction.
5) Remediation and detection scripts
The goal here is to prevent repeat incidents. Since Microsoft now treats the Sense client as a Feature on Demand on Windows 11 24H2+, I’ve built automation to handle it. You can find the scripts on my GitHub
Remediation: Installs the Sense capability if needed, verifies onboarding, starts the service, and generates troubleshooting logs if it fails.
Detection: Verifies the Windows build, OnboardingState, Sense capability, and service status.
Final conclusion
When a device is locally protected but missing in the Defender portal, especially on Windows 11 24H2, do not stop at the obvious explanation. Check the build, the Sense capability, the service and the reporting path. In this case, that is what turned a confusing “portal issue” into a clean, repeatable remediation.
