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.
This update is now available in the 1712 Technical preview.
There is a similar issue but with the application dependency (and not supercedence) . Please refer to the Premier Support case #118011217456489 for more details.
Thanks Matt for your comment and votes. Please do try the latest Technical Preview and give us your feedback that the latest changes in this regard solve your problem!
Matt Seng commented
This is already in the works, and due to be available soon, but I'm still spending my votes on it. Yes I got bit, and no, it wasn't pleasant.
In my environment, apps are managed by a different team, and I just deploy them. So if the apps are made with supersedence, I have no recourse except to duplicate the apps on my own and make them without supersedence. If I WANTED to auto update the apps, I would deploy them as required. The current functionality offers no additional capabilities and it removes my capability (in my scenario) to push self-service app updates to Software Center, without jumping through a bunch of hoops.
In effect, it forces me to either duplicate lots of work, OR strips me and my users of control, into a SaaS scenario.
So yes, there IS a point to fixing this.
Roth, Chase commented
Yay! Blurb from the TP 1712 notes...
"...in this release you have the option to configure an application deployment to not automatically upgrade any superseded version. Now when creating the deployment, on the Deployment Settings page of the Deploy Software Wizard, for either Available or Required install purpose, you can enable or disable the option to Automatically upgrade any superseded versions of this application."
We got bitten by a variant of this problem today. We also use Available device-based deployments to pilot upgrades for certain applications, but I ensure that the greyed-out Auto-upgrade checkbox is always unchecked (pretty sure it corresponds to the "UpdateSupersedence" property of the object returned by Get-CMApplicationDeployment, which I ensure is false).
However, today, an Available deployment enforced itself automatically on a targeted computer as soon as it entered a maintenance window overnight. This issue is now even more confusing to me:
* Earlier, it seemed that there was a series of steps which would lead to the checkbox appearing in a checked state on the deployment, and it could not be unchecked. This is a bug which should be fixed, but at least the potential problem was apparent from the UI / PowerShell.
* The problem that I faced today was despite the deployment properties clearly indicating that superseded versions of the application would not be upgraded.
Am I not understanding something correctly here? Or is the behavior of the whole mechanism completely non-deterministic, and Microsoft just can't be bothered to fix it in two years?
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.