Packaging knowledge
Detection rules that survive updates
Registry, file or script: how Intune detection works, why version checks break and how to keep 32- and 64-bit paths apart.
Three routes and their limits
Intune knows three detection types: registry, file and custom script. All three answer the same question — is the state reached? — with different precision. Registry is fast and stable. File is simple but version-tolerant. A script is powerful and slow.
Registry: the stable case
A registry key only this product writes is the most reliable detection. What matters is the right path, the right value and the right view: a 32-bit process sees a different branch under HKLM\Software than a 64-bit process. Mix them up and you look in the wrong place, then treat an installed package as missing.
File and version
A file check is good when the file only exists because of this package. A version check is more precise but breaks on the next update: if detection is not updated too, the new version counts as “not installed” and gets deployed again. Testing rarely catches this because the test device usually has one version.
Script: when it is worth it
A script makes sense when the state has several conditions: service running, file present, registry value set. It is the slowest route because Intune runs it on every device. For simple cases it is over-engineering.
The 32/64-bit mistake
The most common silent failure. The installer writes to the 64-bit view, detection reads the 32-bit view. Result: the package installs, detection fails, Intune retries. The log shows an error that looks like an install failure but is not.
Testing detection
Three steps: install on a clean device, check detection, uninstall and check again. Testing only the first step is testing half. And detection changed after every update should be treated as part of the package, not as an afterthought.
---