Automation tails from the fox hole

You might be wondering how to control this box in your SCCM 2012 R2 SP1 (or ConfigMgr SP2, pretty much the same thing) deployments.

I’ve finally been able (with the help of my friend and future ConfigMgr MVP nominee, Eric Anderson) to track down precisely what is going on in the confusing world of applications and supersedence in SCCM.

The Scenario

· Machines all had the old version of Java, Java 8 Update 65, which is deployed via either a Task Sequence , or with a firm-wide mandatory advertisement
· We made a new deployment of Java, Update 71, and set this to supersede the old version
· The new version of Java was deployed as Available yesterday, not required, to a small subset of machine (5 or so)
· Today, these machines have all automatically updated to the newest version of Java even though it was an Available deployment!!

Looking into the logs, we see this:

AppIntent –

The Juicy part : Will uninstall/upgrade superseded DTs (deployment types)

Then, in AppEnforce a few moments later-

So, we can observe that the machines saw the new advert, and began to automatically apply it, even though we never checked a box to ‘Automatically upgrade clients’…

Or wait…maybe it is.

As it turns out, the checkbox listed in the screen shot above, this one here:

This option is never actually displayed to the SCCM ADMIN while making a deployment. The check box is conditionally displayed after configuring a deployment, and It’s only shown if the application has a supersede rule specified. If so, the box will appear after completing the New Deployment wizard.

Whether or not the box is checked depends, strangely enough, on if the application supersedence rule was configured before or after the app deployment was created.

The worst part about this is that the checkbox isn’t available for the Admin to control when making the new advertisement, but instead appears after the Deployment Wizard finishes. And deployments can’t be altered after they’re created, so no fixing it afterwards either.

Here’s the scoop: this is either a bug or a serious design flaw in SCCM.

But you still need to know how to control the behavior of supersedence, which actually isn’t too complicated, once it’s laid bare.

To allow users in the collection to upgrade to the new version of an app , without being forced to upgrade

Create the deployment of version 2.0 of the app, THEN create the supersedence relationship.

The app will be available to upgrade, and available for new users but will not be enforced on users of the old application, as shown in this screen shot below:

To automatically upgrade users of the old version to the new version of an app, while allowing others the option of installing it

The only difference here is that you create the supersedence first, and then deploy as available to a collection of computers.

Users in the targeted collection who have the old version of the application will be automatically updated to the new version. Users who do not have the app can install it at will, as expected.

To Recap

It turns out this checkbox is only created after a deployment is made, and not actually presented to the user at all.

If a deployment already exists, and then later a supercedence is created, the checkbox of ‘Automatically upgrade any superceded versions of this application’ will be made visible on the deployment, but not checked.
HOWEVER: If a supercedence is created FIRST, then a deployment is made, the checkbox will be added AND checked. This has the same impact as making a new required deployment, even if the deployment is marked as Available.

14 thoughts on “SCCM – Controlling Application Supersedence”

Thanks for sharing Steven. It is defenitley a good thing to know the workaround, and this blog post will make us gain some time (and avoid some pain and frustation ;)).
I have also voted this up on Uservoice.

I just would like to mention the behavior this article is talking about is in regards to deployments to machine collections.

Deployments to user collections will give the option to enable or disable “auto updates” during the deploy wizard, though to remove you do have to delete and recreate the deployment as stated in the article.

Those that see a 10% upgrade anyways… doesn’t surprise me.

We have witnessed simulated deployments actually run on a small %. It is also common to have user targeted “available” Auto-upgrade deployments scheduled in the FUTURE to trigger a % of machines to display the to-be upgraded version in the software center notification balloons and all (these are user deployments so should only be in catalog unless already installed).

We have not been able to figure it out, its not ALL users or machines just some but it happens fairly consistently. I suspect it has something to do with how SCCM records deployments locally on the client. Since user based deployments seem to record deployment only for that user (Even if the deployment type is run as system),.

We have in the past setup machine based “upgrade stragglers” deployments to upgrade machines where the user that installed said app no longer logs in (but other users who the upgrade is still targeted do).

We would delete the machine based deployment after compliance is met and that deployment is probably never “cleaned” up or re-evaluated in the database/wmi.

From what I observed, SCCM should probably record deployment per machine or per user based on the Deployment Type NOT the kind of collection it was deployed to.

Was just bit by this today, wish I had read this yesterday. At least it was ONLY Chrome, to 7000 machines, at 3pm on a Wednesday, but now I have more proof for those naysayers that claim SCCM doesn’t “work”

Stephen, just tested in 1702 and this now appears to be fixed. When creating application deployments on superseding applications you now have ‘Automatically upgrade any superseded versions of the application’ option. If you do not select it, the application does not install automatically when deployed as available. If you do select it then it does as well as allowing you to set a deadline. In line with most other deployment options, you cannot change it after the fact.