Skip to content

Field note

Fix Intune Win32 Detection Before Repackaging

Keep the installation result and the detection result separate.

Published17 Oct 2026

Updatedyesterday

Read time4 min. 788 words.

A user can open an application while Intune reports its installation as failed. Rebuilding the package immediately may waste time because the installer and the detection rule answer different questions.

The installer reports what happened when it ran. Detection checks whether the device now matches the condition you configured. Start by identifying which stage failed.

Put the deployment stages in order

Microsoft’s Win32 app configuration guidance separates requirements, installation commands and detection. Keep the same separation in the support record.

AssignmentIs this user or device intended to receive this app?
RequirementsIs the device eligible for this package?
InstallationDid the intended command run successfully in the configured context?
DetectionDoes the resulting state match the rule?
Application useCan the intended user perform the required task?

Collect the application ID, package version, affected device and relevant timestamps. Avoid comparing a current portal result with a log from a different deployment attempt.

Check whether the failure affects a clean installation, an upgrade, or both. Those starting states can expose different mistakes.

Make detection describe a useful state

A file-exists rule may detect an obsolete version. A rule requiring one exact version may reject a newer version installed through another supported update route. Decide which state the deployment is intended to accept before editing the rule.

For an MSI rule, verify the actual product code and any configured version condition. For file or registry detection, inspect the exact path and the 32-bit or 64-bit view. Test in the configured execution context; an administrator’s interactive session can see a different user profile or registry location.

Microsoft documents that all configured manual detection conditions must be met. One obsolete secondary rule can therefore make an otherwise correct installation appear absent.

Keep the rule narrow enough to demonstrate the intended product state without tying it to incidental files that an application may clean up.

Check script output as well as its exit code

For a custom detection script, Microsoft requires a zero exit code and data on standard output to report the app as installed. Data written to standard error makes detection fail even if the other conditions are met.

Do not let a script print a reassuring message unconditionally. Its output should follow the actual detection decision.

Test the rule against a small set of known states:

App absentNot installed
Previous version onlyResult defined by the upgrade policy
Required version presentInstalled
Newer supported version presentResult explicitly decided
Partial or broken installationInvestigate whether the rule can identify the required state

This is a proposed test matrix, not a claim that any particular package has passed it. Keep the observed values with the package change.

Review supersedence independently

Supersedence describes how a new Win32 app updates or replaces another. It does not automatically target the new app; assignment still needs to be configured.

Check whether the new installer performs an in-place upgrade or whether Intune should first run the old uninstall command. The “Uninstall previous version” choice should follow the vendor’s supported behaviour.

Test removal and detection of the old app as well as installation of the new one. A replacement can stall when the old detection rule continues to claim that an uninstalled app remains present.

Keep the earlier package and a documented recovery decision available while testing. Reversing an upgrade is not always equivalent to installing the older package again, particularly when application data has changed.

Read the logs before changing another setting

Microsoft’s troubleshooting guide identifies separate management-extension logs for application processing and workload activity. Use them to connect applicability, command execution and detection within the same attempt.

Where supported, collect installation diagnostics from Intune and include the relevant installer log. Restrict the collected material to what the investigation needs.

Change one responsible component, repeat the failed starting state, and then test the other states in the matrix. Release the package when both deployment reporting and the user’s business task have the expected result.

References

Related notes

Need help mapping this to your own tenant, controls, or assessment timeline?