Understanding how Intune actually processes and evaluates configuration profiles changes how you design them. Not just conceptually – it changes specific decisions about how many profiles to create, how to structure assignments, and how to troubleshoot when something doesn’t apply as expected.
The previous article established that Intune doesn’t apply policy the way Group Policy does – no deterministic order, no hierarchy, no last-writer-wins resolution. This article gets into the mechanics of what actually happens when a device checks in and how Intune decides what to apply, what to report, and what to flag as a conflict.
Devices check in with the Intune service on a schedule, not continuously. For Windows devices, the default check-in interval is approximately every eight hours once the device is enrolled and policies have initially applied. The first check-in after enrollment happens within minutes. Subsequent check-ins happen on the eight-hour cycle, with some randomization built in to prevent all devices in a large fleet from contacting the service simultaneously. You can trigger a manual sync from the Intune portal or from the device itself, and the service side has more reach than it used to: the Sync remote action tells a device to check in immediately, and assigning or changing a policy sends change notifications that make online devices sync within minutes. The transport is still device-initiated – Intune notifies, the device connects – but waiting out the eight-hour cycle is no longer the whole story.
This check-in model is why “it hasn’t applied yet” has a different meaning in Intune than in Group Policy. In GPO, you wait for the next refresh cycle, which is predictable and relatively short. In Intune, the device may genuinely not have checked in yet – and there’s no way to know from the portal whether the delay is a check-in timing issue, a connectivity issue, or a conflict preventing application. The device compliance and configuration status in the Intune portal reflects the last reported state, not the current state on the device.
Intune reports what the device last told it. If the device hasn’t checked in recently, the portal is showing you stale data. This matters enormously when troubleshooting.
When a device checks in, it receives the list of policies assigned to it and evaluates each one. For Settings Catalog policies, the device processes each setting individually and applies it to the local configuration. The device then reports back the status of each setting – applied, not applicable, or error – which flows into the policy reporting visible in the Intune portal. This reporting is per-setting, which means you can see exactly which settings within a profile succeeded, failed, or weren’t applicable to the device’s configuration.
Conflict behavior is where the evaluation model has the most practical impact. When two profiles assigned to the same device attempt to configure the same setting with different values, Intune reports a conflict for that setting. The conflict doesn’t resolve automatically – neither value wins. The setting remains in whatever state it was in before the conflicting policies arrived, and both policies report a conflict status in the portal.
This is distinct from how different policy types interact. Settings Catalog policies and Endpoint Security policies can both configure settings that affect the same device behavior, but they use different CSP paths in some cases. The conflict detection doesn’t always catch cross-type conflicts – two policies from different surfaces can both attempt to configure related behavior without Intune flagging a conflict, while producing inconsistent results on the device. This is one of the reasons keeping Settings Catalog configuration and Endpoint Security policies clearly separated by function – as the OIB naming convention enforces – reduces ambiguity about which policy owns which setting.
Conflict detection in Intune is per-setting, per-policy-type. It won’t always catch interactions between Settings Catalog and Endpoint Security policies targeting related behavior. Clean ownership of each setting is the only reliable defense.
Endpoint Security policies are not an exception to this. All Intune policy types carry equal precedence, so when multiple Endpoint Security policies of the same type – say, two Antivirus policies – set the same setting to different values, the result is a flagged conflict that needs manual resolution, not a quiet winner. The narrow carve-out is Defender Antivirus. A handful of Antivirus settings, the exclusion lists, support policy merge and combine into a single superset instead of conflicting. For Antivirus settings that don’t merge, there is a tiebreak: the most secure value applies first, the most recently modified policy second, and if that still can’t decide, the device gets no policy for that setting at all. That is a last resort, not a precedence model to design around.
Not applicable is a distinct status from conflict or error and is frequently misread. A setting reported as not applicable means the device’s configuration doesn’t support that setting – the wrong Windows edition, the wrong hardware, a feature not present in that OS version. Not applicable is not a failure. It’s the device correctly reporting that the setting doesn’t apply to it. Chasing not applicable status in reporting is a common waste of troubleshooting time.
The practical implications of this evaluation model shape how Phase 5 is structured. Modular policies with clear ownership of each setting eliminate the conditions that produce conflicts. Consistent naming that encodes policy type and control surface makes it visible which policies own which settings. Staged assignment through rings limits the blast radius when a conflict or misconfiguration surfaces. The evaluation mechanics aren’t abstract – they’re the reason the design principles in this phase exist.
Intune Deployment Guide · Phase 1: Foundations
‹ Previous: [1.1] From Group Policy to Cloud Policy
Next: [1.1.2] Why I Design Baselines in Modular Sections ›
