Assuming Intune Available Apps Auto-Update? Think Again
Company Portal says Northstar Workspace 4.3 is ready to install. Northstar Workspace is a fictional app used for this example. The laptop already has 4.2. Clicking Install sounds harmless: it is only an update, right?
Not necessarily. Company Portal knows that the 4.3 application is not detected. It does not automatically know whether its install command upgrades 4.2, replaces it, installs next to it, or fails because the old installation used a different product code, path, or context.
Publishing a newer app keeps the Intune up to date, but it does not define what should happen on a device that already has an older version. That needs an explicit app relationship or installation logic that handles the old state.
The three versions of the truth
The same device can describe Northstar Workspace in three valid but different ways:
| Where | What it knows |
|---|---|
| Endpoint | Northstar Workspace 4.2 exists. It may be an old MSI, a manual install, or an earlier Intune deployment whose managed app package was later removed from Intune. |
| New 4.3 application | Its own command, requirements, and evidence for “4.3 is installed.” |
| Company Portal | 4.3 is not detected, so it will offer Install again. |
“4.3 is not detected” means only that the 4.3 application’s own detection rule has not passed. It says nothing about an earlier version or related product that may already be on the device.
Detection answers whether this application is installed. Supersedence answers what the new application must do with the old one.
Available is an offer, not an update plan
Available for enrolled devices is self-service. Without further configuration, Company Portal shows the new app and the user must choose Install.
Publishing 4.3 does not change that. The new app can be offered to the user, but it does not automatically replace or update 4.2.
Let detection tell the truth
For this example, configure the 4.3 application’s registry detection rule in the portal as follows:
| Intune detection setting | Value |
|---|---|
| Rule type | Registry |
| Key path | HKEY_LOCAL_MACHINE\SOFTWARE\Northstar\Workspace |
| Value name | DisplayVersion |
| Detection method | Version comparison |
| Operator | Greater than or equal to |
| Value | 4.3.0 |
| Associated with a 32-bit app on 64-bit clients | No |
On this device, 4.2.0 >= 4.3.0 is false. That is correct: 4.3 is missing and Company Portal will offer Install again.
Warning: Do not weaken version-aware detection just to make Company Portal look friendlier. A rule that accepts every old version hides the fact that the target version is absent.
A correct failed detection does not make the request a safe upgrade. Intune runs the 4.3 installation process exactly as it was configured. If that process was built only for a clean 4.3 installation, it can run into an existing 4.2 installation with no upgrade, replacement, or removal logic.
Supersedence makes the transition explicit
On the 4.3 Win32 app, create a supersedence relationship to 4.2. Then decide whether this is an update or a replacement:
- Update: the 4.3 installer upgrades 4.2 itself. Leave Uninstall previous version off.
- Replacement: Intune removes 4.2, then installs 4.3. Enable Uninstall previous version and test both commands in their intended context.
Available Auto-update
Configure the no-click path on the newer Win32 application, following Microsoft’s documented flow:
- In Apps > All apps, add or open the newer Win32 application, such as 4.3.
- On its Supersedence step, add the older application, such as 4.2.
- On Assignments, create or open the intended Available for enrolled devices assignment. Its target can be a group, All users, or All devices.
- In that assignment’s Auto-update column, select Auto-update, then save the assignment and application.
- Keep the original Available assignment and its scope in place. The original Company Portal user must still be signed in, and the device or user must remain in scope, whether that is through a group, All users, or All devices. Changing the assignment or intent after the original Company Portal install removes the consent state that Auto-update relies on.
This applies when the user originally installed 4.2 from Company Portal. With that state intact, Intune requires 4.3 without another Company Portal click.
When an app-management platform publishes your apps
An app-management platform adds real value when it can keep this lifecycle intact as it publishes a new release: reliable version detection, supersedence, the correct update or replacement behaviour, and the Available Auto-update assignment. That removes repetitive configuration work and makes the intended transition consistent.
Do not assume it does this just because it publishes a newer version. Verify what the platform creates in Intune. If it only publishes the next package, Intune sees a new application rather than a known successor. The platform must either support supersedence and Auto-update, or ensure the package handles legacy state before it installs.
Test the lifecycle, not just a clean install
Use an enrolled test device and publish version 2 exactly as production automation will. Do not test only a clean installation. Test these two paths:
- Known Company Portal install: install version 1 through Company Portal, then verify that supersedence with Auto-update moves it to version 2 without another user action.
- Existing unmanaged installation: start with an old manual, user-context, or unrelated installation. Verify that the version-2 package safely upgrades, replaces, removes, or stops when it encounters that state.
In both cases, confirm that version 2 is detected and that a device without version 1 does not receive an unwanted first install. If the result is unclear, inspect AppWorkload.log and AppActionProcessor.log.
The practical rule
Available supersedence with Auto-update solves the central Company Portal problem when the earlier version is a known Intune application installed from Company Portal. It gives Intune both the relationship and the instruction to install the successor.
Important: Supersedence links Intune applications. It does not make
HKLMandHKCUequivalent. A System-context installer uses the System account’sHKCU; user-context logic can miss a device-wideHKLMinstallation. If both histories are possible, the installer or wrapper must check the relevant contexts and deliberately upgrade, replace, remove, or stop.