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.
Andrew Morgan commented
Oh thank you, thank you for putting this on the docket!
Roth, Chase commented
@Anonymous... how can not having applications in the task sequence be "ideal". That is a silly comment. So when I am done my task sequence, now wait a several hours until the device makes its way into the proper collections and all the software is detected and deployed instead of being done in 60 minutes with all necessary software installed. Yeah, good plan.
@Anthony Fontanez... Yeah, could be. I assume you're deploying to User Collections and not Devices Collections? Reading the comments, User Deployments seem to function properly with supersedence. Device deployments do not. I should have the ability to put an application out there, like Office 2016, which supersedes the previous Office 2013 version, as AVAILABLE. This allows the users to install, but does not force them to. Currently, SCCM will start installing the application for any user that has Office 2013 installed IMMEDIATELY, even if the Office 2016 is only set as AVAILABLE for their device. This is obviously a bug and not an intended action. There are even check boxes to change that behavior so it functions right, but they're unavailable and grayed out. Secondly, the only way to tell one application that it must uninstall the previous version is through supersedence, so repeat my previous point. Just because I want/need to uninstall previous version before installing new one, doesn't mean it is not optional. Office may not be a good example for that, but you can imagine a separate scenario where a newer software is available and users may choose to use it or stay with older version. However, that newer software requires the older software be uninstalled and the functionality is not built directly into the newer installer (poor packaging but that happens often). Need this supersedence behavior to function like any normal functioning admin would expect it to and when set to available, BE AVAILABLE and not REQUIRED.
@Microsoft... So pleased this is in the works. It is long since overdue, but hey I'll take that it is on its way at this point.
I've never encountered this since 2012 R2. I have seen applications in available task sequences be replaced when a supercede is in place. Ideally not having applications in your task sequence will remedy this.
Adam Juelich commented
Well, you have to test the Supersedence functionality. Most people do that by deploying as 'Available' to a Collection and manually invoking through Software Center.
I've been burned by this in the past but I have to say, since CB, I haven't really encountered it as much.
There are still improvements to be made, though.
Anthony Fontanez commented
I can’t be the only person who doesn’t have an issue with this. Why are you superseding an app unless it’s ready for prod? Deploy a new version without superseding the old version to test it, then supersede it’ll and when you create the new deployments, you get a checkbox to auto upgrade past versions, plus the ability to set a deadline to upgrade. What am I missing?
John Halverson commented
We worked around the issue by not using it after getting burned with a full Office 365 Suite deployment. People almost got fired. Now, we have created our own via our power shell installer scripts.
And the peasants rejoice. This has better be 1710 we're talking about there.
Chris Taverner commented
Great to see this is being planned! :)
Richard knight commented
Awesome guys! this is a real pain in the neck, nice work!
Matthew Thompson commented
Another workaround, use powershell after the fact.
New-CMApplicationDeployment -CollectionName $TargetCollection -Name $ApplicationName -AvailableDateTime ([DateTime]::Now) -DeployAction Install -UpdateSupersedence $false -DeployPurpose Available
We've always avoided this feature after experiencing the 'witness in horror' scenario exactly one time. Would love to have this fixed, as in theory it's a very useful feature.
Tom Wardrop commented
I've always just assumed this was a bug, because surely no one in their right mind would find this behaviour desirable, at least not as a default.
Even when you do want to automatically upgrade the version, this still falls short because there's way to force it outside a maintenance window as it's greyed out, as are the option for wake on lan, etc. It's the most dodgy half-baked feature... if you can even call it a feature.
Mike Kauder commented
"witness in horror" ha ha. I know the feeling.
I'd like to see some better intelligence with this process. We use Mimecast for Outlook and distribute it via CM. When a new version is released, it comes out with a new product code. So if someone installs the update ahead of us deploying the new version, CM will downgrade them back to the older one.
Considering the risk posed if a deployment triggers unintentionally, this really should be a high priority.
Roth, Chase commented
I tried some of the work-arounds for deploying in a particular order. It still didn't seem to work for me. This just needs to be fixed without excusing the shortcomings. I should be able to chose: to uninstall previous or not (I can) as well as required or not (I can't). Simply if the app is "Available" should not trigger installs.
@Edward Perkins, the problem here is a feature defaulting to enabled when deployments are made. So the workaround is to not create deployments when the update is superseded. Deploy the app first then add the supersedence relationship.
Chris Wroten commented
From my point of view, supercedence is an excellent way to manage an Application's Lifecycle within your organization. For now, the only real 'workarounds' seem troublesome and the mix of behaviors between User deployments and Device deployments makes it very very frustrating. The only alternative currently is to ignore this feature all together and make use of planned rollouts, hoping that an old version's deployments are removed at the same time the new version is available.
Kyle Ericson commented
Any update come on MS this is a really really mean bug please fix.
Edward Perkins commented
When you say "make a deployment of Version 2.0 first" do you mean the application needs to be deployed to a collection? Or would it suffice to simply create the version 2.0 application first without an actual advertised deployment. I'm going to assume that you mean it has to be deployed to a collection before proceeding. Thanks for the tips, I was about to hit the switch when I came across your article, slightly aged as it may be. Thank you!