PATTERN · INTUNE

Build Win32 app detection rules you can support

How to choose stable evidence, distinguish versions, handle architecture, and test Intune detection without creating reinstall loops.

8 min readBy ArunPublished 28 Jul 2026Updated 1 Aug 2026

Detection is the contract that tells Intune whether the desired application state exists. It should be narrow enough to prove the requirement and stable enough to survive normal user activity.

Detect the outcome, not the installer

Prefer evidence that represents the usable application state: an authoritative MSI product code, a versioned registry value, or a stable file with a meaningful version. Avoid temporary files, shortcuts, and paths users can alter.

If an application can be installed per user and per device, decide which state the deployment owns and make the execution context match the detection context.

Make version logic explicit

Define whether equal, greater-than, or exact version is compliant. Test upgrade, downgrade, repair, and supersedence paths instead of validating only a clean installation.

Normalize version values before comparison. Text comparison can produce incorrect results when numeric components have different widths.

Keep script detection deterministic

Return success only when the required state is proven. Write a short useful value to standard output and use the documented exit behavior. Do not change device state in a detection script.

Handle missing registry views, 32-bit and 64-bit paths, access errors, and malformed values as explicit evaluation outcomes.

$path = 'HKLM:\SOFTWARE\Contoso\Example'
$value = Get-ItemPropertyValue -Path $path -Name Version -ErrorAction SilentlyContinue
if ([version]$value -ge [version]'2.4.0') {
  Write-Output "Detected $value"
  exit 0
}
exit 1

Test the full lifecycle

Test clean install, already installed, failed install, upgrade, uninstall, user-context variation, and a device reboot. Review both Intune reporting and local Intune Management Extension logs.

Retain the detection rationale beside the package source so the next maintainer knows what evidence is authoritative.

OPERATIONAL CHECKLIST

Take this into the work.

  • Define authoritative installed state
  • Match execution and detection context
  • Specify version comparison behavior
  • Handle 32-bit and 64-bit locations
  • Keep detection read-only
  • Test install, upgrade, repair, and removal
  • Document the rationale
Download the free endpoint operations checklist ↓

PRIMARY REFERENCES

Check the platform documentation.

Product behavior and requirements change. Validate this guidance against the current vendor documentation and your own environment.

NEED HELP APPLYING THIS?

Turn the guidance into a scoped outcome.

Request a consultation