Fix Supercedence behavior
This is definitely in the catagory of a bug or design change.
Consider this scenario:
* app A deployed to a number of machines via required deployment
* app a Version 2.0 comes out, we create a supersedence for the old app
* deploy Version 2.0 to a small collection with an 'Available' Deployment
* witness in horror as machines automatically begin applying the updated version
* check the deployment after the fact and discover that a check box of ''Automatically upgrade any superceded versions of this application' has now appeared in the deployment, and is forced checked.
No where in SCCM is this behavior explained or documented and I've seen this bite SCCM Admins at two separate customers now.
The workaround for controling this behavior is to make a deployment of Version 2.0 first, THEN create the supercedence, which will add the checkbox to the deployment but NOT check it.
Very very strange and puzzling behavior here.
Roth, Chase commented
This really is a broken feature. I have many situations where we'd like to use supersedence, but haven't been able to. Like many others we tried using this feature when first available in 2012, and deployed a new version of SMARTBoard to EVERY computer that had the old version of the software installed, even though BOTH of the deployments were AVAILABLE and NOT REQUIRED.
Please please fix it! We really need this ability. There is no other way to say "before you can install this application, that application needs to be uninstalled." I'd like to be able to say as a dependency a certain application CANNOT be installed and it would have the option to uninstall it, but I can see that that sort of functionality really is more appropriately suited as a supersedence and not really a dependency.
Kyle Ericson commented
Yeah we went to deploy Solidworks 2017 with this bug and everyone got it. Caused us a ton of down time this needs to be fixed.
Tested in SCCM 1702. This has not been fixed for deployments to device collections.
This appears fixed in 1702 for new user deployments. You can't change existing deployments so you would need to recreate them. Device deployments still have the old behavior. When creating a new user deployment for a superseded application the 'Automatically upgrade any superseded versions of this application' is now enabled and defaults to unselected.
Michel Leclerc commented
John Halverson commented
We observed this happening with an Office Suite deployment. Our entire enterprise got upgraded in a non-controlled fashion. We called Microsoft. They initially told us that unless there was a "Required" deployment, that the systems could not automatically update. Then, we were told that if we had an application with a supersedence that was also part of a Task Sequence, that would cause it. That didn't make sense either. I eventually found out how this was happening through research. There should never be a way that automatically deploys anything that is not fully controlled. Period.
Qasim Mashwani commented
Superseded Application runs in the context defined by the Deployment Type of the Current Application.
An addition to this request, when configuring supersedence consider the following:
1. Current Application contains a Deployment Type which has Installation Behavior set to "Install for user" and is targeted to a machine. It also contains a Deployment Type which has Installation Behavior set to "Install for system".
2. The Deployment Type which installs for system is Priority 1 and the Deployment Type which install for user is Priority 2.
3. Superseded Application contains a Deployment Type which has Installation Behavior set to "Install for system if resource is device, otherwise install for user".
4. Supersedence is configured so the Old Deployment Type maps to the Replacment Deployment type which is Priority 1.
5. Current Application install is attempted on the client and it fails because the Superseded Application uninstall runs in the User context. The user does not have sufficient rights to run the defined uninstall program successfully for the Superseded Application so the Current Application install cannot run.
Conclusion and Suggestions:
Logic follows that the Old Deployment Type Uninstall selection will result in the Uninstall program running in the System context.
In practice the Uninstall program actually runs in the user context even though both applications are targeted to machines, and the Replacement Deployment Type is configured to run in the System Context. The prescense of a Deployment Type which runs as user in the Current Applicaiton alters the intended behavior of the Superseded Application causing it to run in the wrong context.
Update the code so that the Superseded Application runs in the context defined in its Deployment Types not in that of the Current Application.
FWIW: I just tested this in 1610 and the issue is still present.
Mads Nyberg Hansen commented
Another possible work-around is to create a task sequence containing only the superseding application and deploy this as "Available". This will not force the superseded application to update (tested in 1606).
This has to be one of the most annoying bugs i have seen in SCCM in a long time. The saddest part being that it looks like this issue has been around for a good amount of time now and as of 1511 still has not been fixed. Get it together Microsoft.
Dustin Newby commented
I agree this needs fixed ASAP. I pushed out O365 to my users in horror this morning. I had previously tested the deployment to make sure it didn't break anything on a existing collection, only to find that despite selecting available it auto installed on quite a few users pc's before I deleted it. This a good feature to have, but I should be able to toggle it in the wizard instead making a default action that is disruptive.
Paul Deasy commented
I have had a similiar case open with premier support around this.
The interesting part to this, my fix to prevent the auto-upgrade, was to create a new package, then advertise the package to the relevant collections ** ONLY THEN** after setting this up I then set the 'superceedance' rule (in my case tell office365 to superceed Office 2013)
This was the only way to advertise the deployment as an 'optional' (available) package in Software Center.
If you then try to deploy that package (in my case Office365) to a new collection, you'll find that the deployment becomes an automatic upgrade - meaning you have to create a new package to get around the 'auto upgrade'..
Some might say it's a feature change request..but I think it's clear it's a bug in design.
We just need that box to be available for us to check and uncheck and for it to work as it is labeled. For instance, I am in a higher ed environment and we want to make Office 2016 available to our users for them to upgrade at their own convenience. If I use supersedence to control the removal of office 2013, then it will upgrade them at the next maintenance window, regardless of the work-around mentioned above.
So instead, I am forced to script the removal of office 2013 during the installation of 2016.
(Of course of the removal of previous versions actually worked in the office configuration tool, then this would be a non-issue but that is another thread.)
Supersedence needs to be fixed, please.
This really does need to be fixed. Making packages available is how we deploy to laptops (so that they can install at a time convenient to them.
I tried the workaround which worked for 90% of devices but the other 10% still automatically installed the software!
I voted that this does need to be fixed. However, I am disappointed that the workaround still behaves the same way for me and machines still automatically upgrade the superseded application regardless of that box being un-checked.
Given that the official documentation here (https://technet.microsoft.com/en-us/library/gg682071.aspx) states "When you supersede an application, this applies to all future deployments and Application Catalog requests. This will not affect the existing installations of the application." this "feature" is beyond unsettling.
It would seem that even MS's own support team needed to set up a lab with multiple scenarios to determine how this "feature" would behave (see https://blogs.technet.microsoft.com/umairkhan/2014/03/07/configmgr-2012-application-supersedence-behavior-with-task-sequence-deployments/) as this behavior was not documented in any way (?!?!!?)
This, combined with the total lack of this option being visible in the deployment wizard *AND* being unavailable to change after the deployment *AS THE BEHAVIOR IS DETERMINED BY SCCM AND NOT THE ADMINISTRATOR* runs completely counter to the philosophy of SMS/SCCM - "always a client side decision, never server side" (see client notification if you don't understand the reference/history). How this can even be documented anywhere as "by design" should be an embarrassment to all involved in this "feature".
Joshua Binney commented
Switch to user based collections for deployments and you gain this option.
Jeremiah Abbott commented
Supersedence is a great feature, but this coupled with the fact that referencing a superseded Application in a Task Sequence deployment can cause unexpected deployment of the Superseding application makes me a bit leery of recommending its usage unless someone fully understands the ramifications of what supersedence does in client policy.
Stephen Owen commented
Can't figure out how to edit my post, but I've made a longer write-up here, on my site. http://foxdeploy.com/2016/01/21/sccm-controlling-application-supersedence/
I will agree with this improvement. Especially with larger applications that have longer installs, it's often worthwhile to give users the option to do the installation when convenient.