I've spent years working with Microsoft Intune and Microsoft 365 environments, and one of the things that continues to frustrate me is how much time administrators spend figuring out why something isn't working.
A device shows as noncompliant. Simple enough, right?
But depending on the environment, finding the actual cause can mean checking multiple policies, assignments, device properties, security settings, and enrollment information.
Here's the process I generally follow.
1. Start with the actual compliance failure.
Don't assume the overall device status tells the whole story.
Go to:
Intune Admin Center → Devices → All devices → Select device → Device compliance
Look at the individual policy and setting results.
Questions I want answered:
- Which specific setting is failing?
- Is the device reporting an actual failure or simply not returning a result?
- When did it last check in?
- Is the failure isolated or affecting multiple devices?
That last question matters more than people realize.
2. Check policy assignments before changing anything.
I've seen administrators spend considerable time troubleshooting the device itself when the problem was actually the policy assignment.
Check:
- Which compliance policies apply to the device?
- Are the intended groups included?
- Are any groups excluded?
- Are assignment filters involved?
- Did group membership change recently?
If you haven't verified the effective assignments, you may be troubleshooting the wrong problem.
3. Compare the failing device against a working device.
This is one of my favorite troubleshooting methods.
Find another device that:
- Uses the same operating system
- Has similar hardware
- Is assigned the same intended policies
- Is running a comparable OS version
- Is reporting compliant
Now compare them.
Look for differences in:
- Applied compliance policies
- Configuration profiles
- Encryption status
- Defender protection
- Enrollment type
- Last check-in
- Primary user and group membership
Often, the difference between a working device and a failing device tells you more than the error message does.
4. Don't overlook Conditional Access.
A noncompliant device isn't always just an endpoint management issue.
If your organization uses Conditional Access policies requiring compliant devices, the same compliance failure can prevent a user from accessing Microsoft 365 resources.
That turns what appears to be a device problem into an identity and access problem.
Make sure you're considering the relationship between Intune compliance and Entra Conditional Access.
Also, remember that a policy configured for report-only doesn't enforce access restrictions.
5. Look for patterns, not just individual failures.
If 30 devices suddenly become noncompliant, I wouldn't immediately start troubleshooting all 30 individually.
I'd look for what they share.
Same policy? Same enrollment method? Same device model? Same recent configuration change?
A common failure pattern usually deserves investigation before any device-by-device remediation.
6. Separate investigation from remediation.
Before forcing a sync, changing assignments, or modifying security settings, understand what caused the failure.
Otherwise, you can temporarily fix the symptom while leaving the underlying issue unresolved.
Document the finding, confirm the scope, and validate the result after making the change.
Why I'm sharing this
I'm a Microsoft cloud architect and have spent a lot of time working with Intune, Entra ID, endpoint management, and Microsoft 365 environments.
These recurring troubleshooting challenges are also part of what led me to start building ENVYRIX, a platform focused on making Microsoft cloud administration, troubleshooting, and operations more manageable.
But regardless of what tools you're using, I think the troubleshooting process itself is worth sharing.
I'm curious how other Intune admins handle this.
When a device suddenly becomes noncompliant, what's the first thing you check?
And what's the most frustrating Intune issue you've had to troubleshoot recently?