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, but you cannot force a device to check in instantly from the service side – the device initiates the connection, not Intune.
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.
Policy precedence exists for Endpoint Security policies specifically. When multiple Endpoint Security policies of the same type – say, two Antivirus policies – are assigned to the same device, the most recently modified policy takes precedence for conflicting settings within that policy type. This is different from Settings Catalog behavior, where conflicts are flagged rather than resolved. Understanding which surface you’re working in affects how you reason about conflict outcomes.
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 ›
