Intune Deployment Guide
Intune detection rules explained
Overview
Detection rules allow Intune to determine whether a Win32 app is already installed on a device. A good rule prevents unnecessary reinstalls and helps deployment status stay accurate.
This guide explains how MSI, File, Registry, and PowerShell script detection work, when to use each method, and how to avoid common detection mistakes.
What are detection rules?
Detection rules define the condition Intune uses to decide whether an app is present on a Windows device.
When a device receives a Win32 app assignment, Intune checks requirements first, then evaluates detection. If the app is not detected, the install command runs. After installation, detection is evaluated again to confirm the result.
- If detection returns true, the app is treated as installed
- If detection returns false, Intune continues with installation
- If the rule is wrong, a successful installation can still appear as failed
For the full deployment flow, see Intune app lifecycle.
How Intune evaluates detection rules
For Win32 apps, detection is handled on the device by the Intune Management Extension. The extension checks the rule before and after installation, and later uses it to keep deployment status accurate.
Learn more about the agent in Intune Management Extension explained.
Detection rule types in Intune
When manually configuring detection rules, Intune supports MSI, File, Registry, and custom PowerShell script detection. Choose the simplest reliable method for the way the app installs.
Choose how Intune should detect the presence of the app.
MSI detection
MSI detection uses the MSI product code to determine whether the app is installed. It is usually the best option for MSI-based installers because the product code is designed to identify the installed application.
Create a rule that indicates the presence of the app.
File detection
File detection checks for a file or folder path. It works well for EXE-based installers when the app creates a predictable file in a system-level location.
Create a rule that indicates the presence of the app.
Registry detection
Registry detection checks whether a registry key or value exists. This is useful for custom apps, legacy installers, or apps that do not create a stable executable path.
Create a rule that indicates the presence of the app.
PowerShell script detection
PowerShell script detection is useful when MSI, File, or Registry checks are not flexible enough. Keep the script simple and deterministic. It should return a clear installed or not installed result.
Upload a custom script to detect the presence of the app.
if (Test-Path "C:\Program Files\7-Zip\7z.exe") { exit 0 } else { exit 1 }How to choose the right detection method
Start with the most reliable signal that the app is installed. For most apps, that means MSI detection when available, then File detection, then Registry detection, and finally PowerShell script detection for advanced cases.
| Scenario | Recommended detection method | Why |
|---|---|---|
| MSI installer | MSI | Uses the product code created by the installer. |
| EXE installer with stable path | File | Simple and easy to validate after install. |
| Custom or legacy app | Registry | Useful when a reliable registry value exists. |
| Complex validation | PowerShell script | Allows custom logic when built-in rules are not enough. |
Version-aware detection
Detection should be specific enough to identify the correct app version, but not so strict that minor vendor changes break deployment. Use version checks only when the deployment requires a specific version to be present.
- Use File version when the executable version is reliable
- Use Registry value when the app writes a stable version key
- Avoid temporary paths, user profile paths, or installer cache locations
If the installer itself is inconsistent, review best practices for packaging Win32 apps.
Common detection mistakes
Most detection problems come from checking the wrong location, using the wrong context, or choosing a rule that is too broad or too strict.
Quick checklist
- Confirm the file path or registry key exists after installation
- Use system-level paths for device-wide installs
- Check 32-bit vs 64-bit paths when needed
- Avoid user-specific locations unless the app installs per user
- Test detection on a pilot device before broad deployment
Troubleshooting detection issues
If detection fails, Intune may reinstall the app, show a failed status, or report the app as not installed even though the installer completed successfully.
| Issue | What to check |
|---|---|
| Install succeeds but status shows failed | Verify the detection rule matches the final installed state. |
| App reinstalls repeatedly | Check whether the rule returns false after install. |
| File rule fails | Confirm the path, file name, and install architecture. |
| Registry rule fails | Check the hive, key path, value name, and 32-bit registry view. |
| Script rule fails | Confirm the script exits consistently and runs under the expected context. |
For deeper troubleshooting, check Intune Management Extension logs.
Best practices
- Prefer MSI detection when the app is MSI-based
- Use File detection for predictable EXE installations
- Use Registry detection when the app writes a reliable key or value
- Use PowerShell script detection only when built-in rules are not enough
- Keep detection rules stable, simple, and easy to validate

Leave a feedback
Include versions, steps, and any error text if you have them.