So we drank the Kool-Aid and ran a 90-day E5 trial. As of midnight, every single Defender agent flipped to "Inactive" in the portal. No alerts, no sensor data, and our security team is having a collective aneurysm. Classic "license trap" scenario, but the speed of the decay was impressive.
The official docs suggest this is a licensing sync issue and to just wait. We don't have that luxury. Here's what actually worked to get agents reporting again, in order of escalation:
1. **Force a license check on the endpoint.** The sensor goes dormant if it thinks it's unlicensed. On a test machine, run an elevated PowerShell:
```powershell
& "%ProgramFiles%Windows DefenderMpCmdRun.exe" -RefreshPolicy
Restart-Service -Name Sense -Force
```
Check the portal after 10-15 minutes. If it's still inactive, move on.
2. **The registry hack.** This forces the agent to re-evaluate its license state. Found this buried in an old support thread.
```powershell
Stop-Service -Name Sense -Force
Set-ItemProperty -Path "HKLM:SOFTWAREMicrosoftWindows Advanced Threat ProtectionStatus" -Name "OnboardingState" -Value 0
Start-Service -Name Sense
```
You'll need to push this out via your config management if you're dealing with a fleet.
3. **The nuclear option: re-onboard.** If the above fails, the agent has likely fully orphaned itself. You'll need to re-run the onboarding script from the Defender portal. This is a massive pain at scale and resets the machine's historical context.
The real issue here is the architecture. The agent doesn't gracefully degrade to a "reduced functionality mode" – it just stops. For a platform that touts seamless integration with the Microsoft ecosystem, the licensing handoff is remarkably brittle. Anyone else seen this, or have a better fix that doesn't involve re-imaging?
Oh, the classic "wake up dead" scenario. Your registry hack is the real skeleton key here - I've had to use that after some truly cursed hybrid licensing migrations.
Just a heads-up, if you've got any machines that were onboarded via onboarding script (not Intune), that OnboardingState value might be a 1 instead of 0. Saw that once and spent an hour muttering at my screen before I checked the original deployment method.
The speed of the decay is still my favorite part. Goes from full enterprise-grade protection to digital tumbleweeds in the span of a cron job.
Exactly. The whole "onboarding script vs Intune" state mismatch is why I gave up on these manual registry fixes for anything more than a few test boxes.
If you're at scale, you need a configuration baseline. Use Intune or your config mgmt tool to set the correct OnboardingState based on a WMI query for the original onboarding path. Patching it manually is just whack-a-mole.
The real problem is designing a licensing cutoff that bricks the service instantly. That's an architectural choice, not a bug.
Simplicity is the ultimate sophistication
Good list, but I need to call out a major risk with that registry key hack. If you're using the modern unified solution with the Microsoft Defender for Endpoint sensor built into Windows Security, that specific `OnboardingState` path is deprecated. You'll break the sensor entirely.
The correct key for anything deployed in the last few years is under `HKLM:SOFTWAREMicrosoftWindows DefenderAdvanced Threat Protection`. I've seen teams nuke their entire fleet's telemetry by using the old path.
Also, pushing that via a script is fine, but you should wrap it in a check for the sensor version first. If `Get-MpComputerStatus` shows `AMRunningMode` is `SxS` or `EDRBlockMode`, you're dealing with the modern stack and shouldn't be touching the old key.
Automate everything. Twice.