From Group Policy to Cloud Policy
The move to Intune is often framed as moving policy to the cloud. That framing is close enough to feel accurate and wrong enough to cause real problems.
In a traditional domain environment, policy follows order. Devices sit in organizational units. Group Policy Objects are linked, processed, and applied in a sequence that can be traced. When two settings conflict, order decides which one wins. You can reason backward from any unexpected outcome and usually find the answer somewhere in the chain. That model is hierarchical by design, and once you understand it, it’s predictable.
Intune doesn’t work that way.
There are no organizational units. There is no link order. There is no guaranteed processing sequence. Policies are assigned to groups, and devices evaluate everything assigned to them together. If two configuration profiles target the same setting with different values, neither one automatically overrides the other. The result is a conflict – and a conflict in Intune doesn’t resolve itself. It surfaces as a policy error that requires you to find and eliminate the overlap.
When something doesn’t behave as expected, the first response is usually to ask which policy won. In Intune, that’s often the wrong question.
This is the part that trips up experienced engineers most often. Not because the concept is difficult, but because the instinct to look for precedence rules runs deep. The more useful question is which policies are attempting to own the same setting – and why.
The Settings Catalog and Administrative Templates compound this. Both look familiar to anyone who has worked with ADMX-backed Group Policy. The interface resembles something you’ve seen before, and that resemblance creates a false sense of continuity. But they follow the same assignment model as everything else in Intune. They don’t introduce inheritance. They don’t resolve conflict through order. Two Settings Catalog profiles targeting the same setting can still produce a conflict regardless of when they were created or how they’re assigned.
The evaluation model is also different in a way that matters operationally. Group Policy applies during predictable events – boot, logon, background refresh – and assumes the device can reach a domain controller when it does. Intune assumes devices may be anywhere. Devices check in on their own schedule, report current state, and move toward the assigned configuration over time. There is no single authoritative processing moment. Policy converges rather than applies.
That convergence model changes how you reason about timing. In a GPO environment, “it hasn’t applied yet” usually means waiting for a refresh cycle. In Intune, the same symptom might mean a conflict is preventing application, a check-in hasn’t occurred, or a detection rule isn’t matching. The troubleshooting path is different.
I’m frequently asked whether existing GPOs can be imported into Intune. Many settings can be translated – Microsoft provides tooling for it. That doesn’t mean they should be. Most long-running GPO environments contain years of accumulated decisions: temporary fixes that became permanent, security experiments that were never cleaned up, overlapping controls added by different teams at different times. That structure worked because hierarchy resolved the conflicts it created. Intune won’t resolve those conflicts. It will surface them.
Bringing a decade of Group Policy history into Intune without reducing it first is one of the fastest ways to create an unstable environment from day one.
Cloud management is an opportunity to simplify – to define clear ownership of each setting and design for the platform you’re actually using. The goal isn’t to rebuild the domain model somewhere else.
Understanding this shift in how policy is evaluated isn’t just conceptual background. It directly shapes every design decision that follows – how baselines are structured, how assignments are organized, how changes are tested safely. That’s what the next articles in this phase address.
Intune Deployment Guide · Phase 1: Foundations
‹ Previous: [1.0] What Intune Is (and What I Had to Re-Anchor)
Next: [1.1.1] How Intune Evaluates Configuration Profiles ›
