When deploying Win32 apps via Microsoft Intune, a failed detection rule means a failed deployment, endless retries, and false non-compliance reports. Choosing between file, registry, or custom PowerShell script detection dictates how reliably Endpoint Manager tracks your legacy EXEs.
The Fast Verdict: Choosing Your Detection Method
| Detection Type | Reliability | Best Used For |
|---|---|---|
| MSI Product Code | Absolute | Native MSIs or properly automated conversions |
| File / Folder | Moderate | Applications that reliably update their main executable version string |
| Registry | High | Apps that write consistent Uninstall strings to HKLM\SOFTWARE |
| PowerShell Script | Variable | Complex OR logic, verifying file contents, or apps that leave no standard footprint |
The Rule of Thumb
Stop relying on complex scripts: Writing custom PowerShell detection scripts for standard software introduces maintenance overhead. If the script logic breaks during an app update, your entire deployment reports as failed.
Target standard footprints: Always default to MSI Product Code detection first. If forced to use file or registry rules, target the exact application version string rather than simple file existence to ensure Intune actually processes updates.
The Faster Path: Automating the MSI Product GUID
Relying on custom registry lookups or file path variables for legacy EXE deployments forces infrastructure engineers to manually reverse-engineer every application they package.
InstallMage eliminates this manual overhead entirely. Instead of writing custom PowerShell detection scripts to verify an EXE deployment, InstallMage automatically converts the legacy installer into a native MSI database. This process generates a standardized MSI Product Code. When you upload the converted package to Intune, the system auto-populates the detection rule using this GUID. You get a bulletproof, zero-maintenance detection rule without writing a single line of code.
Technical Deep Dive: Detection Logic Failures
1. The Pitfalls of File-Based Detection
Relying on simple file existence (e.g., checking if C:\Program Files\App\app.exe exists) is dangerous. If you push an updated version of the software, Intune will see the existing file, assume the device is already compliant, and skip the update entirely. You must use String (version) rules and apply the 'Greater than or equal to' operator, which requires manually validating that the vendor actually increments the file version metadata.
2. Registry Detection Nuances
Registry detection is generally safer than file detection, specifically when targeting the Uninstall key. However, tracking integer or string comparisons requires ensuring the software runs in the correct 32-bit or 64-bit context. Selecting the wrong context in the Intune portal will result in instant detection failures on 64-bit clients.
3. When Custom Scripts Actually Make Sense
Reserve custom PowerShell detection scripts strictly for edge cases. If an application requires multiple registry keys to exist simultaneously, or if you need to read the contents of a local configuration file to verify a successful installation state, a script returning an exit code of 0 with standard output (STDOUT) is your only option. For standard applications, it is an unnecessary operational risk.
Frequently Asked Questions
Why does my Win32 app keep retrying after a successful install?
Intune successfully executed the install command, but the specified detection rule failed to find the target file, registry key, or script output. Ensure your detection logic matches the exact post-installation state of the endpoint.
How does Intune read script output for compliance?
For a PowerShell detection script to report success, it must exit with code 0 and write data to standard output. If the script exits with 0 but STDOUT is completely empty, Intune marks the application as not detected.
The bottom line
Detection rules are the single most overlooked failure point in Intune Win32 deployments. A perfect install command means nothing if Intune cannot verify the result. Default to MSI Product Code detection whenever possible, use registry or file version checks for legacy EXEs, and reserve custom PowerShell scripts for the rare cases where nothing else will do.
Need zero-maintenance detection rules on your next deployment? Try the free tier — three full conversions per month, no credit card required.