Intune detection rules explained

What is a detection rule, and why does it matter?

A detection rule defines the condition that, when true, tells Intune the app is present. It is evaluated independently of the installer’s exit code. That separation is deliberate: an installer can return 0 (success) and still leave the device in a state your rule does not recognize. When that happens, Intune trusts detection over the exit code and marks the app as failed or not installed.

• If detection returns true, the app is treated as installed and Intune does not run the install command again.
• If detection returns false, Intune runs the install command (subject to requirement rules and the assignment intent).
• If detection is wrong, a successful install can show as failed, or Intune can reinstall the app on every cycle because it never sees it as present.

Detection is the gate that keeps deployment idempotent. It is part of the larger sequence Intune follows for every package, covered in the Intune app lifecycle.

Where and when does detection run?

For Win32 apps, detection is evaluated on the device by the Intune Management Extension (IME), the “Microsoft Intune Management Extension” service that is installed automatically the first time a device is targeted with a Win32 app or a PowerShell script. The admin center does not perform detection; it only displays the result the IME reports back.

The IME checks for new Win32 app and script policy roughly every hour, and also after a device restart or when the service restarts. This is separate from the general Windows MDM device check-in, which runs on a variable schedule (commonly around every 8 hours). When you are testing a detection rule, do not wait for the next cycle: force a check-in with Settings > Accounts > Access work or school > Info > Sync, or from the Company Portal.

Requirement rules (OS architecture, minimum OS, optional disk, memory, and custom checks) are evaluated before detection and before the install command. If requirements are not met, detection never runs at all.

What are the detection rule types in Intune?

Under Rules format you choose either Manually configure detection rules or Use a custom detection script. Manual rules come in three types (MSI, File, Registry) and you can add several. When you add more than one manual rule, Intune requires all of them to be true (AND logic) before the app is considered installed.

MSI detection

MSI detection matches on the MSI product code and, optionally, the product version. It is the best choice for any MSI-based installer because the product code is the identifier Windows itself uses to track the installed product. The product code is read straight from the .msi, so there is nothing for you to look up on disk afterward.

File detection

File detection checks for a file or folder, with options to test existence, modified or created date, version, or size. It is a strong choice for EXE-based installers that drop a predictable executable in a device-wide location such as C:\Program Files. Point it at a stable file the app always installs, not at a temporary or cache path.

Registry detection

Registry detection checks whether a key or value exists, or compares a value with an operator (equals, greater than, version comparison, and so on). Use it for custom or legacy apps that write a reliable uninstall key or version value but do not leave an obvious executable to match.

Custom PowerShell script detection

A detection script is for logic the built-in rules cannot express. Its success contract is strict and frequently misunderstood: the app is reported as detected only when the script exits with code 0 and writes something to STDOUT. Exit 0 with no output means not detected, and a non-zero exit means not detected regardless of output. A script that only calls exit 0 after finding the app will silently report “not installed.”

if (Test-Path "C:\Program Files\Contoso\app.exe") {
    Write-Output "Installed"
    exit 0
}
exit 1

How do I choose the right detection method?

Pick the simplest signal that uniquely and reliably proves the app is present after a real install. In practice that means MSI first when the installer is an MSI, then File, then Registry, and a script only when none of those fit.

Why do detection rules fail on 64-bit devices?

One of the most common false “not installed” results comes from 32-bit redirection on 64-bit Windows. A 32-bit app installs under C:\Program Files (x86) and writes its registry keys under HKLM\SOFTWARE\WOW6432Node rather than C:\Program Files and HKLM\SOFTWARE. The IME runs detection as a 64-bit process by default, so it looks in the 64-bit locations and misses the app.

• For File and Registry rules, enable Associated with a 32-bit app on 64-bit clients so Intune resolves the redirected path or WOW6432Node view.
• For a script rule, enable Run script as 32-bit process on 64-bit clients when the script reads 32-bit paths or keys.
• When in doubt, browse the live device with a 32-bit tool to confirm exactly where the app lands, then point the rule there.

How does detection relate to install context and return codes?

Detection always runs in the context the IME uses for evaluation, while the install command runs in the install behavior you set (System or User). If an app installs under System into a device-wide location, your rule must check a device-wide location too, not a per-user path. Per-user apps that install under a user’s profile need detection that matches that profile.

Return codes and detection work together, and confusing the two causes the classic “it installed but shows failed” report. Intune treats 0 and 1707 as success, 3010 as a soft reboot (success, reboot pending), 1641 as a hard reboot, and 1618 as retry. But even a success code only marks the app installed if detection then passes. If the installer returns 3010 and the app’s files are not in place until after the reboot, detection can briefly report not installed until the device restarts and re-evaluates.

How do I troubleshoot a detection rule?

When detection misbehaves, compare what the rule checks against the final installed state on a real device, then read the IME logs in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs to see exactly what the agent evaluated.

For the full diagnostic workflow, follow the steps to troubleshoot Win32 app deployment failures, and learn how to read the agent output in the Intune Management Extension logs guide.

Detection rule best practices

• Use MSI detection whenever the installer is an MSI; the product code is the most reliable identifier.
• Derive File and Registry rules from a real install, never from guesswork about where an app “should” land.
• Be specific enough to identify the right build, but avoid over-strict version checks that break on minor vendor updates.
• Keep script detection deterministic and remember the exit 0 plus STDOUT contract.
• Account for 32-bit redirection up front so rules survive on mixed-architecture fleets.
• Stabilize the package itself first; consistent installers make detection trivial, as covered in the best practices for packaging Win32 apps.