Most teams structure Intune compliance like this: Detection script = logic + data. Every change = edit script. Every edit = redeploy. Every redeploy = test cycle, rings, delays. It works — until it doesn't scale.
Here’s the pattern we use instead: Separate logic from execution.
PowerShell script = pure extractor — reads registry, file versions, outputs flat JSON. Never changes.
JSON rules file = all compliance logic — which apps matter, version thresholds, enforcement rules.
When requirements change? Update the JSON file. Not the script. No redeploy. No testing cycle reset.
Most teams don’t realize Intune can support this pattern cleanly. They just keep rewriting scripts.
Where this breaks in production
Most environments don’t fail during deployment — they fail 30–90 days later when drift, versioning, and enforcement gaps show up.
- A device meets compliance at enrollment but drifts after a Windows update changes the baseline
- A compliance policy targets “All Devices” but a conditional access exclusion group silently bypasses it
- Devices show Compliant in the console but the underlying check hasn’t been re-evaluated since the policy changed
The compliance timestamp tells you when it was last evaluated — not whether the current state still matches.
Next: why your compliant devices might not actually be compliant. Or go back to what Intune doesn’t tell you.
— Hal
If your environment shows “all compliant” but you’re not confident the checks are right — that’s worth a look. Or reply with ASSESS.
Want more patterns like this?
Get the full 6-part guide — what Intune doesn't tell you, but you'll hit in production.
Running into this in production? 30 minutes — I will tell you directly if it is worth fixing.
Book a Fit Call →