Intune Software Deployments and Updates: Why Most Admins Skip Supersedence
Software Deployments and Updates in Intune: Why Supersedence Isn’t Enough
If you’re coming from Config Manager and moving thousands of devices to Intune, software deployment is usually where the pain starts.
One Intune admin migrating about 8,000 devices summed it up well:
- They tried user-based deployments and supersedence.
- Updates were slow. Sometimes it took up to 16 hours for a new version to deploy.
- Supersedence only worked if Intune installed the original app.
- For client/server apps that must stay in sync, that delay is a deal-breaker.
The question they asked the community:
“Did I miss a better way, or is this just how Intune works for software updates?”
The answers from other admins were very consistent.
The Reality: Supersedence Sounds Nice, But…
On paper, supersedence should solve app upgrades:
- You create a new version of the app.
- Mark it as superseding the old version.
- Intune handles uninstall/install and you move on.
In practice, admins see a few big problems:
- It only works if Intune installed the previous version.
- If the app came from ConfigMgr, a manual install, or another tool, supersedence often does nothing.
- It can be fragile.
- Detection issues.
- Mixed versions on devices.
- Devices that never process the change correctly.
- It’s slow.
- Intune check-in cycles and policy processing mean updates can take many hours.
- That’s okay for a browser update, but not for tightly coupled client/server apps that must match a backend upgrade at a specific time.
Because of this, many admins in the thread said the same thing:
“We avoid supersedence. We script it instead.”
What Most Intune Admins Actually Do
Here are the common patterns from the community (and from real-world environments).
1. Use PowerShell to Control the Whole Upgrade
The most common approach:
- Wrap the installer in PowerShell (or PSADT).
- The script:
- Detects and uninstalls old versions (all of them, if needed).
- Installs the new version.
- Writes clear exit codes for Intune.
You then package this as a Win32 app in Intune and let the script control everything.
Why admins like this:
- Same behavior no matter how the app got there (ConfigMgr, manual, GPO, etc.).
- You can support multiple previous versions in one script.
- You can build in logging, retries, pre-checks, post-checks, and custom prompts.
Many people use PowerShell App Deployment Toolkit (PSADT) for this because it already gives:
- Standard logging
- Pre/post actions (close apps, show messages, reboot, etc.)
- Consistent return codes
But plain PowerShell with your own functions is also fine.
2. Device-Based “Required” for Core Apps
For core applications that everyone needs (AV agents, VPN clients, main business apps), most admins:
- Deploy them as Required to device groups (not users).
- Use dynamic Entra ID groups where they can (e.g. by OS, department, or tag).
- Let Intune handle them like “baseline” software.
This gives:
- Predictable coverage: every device in scope should have the app.
- Less noise from follow-me user scenarios that make troubleshooting harder.
Downside: you lose the “user follows their apps to any device” experience.
But most admins decide the trade-off is worth it for stability.
3. “Available” to Users for Optional Tools
For optional or nice-to-have tools:
- Publish apps as Available to user groups.
- Let users install from the Company Portal.
Pros:
- Reduces forced installs and bloat.
- Keeps support simple.
Cons:
- Users are responsible for installing.
- Updates can still be tricky—you may need another “upgrade” app or script later.
Some admins combine this with:
- Service Desk requests → user added to group → app becomes Available.
- Automation (Power Automate, custom portals) to manage those group memberships.
4. Scripted Upgrade Waves Instead of Supersedence
For apps that must match a backend change:
- Create a new Win32 app that:
- Uninstalls all old versions.
- Installs the new version.
- Deploy it as Required to:
- A pilot group, then
- Rings (e.g. 10%, 50%, 100%) using Entra groups.
You can time these deployments close to the backend upgrade, or align them with planned maintenance windows.
The key is: your script controls timing and behavior, not supersedence.
Why User-Based Deployments Feel Messy
The OP tried user-based deployments to keep a “follow-me” experience:
- Wherever users sign in, their apps appear.
This sounds good, but it creates issues:
- Users log on to many shared devices, so apps end up everywhere.
- Troubleshooting becomes hard:
- “Does the device have the app?”
- “Does this user have it?”
- “Which version is where?”
- Updates depend on both:
- The user being targeted, and
- The device checking in correctly.
This is why many admins end up with:
- Device-based Required for anything critical.
- User-based Available for optional tools only.
A Practical Pattern for a 8,000-Device Migration
If you’re in a similar project, here’s a simple model that matches what the community is doing.
1. Classify Your Apps
Split your apps into:
- Core apps
- Security, VPN, core line-of-business client, Office, browsers.
- Tightly coupled client/server apps
- Must be upgraded in sync with backend.
- Optional apps / utilities
- Tools, viewers, small helper apps.
2. Decide Deployment Style
- Core apps → Win32 + PowerShell/PSADT, Required to devices
- Client/server apps → Win32 + PowerShell/PSADT, Required to device rings, no supersedence
- Optional apps → Win32 or Store, Available to users through Company Portal
Avoid supersedence for anything critical; treat each version as a new “upgrade app” with its own detection logic.
3. Standardize Your Script Template
Create a shared script or PSADT template that every packaged app follows:
- Check for and uninstall old versions.
- Install the new version.
- Write logs to a standard path.
- Return standard exit codes.
- Optional:
- Kill running processes.
- Prompt user or schedule a reboot.
Once this template is proven, app packaging becomes repeatable, and your team trusts the behavior.
Are You Missing a Magic Feature?
Based on the community feedback: no, you’re not.
Right now:
- Many experienced admins do not trust supersedence for real-world updates.
- Scripted uninstall + install is the common, accepted pattern.
- Complex group targeting and user-based logic is still very normal in Intune.
People do wish for:
- More reliable supersedence.
- Better grouping/foldering of apps in the Intune portal.
- Smoother user-based follow-me installs that don’t explode complexity.
Until Microsoft improves these areas, most large environments follow the same script-heavy approach you’re already considering.
Takeaways
- Supersedence in Intune looks nice on paper but is often too fragile and slow for large, mixed environments.
- PowerShell-based Win32 apps (often with PSADT) are the standard way admins manage installations and upgrades.
- Use device-based Required deployments for core and tightly coupled apps.
- Use user-based Available deployments for optional tools.
- Build a repeatable packaging pattern so your team isn’t reinventing the wheel with every app.
