Choosing Detection Rules for Win32 Apps in Intune

If you’ve ever deployed an app through Microsoft Intune, MECM, or another system, you probably had to configure detection rules. Detection rules are conditions used during app deployment to determine whether an app is already installed on a device. In Intune, the client evaluates detection rules before and after installation and then at regular intervals. If the rule doesn’t detect the app, Intune installs it on the device. 

This post explains the four detection rule types for Win32 apps in Intune. The screenshots come from Intune, but the same rules apply to MECM with only minor differences. The detection rule types in Intune are: 

• MSI 
• File 
• Registry 
• PowerShell script  

MSI Product Code Detection 

Each MSI package has a product code – a globally unique identifier for the product release. The product code is used by the Windows Installer service to determine whether the MSI-based product is already installed, and to perform actions such as repair or uninstallation. It also serves as the reference point for configuring MSI-based detection rules in Intune. 

When you deploy an MSI as a Win32 app, the product code is the simplest detection rule. When you select the MSI in the Microsoft Win32 Content Prep Tool, it captures the product code and writes it to the <MsiProductCode> tag inside the .intunewin file. Intune then auto-populates that code when you create an MSI detection rule. 

You can also find the product code by using an MSI packaging tool like Master Packager, or from the uninstall registry key if the product is already installed. You can sometimes use an MSI detection rule even when you deploy an EXE installer. Many EXE installers are just wrappers around an MSI. You can uncover the MSI by extracting the EXE with a ZIP tool, installing the app and inspecting the uninstall registry key, or reviewing event logs to see where the MSI was unpacked. 

With MSI product version check, you can configure if Intune should also check for a specific version and what kind of operator it should use. Version check is handy when the product code stays the same across versions or during auto-updates. For instance, every Adobe Acrobat build with the same architecture and language shares one product code because the original MSI is patched with an MSP. When you deploy the update, you can reuse the product code and simply adjust the version value. 

Use MSI detection rules when: 

• You deploy an MSI package 

File Based Detection 

File-based rules can detect file or folder existence and properties such as version, size, and modified date. Install the app first so you can capture the exact path and properties needed for the rule. Use the String (version) method; it lets you target a specific version and apply the “Greater than or equal to” operator for devices that already run a newer build. 

When specifying a file version detection rule, try to find a file where the version number matches the application version. That approach prevents older versions from passing detection and guarantees the targeted release installs. Typically, the main executable—the one launched by the shortcut—works best. 

If version doesn’t matter because the app auto-updates, use simple file or folder existence detection. This is the simplest form of file detection, as you only need to specify the path and file/folder name. 

The file or folder path can be a direct path (e.g., C:\Program Files) or a variable like %ProgramFiles%. Selecting “Associated with a 32-bit app on 64-bit clients” lets Intune look in the 32-bit program folder. In that case, Intune checks C:\Program Files (x86) on 64-bit systems. Use this setting only when you manage both 32- and 64-bit OSs; in an all-64-bit fleet, ignore it. 

Use file detection rules if: 

• You deploy an EXE setup 
• You deploy an MSI, and you rely on in-app updates, and the product code changes after each update 

Registry Based Detection 

Registry rules let you check for a key or value and compare strings, versions, or integers. You can target any key the SYSTEM account can read, but the most common is the Uninstall registry key. That key lists every MSI and EXE install, even those hidden from Programs and Features. 

The Uninstall key lives in two locations: the first covers all installs on 32-bit OSs and 64-bit apps on 64-bit OSs; the second covers 32-bit apps on 64-bit OSs: 

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall 
• HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall 

As with file rules, use Version comparison and target the DisplayVersion value. Version comparison works on REG_SZ values and supports multiple operators. If the app lacks a DisplayVersion string, switch to Integer comparison. Integer comparison reads DWORD values and offers the same operators.  

Use registry detection rules when: 

• The app doesn’t place identifiable files or 
• The installed files don’t have a version number or 
• The file path is version specific, while the key path is the same for all versions and you use in-app updates 

Custom PowerShell Detection Scripts 

PowerShell detection scripts are the most flexible option in Intune. A script can inspect files, registry values, or any other system trait PowerShell exposes. For example, you might check for a specific printer (Get-Printer), read a file’s content (Get-Content), or confirm a VPN profile (Get-VpnConnection). Your script must pass the detection result back to Intune. Intune marks the app as installed when the script writes to STDOUT (Write-Host or Write-Output) and exits with code 0. Include an IF block that outputs a value only when detection succeeds. Here’s a simple example: 

$Printer = Get-Printer | Where-Object {($_.PortName -eq "192.168.3.24_1") -and ($_.Name -eq "Lab Printer 3")} 
if ($Printer){ 
    Write-Output 1 
    Exit 0 
}  

This script checks whether the device has a printer named “Lab Printer 3” on port 192.168.3.24_1. If $Printer is empty, Intune assumes the app is missing and installs it. When a match exists, the script runs Write-Output 1 and Exit 0, and Intune treats the app as installed.  

To use a script, choose Use a custom detection script in the rule format menu. Because you can’t edit scripts in Intune, test the .ps1 locally before uploading. 

Use custom detection scripts when: 

• You have an application that does not install any files or make any registry changes 
• You need to detect multiple file paths or registry keys with an OR operator 
• You need to detect the app based on file contents 
• You have other custom requirements 

When to Use Each Detection Rule Type 

Which detection rule should you choose? The honest answer: it depends. File-version detection is usually best, but the other types also have their place. In practice, use the MSI product code for most MSI installs, file-version rules for other apps, and registry rules when no reliable file is available. 

Conclusion: Choosing Detection Rules for Win32 Apps in Intune 

Whatever rule you choose, make it version-aware so it detects the deployed release or newer. That ensures your deployment also upgrades older installs. If the rule matches every version (e.g., simple file existence), Intune won’t update older builds because it already thinks they’re compliant. 

Application Manager customers may have noticed we recently switched to file-based rules based on your feedback. Application Manager automates downloading installers, creating apps in MECM and Intune, defining detection rules, and managing updates—saving time and preventing manual errors.