Hi,

I was hoping to get peoples input on supersedence in SCCM 2012.

In my view it seems rather backwards with how it is configured. Here is my example as to why. Very interested to see if anyone agrees or suggestions on what others are doing.

There is an application lets call it "Program A". I input a version for it in the main Application screen. I create a Deployment type and deploy it. All works well.

I now have a new version of this program. Now this is where I feel it goes backwards. In order to now deploy this update common sense to me says I should simply create a new deployment type and tell it within that that this is the updated version. I update the version number in the main application window and off I go. SCCM Automatically updates the distribution points with the new version, removing the old one and "re advertises" the current deployment to link to the new version.

However as I understand it this is what needs to happen:

• Create a completely a "New" Application. "Program A v2" (What is the point of a version number if you need it in the name of it to ensure its unique)
• Create a completely new deployment type.
• Tell this new application that it supersedes the old application.

(I now have 2 applications called the same thing with a version number in the name as you cant have duplicates.)

• Create a new deployment for "Program A v2"
• Remove the deployment for "Program A"

I now have 2 applications for the same program.

I struggle understanding the point of this. Why even both creating a relationship between the 2 programs? Adding in the supersedence relationship actually makes the take longer.

Ultimately, the answer is because that's how it was designed.

Applications in ConfigMgr are version specific and are meant to be.

Deployment types are not meant as different ways to deploy an application or for version differentiation; DTs are meant tot define different types of a single (version of an) application. Also, clients dynamically choose between multiple DTs within a single application dynamically at deployment time based on characteristics known to that client like OS, OS architecture, primary user, etc. This does not match up at all with using DTs to define versions.

The supersedence relationship that you create between two applications is more than just "for looks"; it does have functionality and implications: http://setupconfigmgr.com/application-supersedence-in-configuration-manager/

Thanks Jason,

Had a look at the supplied link. Is the only advantage that you get (with regards to supersedence) being able to tell it that it needs to uninstall an application during an upgrade rather than just installing over the top?

Using the example of Java from that link I have a question as to what would be best practice:

• How long do you leave the old application there? Ie after 4 "upgrades" say when would you start removing the old applications and their corresponding data to both clean up the SCCM console and minimise data used.

Hope that makes sense.

Cheers,

Hi,

You just have to leave the old application until all devices get the new version of the application.

You can create a configuration item (and then a configuration baseline that you can deploy on your devices) to see the compliance of the application. If you see that Java's old version is not installed anymore on your devices, you can then remove it from SCCM.

Is that answer your question ?

• Edited by Vahé Touloumain Monday, January 20, 2014 8:42 AM

Hi Vah,

It does to some extent. I guess I understand how to use supersedence in applications in SCCM 2012 as it stands.

This was more trying to get some info from people on if they actually use it because I honestly cant see an advantage in it. To me it seems like more work to get it configured and working over just having separate applications and managing them as such.

Cheers,

Hi Zac,

We use supersedence in our company for the applications that does not uninstall the old version.

As an exemple we have greenshot (a screenshot software). If we don't use supersedence for that software and we install the new version on a computer that already have an old version, we will have two versions of the same software on the computer.

Of course there is other ways to uninstall the old application and then install the new one. But we prefer to use sccm fonctionality (supersedence) instead of using other methods, just to simplify the administration for the deployment team.

Thanks Vah,

Be good to see what others do as well.

Cheers

Well, that link was underwhelming.

Thanks Jason,

Had a look at the supplied link. Is the only advantage that you get (with regards to supersedence) being able to tell it that it needs to uninstall an application during an upgrade rather than just installing over the top?

Not entirely.  It's also valuable if you change product vendors for any reason.  For example you can have Office 2013 supersede OpenOffice.  McAfee virus scanner to Panda.  DPM to Symantec.  Etc.

To be honest my most common use for it is to correct install fubars.  You can create an application with a unique detection string to detected the "botched install" then supersede it with the fix.

At the end of the day, deployment types represent different way to to deploy the same application.  Think of it more like firewall rules.  When you push a product it goes through each deployment type in order, and checks the requirements until it finds a match.  That's then the deployment that is used.  So you can bundle x64, x86, iOS, Google URLs, whatever all to the same "Application" and know it will install no matter what type of device it ends up pointing at.

• Edited by Justin.King 7 hours 28 minutes ago