What This Article Is For
This article is for the simple non-compliant device scenario used in this lab. It is intentionally based on the locked compliance policy CP-W11-Basic-Compliance, which requires Microsoft Defender Antimalware and Windows Firewall.
That narrow scope is deliberate. For a beginner project, the goal is not to simulate every possible compliance failure. The goal is to understand one compliance rule set clearly enough that you can explain how the device was healthy, how it became non-compliant, how you diagnosed the failing condition, and how you returned it to the expected state.
The most useful version of that story in this lab is turning Windows Firewall off, observing the non-compliant result, and then remediating it cleanly.
Symptom
W11-M365-ENDP01 shows as non-compliant or stops showing the expected compliant result in Intune.
In real support work, the important thing about this symptom is that it sounds simple but can still mean different things. The device might truly be non-compliant. The device might have the wrong assignment. The portal might simply be waiting for a new check-in. Good support work starts by separating those possibilities instead of assuming the first visible status is the full story.
What You Are Trying To Understand
When a device shows as non-compliant, you are really trying to answer three questions:
- Is the device truly failing a rule, or is the portal still waiting for fresh status?
- If it is failing a rule, which rule is actually failing?
- What small action would correct the problem without turning the troubleshooting into guesswork?
Those questions matter because compliance status is often where beginners feel uncertain. The portal can show a red or warning state, but that does not automatically tell you whether the problem is the device, the assignment, or timing.
Scope Of This Article
This article assumes the lab uses the following locked setup:
- compliance policy:
CP-W11-Basic-Compliance - rule 1: require Microsoft Defender Antimalware
- rule 2: require Firewall
- target group:
SG-Intune-Pilot
Because of that locked setup, the cleanest and easiest-to-defend failure in the lab is Windows Firewall being off.
That is also why this article does not try to teach every Intune compliance concept. It is meant to teach one realistic troubleshooting pattern well.
Checks
1. Confirm The Device Is Enrolled And Visible In Intune
Start by confirming that W11-M365-ENDP01 is still present in Intune as the device you expect to be troubleshooting.
This is important because compliance results only make sense when you are clearly looking at the correct managed device.
2. Open The Device Compliance Details
Open the device compliance view and identify which setting is reported as failing.
This matters because “non-compliant” on its own is too vague. You need to know whether the issue is the firewall rule, the antivirus rule, or something else about the reporting state.
3. Confirm The Policy Is Assigned Correctly
Check that CP-W11-Basic-Compliance is assigned to SG-Intune-Pilot and that the user or device still fits the intended target path.
This check is useful because sometimes the problem is not that the device failed the rule. Sometimes the issue is that the expected assignment path is no longer what you think it is.
4. Confirm Recent Check-In Activity
Review the device’s recent sync or check-in information.
This matters because cloud management tools do not always reflect endpoint changes instantly. A stale status can look like a deeper issue if you do not first consider timing.
5. Check The Actual Endpoint State
On the Windows 11 endpoint, confirm whether Microsoft Defender AV is active and whether Windows Firewall is on.
This step is what connects the portal result to reality on the device. In this lab, that connection is a major learning point. You are not only reading status from Intune. You are checking whether the endpoint condition actually matches the compliance result.
6. Decide Whether The Problem Is Real Or Delayed
After those checks, decide whether you are looking at true non-compliance or delayed reporting.
That distinction matters because the remediation is different. A real rule failure needs correction on the endpoint. A delayed state may only need a sync and some patience.
Likely Causes And What They Mean
If Windows Firewall is turned off, that is a genuine device-state issue. In this lab, it is the most useful failure because it is easy to create, easy to explain, and easy to validate after remediation.
If the policy assignment is wrong, the problem is not really “bad device behaviour.” It is a targeting problem.
If the device has not checked in recently, the problem may not be compliance at all. It may be stale reporting.
If the device is still very new and processing post-enrollment work, the issue may simply be that the management state has not settled yet.
Remediation
Remediation should stay tied to the actual failing condition.
If the problem is Windows Firewall being off, turn Firewall back on, then sync the device and wait for Intune to refresh the result.
If the issue is stale reporting, start with a manual sync and give the portal time to update before making other changes.
If the issue is wrong assignment, fix the target path rather than changing unrelated settings on the endpoint.
The reason this matters is simple: support work is strongest when the action clearly matches the diagnosed cause. Broad, unfocused remediation teaches bad habits and makes later explanation much harder.
Validation
Validation means confirming that the device checks in again and that the compliance result returns to the expected compliant state.
In this lab, strong validation should also include before-and-after evidence. If you can show the failing firewall-related state, the remediation step, and the final compliant result, the story becomes much easier to defend in interview.
Your notes should record which setting failed, what change you made, and how you confirmed the result afterwards.
What To Write In The Ticket Or Notes
A useful note for this case does not need to be long. It needs to be precise.
It should explain that the device moved from compliant to non-compliant because the firewall-related requirement was no longer met, that the endpoint state was checked directly, that Firewall was restored, that the device was synced, and that Intune later returned the device to compliant.
That kind of note proves structured troubleshooting. It also gives the next person enough context to understand what happened without reopening the whole investigation from scratch.
Handoff Notes
Escalate if:
- the device repeatedly fails compliance after the relevant setting is corrected
- the visible endpoint state does not match the Intune result for an extended period
- enrollment or policy processing errors suggest a deeper platform issue
As with the failed sign-in article, escalation here is part of good support judgement, not evidence that the troubleshooting failed.