The instincts I relied on for years still worked – just enough to be misleading.
I didn’t come into Microsoft Intune green. I came into it with years of experience managing Windows devices in environments where authority was clear, timing mattered, and policy behavior could usually be explained after the fact, even when things were messy. I knew how to reason about outcomes, and I trusted that the system would reward that reasoning.
What caught me off guard wasn’t complexity. It was that the instincts I’d relied on for a long time still worked just enough to be misleading. The system responded. Policies applied. Devices checked in. But the explanations I was used to leaning on stopped lining up cleanly with what I was seeing on the screen and, more importantly, on the endpoint itself.
I initially approached Intune through a Group Policy lens – not because I thought it was the same tool, but because that lens had been the correct abstraction for most of my career. Policies existed, devices applied them, and when outcomes didn’t match expectations, the answer was usually somewhere in scope, inheritance, or precedence. That way of thinking had held up across a lot of environments and a lot of years.
With Intune, that mental model didn’t fail outright. It just slowly stopped explaining things. Devices behaved reasonably, but not predictably. Settings reported success without producing the outcome I expected. Changes took effect, just not in a way that respected the timing or ordering I was used to designing around. That was the point where I stopped assuming something was broken and started questioning whether I was still using the right model to reason about what was happening.
Once I stopped trying to force my old explanations onto what I was seeing, a different picture started to emerge. Intune wasn’t inconsistent. It was consistent in a way I hadn’t designed for yet. Devices weren’t waiting for instruction. They were reporting where they already were, reconciling intent over time, and making decisions based on identity and state rather than timing or order. The more I watched that behavior, the harder it became to pretend this was just Group Policy with cloud latency.
That’s when I had to reset how I thought about what Intune was actually responsible for.
I don’t think of Intune as a system that configures devices anymore. I think of it as a system that expresses intent and evaluates posture. It looks at who the user is, what kind of device they’re on, how that device is joined, and what state it’s reporting right now. Based on that, it decides what should apply and what conditions should be met. The device then works toward that state on its own timeline, checking back in, adjusting, and re-evaluating as things change.
Once you accept that Intune isn’t trying to be immediate or authoritative in the old sense, a lot of the behavior that feels slippery at first starts to make sense. Delays stop feeling like failures. Re-evaluation stops feeling random. Even conflicts are easier to reason about once you stop expecting a single authoritative moment where everything applies cleanly and stays that way.
What helped me most was recognizing what Intune very deliberately avoids doing. It isn’t trying to be a real-time configuration engine. It isn’t trying to guarantee order of operations. It isn’t trying to resolve conflicts in a way that mirrors inheritance or precedence. And it definitely isn’t assuming that devices live on a network you control. Every time I designed as if those things were true, I ended up compensating with more profiles, more assignments, and more logic than the environment actually needed. The design would technically work but feel fragile – like it only held together as long as nothing unexpected happened.
The part that really forced me to let go of old instincts was understanding where authority actually lives. Intune doesn’t establish identity. It doesn’t authenticate users. It doesn’t ultimately decide whether someone gets access to a resource. That authority lives with Microsoft Entra ID and the access controls built on top of it. Intune’s role is narrower and more specific – it evaluates device posture and reports whether a device should be considered healthy enough for access decisions to proceed. That signal gets consumed elsewhere. Intune isn’t the gate. It’s one of the inputs to the gate.
Once I internalized that, I stopped expecting Intune to feel final. Instead of asking whether something had applied, I started asking what signal it was feeding and where that signal actually mattered. That shift alone cleaned up a lot of my designs.
I won’t pretend this model feels as immediately solid as on-prem tooling did. Those systems gave you something to point at – a controller, a hierarchy, a place where you could say with confidence that this is the source of truth. Intune doesn’t give you that anchor. What I’ve come to accept is that the certainty I was used to depended on assumptions that no longer hold. Devices move. Users roam. Networks are no longer a meaningful trust boundary. Designing as if they are just creates a different kind of fragility – one that’s harder to see until it breaks.
When I design Intune environments today, I start by being explicit about what role Intune is supposed to play in the larger system and what responsibilities it intentionally leaves to other layers. If I skip that step, everything that follows feels over-engineered. If I get it right, the environment feels coherent – even when it’s operating on its own timeline.
The next article is where that gets specific. What actually changed when we moved from Group Policy to cloud policy, and why the instincts that served us well for years stop helping here.
Intune Deployment Guide · Phase 1: Foundations
Next: [1.1] From Group Policy to Cloud Policy ›
