A Win32 app in Intune is two promises: a command that installs it, and a rule that proves it did. The Intune Management Extension runs the command, waits for it to return, then evaluates the detection rule. If the rule says the app is not there, the install is reported as failed, even when the installer returned 0 and the app is sitting in Program Files. Most "the install failed but the app is installed" tickets are a detection rule, not an installer.
Detection also runs on its own schedule afterwards. For a required assignment the extension re-evaluates roughly every 24 hours and on every check-in, and a rule that stops matching (an app that updated itself, say) makes Intune install the package again. A rule that is too loose hides failures; a rule that is too tight causes reinstall loops. The art is in between.
The four rule types
| Rule | What it checks | Best for |
|---|---|---|
| MSI product code | The Windows Installer database for a product code, optionally with a version comparison. | Plain MSI installers. Intune prefills it from the .intunewin when the setup file is an MSI. |
| File or folder | Existence, modified date, size or file version of a path. Supports %ProgramFiles%-style variables and a 32-bit-on-64-bit toggle. | Portable apps, zip-wrapped apps, and vendors whose uninstall entry is unreliable. |
| Registry | A key or value exists, or a value compares as string, integer or version. | EXE installers (Inno Setup, NSIS, Burn), through their uninstall entry's DisplayVersion. |
| Custom script | A PowerShell script run as SYSTEM. Detected when it exits 0 and writes something to STDOUT. | Anything the other three cannot express: two conditions at once, per-user installs, feature flags. |
You can stack several rules; Intune requires all of them to match. That is useful for "this file exists AND this registry version is at least X", and dangerous when one of the two is written against a path that moves between versions.
Which rule for which installer
MSI (including WiX-built MSIs)
Use the product code. Add a version check (greater than or equal to the version you are deploying) so that an older install is treated as missing and gets upgraded. One trap: a vendor's major upgrade changes the product code with every release, so a rule pinned to one code will stop matching after the next update. For those products a registry rule on DisplayVersion under the uninstall key is more durable than the product code.
Inno Setup
Inno writes an uninstall entry whose key name is the setup's AppId with_is1 appended:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{AppId}_is1
DisplayVersion REG_SZ 8.8.6A registry rule on DisplayVersion, compared as a version, greater than or equal to the deployed version, is the standard. 32-bit installers on 64-bit Windows write under WOW6432Node; the rule's "associated with a 32-bit app" toggle tells Intune to look there.
NSIS and other EXE installers
Same idea, different key name: NSIS and most hand-rolled EXE installers register underUninstall\<ProductName>. Read the exact key from a test machine; guessing the name is the usual way these rules end up matching nothing. When the uninstall entry carries no version, fall back to the file version of the main executable.
WiX Burn bundles
A bundle registers under the uninstall key with its BundleId and stores the version in BundleVersion (also mirrored as DisplayVersion). Detect the bundle, not the MSIs inside it: the MSIs can change between bundle releases.
MSIX and APPX
Published as Intune's native Windows app type (line-of-business MSIX), the package is detected by Intune itself through its package identity and version; you write no rule. When an MSIX has to go out as a Win32 wrapper instead, detect it with a script aroundGet-AppxPackage or Get-AppxProvisionedPackage, because the package leaves nothing under the classic uninstall key.
Zip and portable apps
There is no installer, so there is no uninstall entry. The wrapper that extracts the app decides where it lives; detect the main executable there, by file version where the vendor stamps one, by existence where they do not.
macOS
Intune's macOS PKG and DMG app types detect by bundle identifier and version from the app bundle's Info.plist (CFBundleIdentifier and CFBundleShortVersionString). Intune reads the included apps from the package when you upload it, so the rule writes itself, provided the identifier and version in the package match what the installed app reports. Self-updating Mac apps are the classic mismatch: the app updates to 4.49, Intune still expects 4.48 exactly, and reinstalls. The "ignore app version" option exists for exactly those.
Version comparisons that bite
- Equals versus greater-or-equal.
equalsmakes every vendor self-update look like a missing install. Usegreater than or equal tounless you must pin a version. - File version is not product version. A file's version resource can lag or lead the marketed version (Chrome's match; many others do not). Check the actual file on a test machine before writing the number down.
- Strings are not versions. Intune's version comparison wants dotted numbers. A
DisplayVersionof2024.1 (build 7)or8.8.6-rc1will not compare; use a string rule or a script. - Per-user installs. Rules run as SYSTEM and see HKLM and the machine's file system. An app installed into a user profile needs a script that enumerates user profiles, or an installer run in the user context with a rule that looks under HKCU.
Testing a rule before it ships
- Install the app on a clean machine the way Intune will (as SYSTEM, non-interactive), then read the uninstall key and file versions it actually wrote. Do not trust the vendor's documentation for key names.
- Deploy to a pilot group first and watch
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log; the detection evaluation and its result are logged per app. - Confirm the rule still matches after the app's next version, or you will find out on update day.