Root Cause
Missing or misconfigured Azure AD Device Registration settings. The tenant's Device Settings do not allow all users (or the target group) to join Azure AD, or the MDM enrollment scope in Azure AD is not set to "All" / the target group. Also triggered when the Autopilot profile is unassigned or the device serial is not registered in MEM.
Resolution Steps
In Azure AD → Devices → Device Settings, verify "Users may join devices to Azure AD" is set to
All or includes the target user group.In Azure AD → Mobility (MDM & MAM) → Microsoft Intune, set MDM User scope to
All (or the target group) and confirm the MDM Terms of Use URL is populated.Go to MEM Admin Center → Devices → Windows → Enrollment → Deployment Profiles and confirm the Autopilot profile is assigned to the device group containing this device.
Verify the device serial number is registered under Devices → Windows → Enrollment → Devices (Windows Autopilot devices). If missing, import the hardware hash CSV.
On the failing device, collect the diagnostic ZIP: at the error screen press
Ctrl+Shift+D then export. Check MDMDiagReport.html for the specific sub-error code.If the sub-code is
aadsts50020 (guest account), ensure the provisioning user account is a member of the home tenant, not a guest/B2B account.Reset the device to factory defaults and retry provisioning after confirming all settings above are correct.
Useful Commands
# Run on device — view recent MDM enrollment events
Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" -MaxEvents 50 | Select TimeCreated,Message
For Hybrid Azure AD Join scenarios, also verify the Hybrid Azure AD Join connector is healthy in Azure AD Connect and that the device OU is in scope for the sync.
Root Cause
An app assigned as "required" in the ESP profile is failing silently. Common culprits: Win32 app detection rule mismatch, app content not uploaded to all DPs/CDN points, or a dependency app with a broken install command. The ESP waits for all required apps to report success — one failure blocks the entire flow.
Resolution Steps
On the stuck device, open Task Manager → Details tab and look for
IntuneManagementExtension.exe. Check its CPU usage — if 0% for several minutes, the extension may have crashed.Navigate to
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\ and open the latest IntuneManagementExtension.log. Filter for Failed or Error lines to identify the blocking app.In MEM Admin Center, go to the specific app → Device install status and confirm the device shows a failure status and note the error code.
Re-check the Win32 app's detection rule. Test it manually on a working device. A rule pointing to a path that does not exist will always report "not installed" keeping ESP in a loop.
If you cannot fix the app immediately, go to the ESP profile and either remove the problematic app from the "blocking apps" list or reduce the ESP timeout from 60 min to a lower value so it fails fast.
After fixing, sync the policy on a test device using: Settings → Accounts → Access work or school → Info → Sync and re-test the ESP flow.
Useful Commands
# Restart IME to force re-evaluation
Stop-Service IntuneManagementExtension -Force
Start-Service IntuneManagementExtension
Do not skip the ESP by pressing Ctrl+Shift+F3 in production — this exits audit mode and can leave devices in an unexpected state. Use it only for diagnostics on a disposable test unit.
Root Cause
Browser cookie/session conflict, or a Conditional Access policy requiring a compliant/hybrid-joined device that is not met. The authentication token is issued but the CA policy immediately blocks it, triggering a fresh challenge. Also caused by a corrupted browser session or the Primary Refresh Token (PRT) on the device being stale/missing.
Resolution Steps
First, test in a private/incognito window to rule out cached cookies. If sign-in succeeds, clear all browser data for
login.microsoftonline.com.In Azure AD → Sign-in logs, filter by the affected user and look for the failing sign-in. Check the Conditional Access tab on the event — identify which CA policy is blocking.
If the CA policy requires a compliant device, check the device compliance status in MEM → Devices. A grace period may have expired or a compliance policy rule may have changed.
On the Windows device, check PRT health:
dsregcmd /status
Look for
AzureAdPrt : YES. If NO, sign out of all accounts in Settings → Accounts, re-add the work account, and force a sync.As a last resort, in Azure AD → Users → [user] → Authentication methods, require the user to re-register their MFA method, then have them sign in fresh.
Use the What If tool in Azure AD Conditional Access to simulate the sign-in and confirm which policy fires before spending time debugging on a live device.
Root Cause
Corrupted Windows Update cache or SoftwareDistribution folder. The update agent expects a file at a calculated path inside
C:\Windows\SoftwareDistribution\Download\ but the file is missing or has a mismatched hash — often caused by a previous interrupted download.
Resolution Steps
Open an elevated PowerShell and stop the update services:
Stop-Service wuauserv,bits,cryptsvc,msiserver -Force
Rename (do not delete) the SoftwareDistribution folder:
Rename-Item "C:\Windows\SoftwareDistribution" "SoftwareDistribution.bak"
Rename-Item "C:\Windows\System32\catroot2" "catroot2.bak"
Restart the services:
Start-Service wuauserv,bits,cryptsvc,msiserver
Run the DISM health repair and SFC scan:
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
Reboot and attempt Windows Update again. Windows will rebuild the SoftwareDistribution folder from scratch.
If still failing on a specific KB, download the standalone package directly from the Microsoft Update Catalog and install manually.
The renamed SoftwareDistribution.bak folder can be deleted once the update installs successfully — it is no longer needed.
Root Cause
The DHCP scope's IP range is too small relative to the number of active leases, OR stale/ghost leases are consuming addresses. Stale leases accumulate when devices leave the network without releasing their IP (shutdown without
ipconfig /release). Also caused by DHCP starvation attacks (a form of DoS) where a rogue device requests all available addresses.
Resolution Steps
On the DHCP server, open DHCP Manager → Scope → Address Leases and sort by expiration date. Identify and delete clearly stale leases (devices offline for days).
Check lease duration — if it is set to 8 days (default), consider reducing to 4–6 hours for highly transient environments (meeting rooms, guest WiFi).
Extend the scope range if the subnet allows. Alternatively, add a superscope with an additional subnet range as a short-term bridge.
Check for duplicate MAC addresses in the lease table — multiple entries for the same MAC can indicate a loop or DHCP starvation attack.
Enable DHCP Snooping on managed switches to prevent rogue DHCP devices and restrict DHCP discovery traffic to trusted ports only.
Useful Commands
# Show scope statistics (Windows DHCP Server)
Get-DhcpServerv4ScopeStatistics -ScopeId 192.168.10.0
# List all active leases for a scope
Get-DhcpServerv4Lease -ScopeId 192.168.10.0 | Sort-Object LeaseExpiryTime
Rapid scope exhaustion (within hours) is a strong indicator of a DHCP starvation attack. Capture a packet trace on the scope's VLAN and look for bulk DISCOVER frames from spoofed MACs before extending the scope.
Root Cause
The SENSE service (the MDE sensor) is not running, or outbound connectivity to MDE cloud endpoints is blocked. Common causes: firewall blocking
*.security.microsoft.com / *.endpoint.security.microsoft.com, proxy requiring explicit authentication (Digest/NTLM not supported by SENSE), or the onboarding blob was applied to the wrong tenant.
Resolution Steps
Verify the SENSE service is running and set to automatic:
Get-Service -Name Sense | Select Name,Status,StartType
Run the MDE Client Analyzer tool on the device. Download from security.microsoft.com → Settings → Endpoints → Client Analyzer and run:
MDEClientAnalyzer.cmd
Check connectivity to required MDE endpoints. From an elevated PS:
Test-NetConnection -ComputerName "us.vortex.data.microsoft.com" -Port 443
Test-NetConnection -ComputerName "us4-v20.events.data.microsoft.com" -Port 443
If connectivity fails, add the required FQDNs to the firewall/proxy allowlist. Refer to the official MDE URL list documentation for your region.
Confirm the onboarding blob is from the correct tenant: open Registry Editor →
HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status and check OrgId matches your Azure AD Tenant ID.If OrgId is wrong, offboard first using the offboarding package from the MDE portal, reboot, then re-onboard with the correct package.
Devices appear as "Inactive" in MDE portal if no telemetry is received for 7 days. An "Onboarding" state lasting more than 1 hour almost always means a connectivity or service issue — not a portal delay.
Root Cause
Most common: DNS misconfiguration, firewall blocking port 135/445/49152+, tombstone lifetime exceeded (USN rollback), or an SRV record missing for _ldap._tcp.dc._msdcs. If SYSVOL is also absent, DFS-R replication service may have stopped or the SYSVOL set is in an error state.
Resolution Steps
Run a full diagnostic on all DCs:
dcdiag /test:replications /v
repadmin /showrepl * /errorsonly
repadmin /replsummary
Note the specific error codes from
repadmin. Common ones: 8453 (Access Denied), 1722 (RPC Server Unavailable), 8614 (tombstone exceeded).Test DNS resolution between DCs — each DC must resolve the other DCs' hostnames and the
_msdcs SRV records:nslookup -type=SRV _ldap._tcp.dc._msdcs.yourdomain.com
Force replication from a healthy DC to the problematic one:
repadmin /syncall /AdeP
If SYSVOL is missing, check DFS-R replication health:
dfsrdiag ReplicationState /member:DCName
Get-WinEvent -LogName "DFS Replication" -MaxEvents 20 | Where Message -match "Error"
If error
8614 (tombstone exceeded) is present, the only safe path is a full DC metadata cleanup and DC demotion/re-promotion using a clean media (IFM).Never force-delete a DC from the site topology without first verifying the tombstone lifetime issue. A hasty metadata cleanup on a DC that was temporarily unreachable (not truly failed) can cause permanent AD data loss.
Root Cause
The detection rule does not match what the installer actually writes to the registry. Installation and detection are two completely independent mechanisms in Intune. A Win32 app can install perfectly and still be reported as "not installed" if the
DisplayName or DisplayVersion in the detection rule differs — even by one character — from the value written under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\. Tools that auto-generate detection rules (such as PatchMyPC in Custom App mode) are particularly susceptible because they use whatever name you type into their form, not what the installer actually registers.
Real-World Example — FortiClient VPN via PatchMyPC
Encountered at a client site deploying FortiClient VPN via PatchMyPC Custom App. The installer ran cleanly, the VPN was fully operational on every device, but Company Portal showed "This app is no longer detected on your device" for all users.
Querying the registry revealed the mismatch immediately:
DisplayName = FortiClient ← what the installer writes
DisplayVersion = 7.2.14.1296 ← what the installer writes
Installed Apps Name = FortiClient VPN ← wrong (marketing name)
Version = 7.2.14 ← incomplete (missing build number)
The detection rule was looking for a registry entry named "FortiClient VPN" that never existed — Fortinet's installer always registers the app as "FortiClient". The rule failed silently on every device.
Resolution Steps
On an affected device, query the 64-bit uninstall registry hive to find the exact
DisplayName written by the installer:reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" /s /f "YourAppName" /d
If the app is a 32-bit installer on a 64-bit OS, also check the
WOW6432Node hive:reg query "HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall" /s /f "YourAppName" /d
Once you have the GUID, retrieve the exact
DisplayVersion:reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{YOUR-APP-GUID}" /v DisplayVersion
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{YOUR-APP-GUID}" /v DisplayName
Update the detection rule in your deployment tool (Intune / PatchMyPC) so that Installed Apps Name matches
DisplayName exactly, and Version matches DisplayVersion exactly (or use a ≥ operator if the tool supports it).Also verify that the Architecture setting (32-bit vs 64-bit) and Scope (System vs User) match the actual install — a scope mismatch sends the detection rule to the wrong registry hive (
HKLM vs HKCU).After updating the rule, force an Intune Management Extension sync on the test device to trigger immediate re-evaluation:
# Force IME sync (CMD, no PowerShell needed)
"C:\Program Files (x86)\Microsoft Intune Management Extension\Microsoft.Management.Services.IntuneWindowsAgent.exe" sync
# Or restart the IME service if the above doesn't trigger
net stop IntuneManagementExtension && net start IntuneManagementExtension
Confirm detection passes by searching the IME log for your app name — you should see
Detected instead of NotDetected:notepad "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log"
Detection Rule Checklist
| Field | Must Match | Common Mistake |
|---|---|---|
| Installed Apps Name | DisplayName in registry | Using marketing name instead of installer-registered name |
| Version | DisplayVersion in registry | Truncated version (e.g. 7.2.14 instead of 7.2.14.1296) |
| Architecture | Actual install bitness | 64-bit rule checking WOW6432Node (wrong hive) |
| Scope | System = HKLM, User = HKCU | System install detected as User scope |
PowerShell being disabled is not a blocker. All the registry queries and IME interactions above work in pure CMD. The
reg query command and net stop/start are available on every Windows installation regardless of execution policy.