Intune Win32 Supersedence Conflict: Why the New App Won’t Install

An Intune Win32 app can be correctly packaged, targeted, and available in the admin center but still never install because its supersedence relationship is blocking the next step. The most misleading cases are the ones where the old app is still present, the new app is not targeted, or Intune is waiting for the old app’s uninstall state to change.

This is a different problem from a bad installer. Before rebuilding the .intunewin file, prove which app Intune thinks is installed, which app is supposed to replace it, and whether the old app can be removed cleanly.

Quick fix checklist

1. Open the new Win32 app and record its Supersedence relationships.
2. Confirm the new app has an explicit assignment. Supersedence does not automatically target the superseding app.
3. Check whether Uninstall previous version is enabled for the relationship.
4. Compare the old app’s detection rule with the actual device state.
5. Review AppWorkload.log, AppActionProcessor.log, and IntuneManagementExtension.log on the device.
6. If the old app is still detected, fix its uninstall command or detection rule before troubleshooting the new installer.
7. Test the relationship on one device, then verify the new app is detected after the old app is removed.

For a structured first pass, use the free Intune App Failure Analyzer. It is a browser-based, client-side beta. It accepts error codes, install commands, detection rules, install context, registry view, and IME/AppWorkload logs. Paste sanitized evidence only; validate every conclusion against the affected device.

Why supersedence looks like an install failure

Supersedence tells Intune that one Win32 app updates or replaces another. Microsoft documents two important behaviors:

• The superseding app still needs its own explicit targeting.
• If the old app is configured to be uninstalled, Intune removes the old app before installing the replacement.

That creates several states that look like “the new app is ignored”:

• the new app has no assignment;
• the old app is detected, so Intune has not completed the replacement path;
• the old app’s uninstall command returned an error;
• the old app still passes its detection rule after uninstall;
• a dependency or another supersedence relationship creates a conflict.

Do not infer the cause from the Company Portal alone. Build the relationship and detection evidence first.

Step 1: inspect the supersedence graph

In the Intune admin center, open Apps > Windows > select the new Win32 app > Properties and review the supersedence relationships. Record:

• the superseding and superseded app names and IDs;
• whether the relationship is an in-place update or replacement;
• whether Uninstall previous version is enabled;
• assignments for both apps;
• dependencies connected to either app.

A common configuration mistake is assuming that creating the relationship also assigns the new app. It does not. Explicitly target the new app to the pilot group.

If the old app is targeted as Required and the new app is not targeted, the device can continue enforcing the old app without ever receiving the replacement as an actionable assignment.

Step 2: prove whether the old app is still detected

Use the old app’s exact detection rule, not a Start menu shortcut. For a file rule:

$Path = 'C:\Program Files\Contoso\Client\Contoso.exe'
Get-Item $Path -ErrorAction SilentlyContinue |
  Select-Object FullName, Length, LastWriteTime, VersionInfo

For a registry rule:

Get-ItemProperty 'HKLM:\SOFTWARE\Contoso\Client' -ErrorAction SilentlyContinue |
  Select-Object InstalledVersion

If the old package was 32-bit on 64-bit Windows, check the registry view used by the original detection rule:

Get-ItemProperty 'HKLM:\SOFTWARE\WOW6432Node\Contoso\Client' -ErrorAction SilentlyContinue

A stale detection rule can keep the old app marked Installed after its binaries are gone. The replacement then appears blocked even though the actual problem is that the old app’s state never transitioned.

Step 3: test the uninstall command outside Intune

Run the vendor’s uninstall command on a disposable test device using the same install context configured for the app. Record:

• the process exit code;
• whether a reboot is required;
• which files and registry values remain;
• whether the old detection rule still returns true.

Do not “fix” the old app by deleting its detection artifact manually on production devices. That can hide an uninstall failure and leave services, drivers, or per-user data behind. Correct the uninstall command or create a detection rule that represents the supported post-uninstall state.

Step 4: read the client logs in sequence

IME logs are commonly stored in:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Use this search to collect the relevant timeline:

$LogRoot = 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs'
$Terms = 'Contoso','supersed','uninstall','detect','dependency','conflict'

Get-ChildItem $LogRoot -Filter '*.log' |
  Select-String -Pattern $Terms -SimpleMatch |
  Select-Object Path, LineNumber, Line

Review the files in this order:

Log	What it can establish
IntuneManagementExtension.log	policy receipt, processing, and reporting
AppWorkload.log	app check-in, install, applicability, detection, and workload state
AppActionProcessor.log	detection and applicability evaluation
AgentExecutor.log	PowerShell install or detection-script execution

The useful chain is:

new app targeted -> old app detected -> uninstall requested -> uninstall result -> old detection rechecked -> new app install

If the chain stops before the uninstall command, check assignment, policy receipt, or applicability. If uninstall completes but the old app is detected again, fix the old detection rule or cleanup. If the old app clears but the new app fails afterward, switch to the new app’s installer and detection evidence.

Verified fixes by state

The new app is not targeted

Assign the new app explicitly to a pilot group containing the test device. Keep the old relationship intact until the pilot proves the replacement path. Supersedence alone does not create the required assignment.

The old app cannot uninstall

Fix the uninstall command, silent switches, permissions, or reboot handling. Test the command independently and confirm the old app’s detection rule becomes false afterward.

Uninstall succeeds but the old app remains detected

Correct the old detection rule so it matches the supported installed state. Remove stale version comparisons, wrong registry views, and paths that survive an uninstall but do not represent a usable installation.

The graph has a dependency conflict

Inspect dependencies and other supersedence relationships on both apps. Simplify the pilot graph, target every required app explicitly, and test one replacement path at a time.

The new app is installed but reports failed

Stop troubleshooting supersedence and compare the new app’s install context, detection artifact, and logs. The related Intune Win32 app installed but says Failed guide covers that branch. For detection-specific status, see error 0x87D1041C.

Prevention checklist

• Give every superseding app an explicit pilot assignment.
• Document whether the relationship is an update or a replacement.
• Test the old app’s uninstall command and post-uninstall detection state.
• Record System versus User context for both install and uninstall commands.
• Keep dependencies and supersedence relationships simple enough to trace.
• Capture AppWorkload.log and AppActionProcessor.log during a pilot replacement.
• Do not expand the assignment until the old app clears and the new app passes detection.
• Recheck detection rules after changing package content or vendor versions.

Bottom line

When a newer Intune Win32 app will not install, a supersedence relationship can be the control point rather than the installer. Verify explicit targeting, prove the old app’s detection state, test its uninstall command, and follow the client logs through the transition. Only after the old app clears should you diagnose the new package.

The Intune App Failure Analyzer can organize the error code, command, detection rule, context, registry view, and log evidence in the browser. It is a triage aid, not a substitute for confirming the state on the device.

Microsoft sources

• Add and assign Win32 apps to Microsoft Intune
• Add Win32 app supersedence
• Troubleshoot Win32 apps in Microsoft Intune
• Understand Microsoft Intune Management Extension