Forgive me if this question has been asked already.  I have Googled (Binged) far and wide and have not found any real posts that say what is the best option for this type of application scenario.

So, her goes...

Is there any scenario where you would revision an application instead of Superseding it?

An example I would like input on would be something like Adobe Reader.  My obvious thought would be to if you are moving from a deploy of Reader 10 to Reader 11 that you supersede reader 10 with reader 11.  I think this would be the best course.

Now, let's assume that we don't have a SCUP package for Adobe Reader updates and we cannot use SCUP as an answer.

So, our deployment of 11.0.4 has completed to all systems (As a script deployment) and 10 is no longer out there.  Now, Adobe Reader 11.0.7 has been released as an MSP patch update to 11.0.4.  In this scenario, I am not sure if I should revision the install script to patch to 11.0.7 and update the detection method to 11.0.7 or supersede the install with a scripted install that installs 11.0.7.

Assume that my Script install can detect that 11.0.4 is already installed before patching to 11.0.7 and that my script install can also remove older version of Reader 9 & 10 as well.

What would be the thoughts from everyone? What works best for you?

You do separate applications of 9, 10, 11.04, 11.07 with their own detection methods. For Adobe 11.04 and 11.07 you could use MSI product code AND the AcroRead32.exe fileversion which is different for them.

Then you configure 11.07 to supersede 9, 10 and 11.04. Now when you deploy 11.07 to a collection of systems that has any of those (9, 10 or 11.04) they will be uninstalled like you've configured, after this the 11.07 will be installed.

• Proposed as answer by Narcoticoo Thursday, February 27, 2014 9:31 PM

I don't know if it makes sense though to create a new application for what boils down to a small update to an existing application. In the model you describe, at Adobe Reader version 11.0.10, you could have potentially 10 different apps for Adobe Reader 11. This would also have a Supersedence chain that would be 10 apps deep, correct? If I did a revision with updated script code to install, and updated detection method, wouldn't the app be reevaluated? And since it is a scripted install that detects the patches needed, it would install only the required patches? Does this seem like a reasonable approach? I guess I am looking for what works for others?

The application model was designed so that you do a different application for different version, you can even see that from the GUI when opening properties of the application, there's a specific place for the version of the app. Revisions are not meant for application deployment version controlling.

For the supersedence to work, you have to configure ALL the applications that you want to supersede. If you search the web, you'll see that everything pointed to supersede and ConfigMgr 2012 is about doing an application for each version and configuring the supersedence between the versions.

If you would change the detection method the client would indeed re-evaluate the application as not installed and then "install" (update/uninstall&reinstall depending on your script etc). Default is that the client re-evaluates all deployments every 7th day.

I'm not sure that I would recommend narcoticoos approach since you get a lot of applications that way and because how to application model works it could be a problem with different applications in that supersedence chain linking to different revisions of the applications.

The best way would be to go with SCUP or something like that.

When new version is released, you do a new application that supersedes the old one, you delete the deployment for the old one and you also retire the old application so that it cannot be deployed any more. Basically you will end up with only ONE old version that gets superseded with the NEW one, after you've gotten rid of all the old ones first.

Someone can correct me if I'm wrong, but to my knowledge, this is how the product was designed to work.

Thanks everyone for all the replies! I understand how the product was designed. I also understand the following the design doesn't always produce the most desirable results. I am looking for what works for people in practice, not what the design says. But, if superseding and retiring all 10 versions of Adobe reader is best in practice, then, I would likely go that way. I have read a few recommendations that an additional deployment type be created with a higher priority as well. Each new DT would be the later version of the application. This would then trigger the reevaluation. I also have read about the worry of the supersedence chain getting broken as well. This and the flurry of additional applications (although they are retired) is why I question the model. Any additional thoughts from the community?

Adding an additional DT won't help much. Only one DT per application will be installed (if the requirements

Hi Torsten,

You're right that only one Deployment Type will run per application. But, if you update the existing deployment type with proper detection method, wouldn't the client then apply that update next time it runs it's deployment policy?

I don't think the above method will work when moving from one major version to another. And frankly, I'd go with separate application for major version release.

I haven't tried the above approach, but I'm curious to find out :)

If the new deployment type was created and them moved to the highest priority, I would think that would force it to reevaluate with that deployment. Then, you would have the old deployment for history. Like Tim said, having the potential of 10 Adobe Reader applications (11.0.0, 11.0.1, 11.0.2, 11.0.3, etc) and having to keep them all (for supersedence chain) seems like an eventual messy task. Other thoughts?

Like I noted, the mess is only at the beginning. After you've removed the unwanted versions from your environment, you can delete those applications too.

I would not change/update existing DTs and/or detection methods. Create a new application instead. Much easier to troubleshoot.

I concur to Torsten, it's way more simpler.

So, to conclude, when a point version patch to Adobe reader were to come out. You would copy the old source content, add the patch to the content and update the script install to detect the current version. Then, create a new application based on the new script. Then, remove deployments of old version and retire. Then set new version of reader to supersede the old version. Then, deploy new version. In this case would you set it to supersede and not uninstall since the scripted install will only install the updates? This sound reasonable?

Narco, you said you can remove unwanted versions after a while. How do you handle this and not break supersedence chains? That is one thing I have read to be wary of.

What do you mean abot breaking supersedence chains? At the end you only want ONE version of the application right? First you need to remove the unwantend versions and there you'll need the older versions, and after you've got rid of them, you don't need them anymore.

Did you get this one solved?

PaulWetter did you figure out an acceptable way to handle this for yourself? I see there is lots of comments here but none marked as answer. Thanks!

This is what i have decided to do.  After much reading and hearing discussions about oddness with  Supercedence, I decided against using it.  My final solution is to publish a new application at each release.  The main applications that become a concern to keep up to date are Adobe Reader and Java (yuck).

So, for both of these, I use the PowerShell App Deployment Toolkit off of codeplex to better handle the installs.  Especially with MSI based installations, it will handle if the base app is already installed (in the case of Adobe) or if it needs to install one of the MSPs to bring it to the latest.  Works like a charm.  So, each quarter, I create a new application for the new version with a new detection and use a copy of the original source files that include the new MSP.  Also, Adobe handles the uninstall of versions of reader that are 8 (or 7) and newer, so we don't have to worry about uninstalling old releases when the next major release comes out.

Java, i have the PowerShell App Deployment Toolkit remove all existing versions of Java off of the machine and then just install the latest MSI version.  So, it kind of works the same way as adobe.  Create a new application for each version of Java and avoid superceding applications.

So, that's where I am at.  Hope this helps.

• Edited by PaulWetter 13 hours 53 minutes ago