Intune detection rule generator
Drop an installer and get the detection rule for it, with the version operator set so a new build still applies. Get this wrong and Intune either never sees the app, or won’t let you update it.
Parsed in your browser. Nothing is uploaded.What usually goes wrong
You can test an install command in about a minute. Run it, and it either goes in silently or it doesn’t. Detection doesn’t have this moment. A bad rule works fine on your test box and then falls over months later across the fleet, and what you actually see (an app reinstalling itself over and over, or one that says it’s installed when it isn’t) doesn’t look anything like a detection problem.
The version operator is where it usually happens. Set it to “Equals” and the rule only matches one build. Ship an update, Intune decides the app is gone, and it pushes the old version back over the new one. Everything generated here uses “Greater than or equal to” instead.
Open source
It's MIT-licensed at github.com/deadarcher/intune-detection. The engine on this page is byte-identical to the one in the repo, and our CI fails the build if they ever drift. You can run it over a folder of installers from Node, or self-host the page with one line of Docker:
docker run --rm -p 8080:80 ghcr.io/deadarcher/intune-detection:latestGot a wrong rule? Open an issue with the installer's name, where to download it, and the rule you expected.
Questions
Why does my app show as not installed after an update?
Almost always the version operator. "Equals" is what everybody picks first, and it works right up until the first update. The app installs, detection matches, then a new version ships and the rule matches nothing, so Intune calls it not-installed forever and keeps pushing the old build over the new one. Everything here uses "Greater than or equal to", which survives updates and still comes back not-detected when the app really is missing or older.
Is a file-exists rule good enough?
It’s the most common rule and it’s the one that burns people. All it tells you is that something got written to disk at some point. Not that this version is there, and not that the install finished. It reports detected on a machine with a half-finished install, and it keeps reporting detected after a failed upgrade. Use the MSI product code if there’s one, otherwise a registry or file rule with a version check on it.
Why is the registry rule two rules?
Uninstall keys live in two registry views. A 32-bit installer on 64-bit Windows lands under WOW6432Node and a 64-bit one doesn’t, and you can’t always tell which from the file alone. When it isn’t certain you get both paths, so you can check one machine and use whichever it turns out to be.
Is anything uploaded?
No. It’s parsed in your browser. Nothing leaves the machine, and you can watch the network tab to confirm that.
What about a script rule?
You get one when none of the field-based rules can be filled in completely. Scripts can do more, but they’re much easier to get wrong. The classic mistake is exiting 0 on both branches, which means it can never come back not-detected and Intune thinks the app is installed everywhere. The one generated here writes to STDOUT and sets a zero exit code on one branch only.