Intune can relate one Win32 app to another in two ways: supersedence updates or replaces an older app, and dependencies install a prerequisite first. Both are easy to configure and easy to get subtly wrong, usually through detection rules or targeting. In this post I'll explain how each behaves, build an upgrade chain and show how to prove on a device what Intune actually did.
Errors this guide fixes
0x87D1041CIntune admin center (Device install status)+3 more guides
How it works#
| Supersedence | Dependency | |
|---|---|---|
| Purpose | Update an app to a newer version, or replace it with a different app | Install a prerequisite, such as a runtime, before the main app |
| Targeting | The new (superseding) app must be assigned; unassigned superseding apps are ignored | Not needed; with Automatically install on, Intune installs the dependency even if it isn't assigned |
| Old app | Uninstalled first if Uninstall previous version is Yes; otherwise left to the new installer | Not applicable |
| Limits | About ten related apps per supersedence graph (Microsoft Learn quotes 10 and 11 nodes in different sections) | Up to 100, counting nested dependencies |
Both work only between Win32 apps and rely completely on detection rules: if the old version is still "detected" after an upgrade, or a dependency isn't, nothing behaves as expected.
Prerequisites#
- Each version packaged as .intunewin and added as its own Win32 app (see Packaging a Win32 app for Intune).
- The Relate permission in the Mobile apps category. Application Manager includes it; custom roles need it added.
- Version-specific detection rules on every version: an MSI product code, or a file or registry version check, rather than "folder exists".
- A pilot group and a test device with the old version.
Step-by-step#
1. Decide: update or replace?#
If the new installer upgrades the old version in place, as most MSI major upgrades do, it's an update: set Uninstall previous version to No. If you're switching products, or the vendor says to uninstall first, it's a replacement: set it to Yes, and Intune runs the old app's uninstall command before installing the new one. One app can update some apps and replace others.
2. Fix detection before you link anything#
With replacement, Intune installs the new app only after the old one is no longer detected. If the old rule is "folder exists" and the uninstaller leaves the folder behind, the new version never installs. Make the old app's rule match only its own version (no "greater than" checks) and test it on the pilot device:
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' |
Where-Object DisplayName -like '7-Zip*' |
Select-Object DisplayName, DisplayVersion, PSChildNameFor MSI-based apps, PSChildName is the product code, which normally changes with a major upgrade and makes a clean detection rule.
3. Add the supersedence relationship#
- In the Microsoft Intune admin center, go to Apps › All apps and open the new app.
- Select Properties, then next to Supersedence select Edit › Add.
- Select the old version or versions and set Uninstall previous version for each.
- Select Review + save.
For the next release, let version 3 supersede version 2. In a chain, every app is superseded by the newest one, so a device still on version 1 goes straight to version 3. Before the graph hits the limit, remove the oldest links once no device reports those versions.
4. Assign the new app explicitly#
Superseding apps don't inherit assignments, so assign the new app to the same groups with the same intent. Where the new app is targeted and the old one is present, supersedence runs whether or not the old app is still assigned. With Available intent, Company Portal shows only the newest app. Start with the pilot group; Intune deployments (preview) can stage this across rings.
5. Optional: auto-update self-service installs#
Users who installed the old version from Company Portal don't get the new one automatically. To change that, in the new app's assignments under Available for enrolled devices, set Auto-update for the group. Keep in mind:
- It covers only users who installed the old app through Company Portal, not devices that got it as Required.
- It needs two available-app check-ins, typically 8 to 16 hours, and the user must be signed in.
- Removing the user from the group, removing the assignment or changing its intent after installation clears the user's consent, and auto-update won't resume.
6. Add dependencies#
Open the main app's Properties, edit Dependencies, add the prerequisites and leave Automatically install on Yes unless the prerequisite is deployed another way. With No, the main app isn't attempted until the dependency is detected, and reporting flags the dependency as failed. Dependencies at the same level have no guaranteed order; if order matters, chain them (add-in depends on runtime, runtime on redistributable).
7. Don't mix them carelessly#
The two can share a graph, and Intune prefers supersedence when they clash. Avoid these patterns:
- A depends on B, and C supersedes B: A reports a conflict.
- A depends on B, and C replaces A: C installs and A goes, but B stays behind.
- A depends on B and C, and B supersedes C: the supersedence doesn't happen.
When a prerequisite gets a new version, point the main app's dependency at it instead of superseding the prerequisite underneath.
Verify#
On the pilot device, restart the Intune Management Extension service to trigger a check-in; otherwise it looks for new Win32 assignments about every hour. Then follow the app through the logs:
Restart-Service IntuneManagementExtension
$appId = '<app GUID from the browser address bar>'
Select-String -Path 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload*.log' -Pattern $appId |
Select-Object -Last 40 | ForEach-Object LineFor a replacement you should see the old app's uninstall, a detection check that no longer finds it, then the new app's install and successful detection. For dependencies, the prerequisite installs first. Per-app state is kept under HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps, one subkey per user SID (all zeros for device context). Good looks like the new app reporting Installed and the old app no longer detected. More on these logs in Reading Intune Management Extension logs.
Tips & gotchas#
- Test uninstall commands. With replacement, the old app's uninstall command runs on every device that has it, so make sure it's silent.
- Azure Virtual Desktop multi-session supports supersedence only for system-context apps.
- Only targeted apps report status. An auto-installed dependency won't show in install reports, so check the device.
- Enterprise App Catalog can create the superseding app for you, but scope tags and assignments aren't copied; see Enterprise App Catalog in Intune.
- Not detected after install? That's
0x87D1041C; see Win32 app error 0x87D1041C.

