I need clarification on how application supersedence is supposed to work in SCCM 2012.

I sometimes see superseded applications being re-installed after a successful install of a new version. On some threads it has been suggested that you must delete the previous deployment to prevent this but I don't find this requirement in any of the official documents.

When I check the logs, it sometimes recognizes that the apps is not required, but then sometimes initiates an install.

Have you retired the superseded application? When you retire it, it won't be deployed anywhere after that.

Retirement also mentioned here:

http://setupconfigmgr.com/application-supersedence-in-configuration-manager/

• Proposed as answer by narcoticoo 7 hours 35 minutes ago

Hi,

You need to delete the deployment of the Superseeded application or remove the computer from the collection where the application is deployed to so that the computers which has gotten a new application isn't targeted by the deployment of the Superseeded application.

Retire will not remove any active deployments, so if you retire an application with an active deployment the deployment is still active, you cannot deploy the application again as it is retired though.

"When you retire an application, it is no longer available for deployment but the application and any deployments of the application are not deleted. " http://technet.microsoft.com/en-us/library/gg682031.aspx

Regards,
Jrgen

Have you retired the superseded application? When you retire it, it won't be deployed anywhere after that.

Retirement also mentioned here:

http://setupconfigmgr.com/application-supersedence-in-configuration-manager/

• Proposed as answer by narcoticoo Wednesday, January 15, 2014 4:50 AM

Have you retired the superseded application? When you retire it, it won't be deployed anywhere after that.

Retirement also mentioned here:

http://setupconfigmgr.com/application-supersedence-in-configuration-manager/

• Proposed as answer by narcoticoo Wednesday, January 15, 2014 4:50 AM
• Unproposed as answer by Tim Boggs 14 hours 52 minutes ago

In Group Policy when you supersede an old application with a new application, the old application will no longer installed. I would expect the same behavior with SCCM.

So if supersedence is not used to determine which of two applications (old and new) are to be installed, what is the purpose of creating supersedence relationships?

My current deployment practice is to deploy to three groups. Alpha, Beta and Prod. Alpha and Beta users are excluded from the Prod group. There is no overlap of users. I cannot retire the old application until the new application is deployed to the production group. As indicated by Jrgen, I have attempted to retire old apps and still had it reinstall on computers where it was previously installed.

Prior to yesterday I had three active versions of this application deployed to prod. Checking the CCM logs, I could see that when each new version rolled out, CCM was attempting to reinstall the old applications for about, 24 hours after that if quit until the next version was released. Very strange behavior. I would expect a deployment that has been superseded to not deploy.

In Group Policy when you supersede an old application with a new application, the old application will no longer installed. I would expect the same behavior with SCCM.

Why would you expect this, this is not IntelliMirror, this ConfigMgr. Coincidental naming does not imply functionality. Software delivery is very different in ConfigMgr than it is in IntelliMirror (the original name for software delivery via group policy) and so drawing any type of parallel simply isn't valid.

Please show me in the MS documentation where the expected behavior of supersedence for SCCM is described. I have yet to find a single document from MS that states you have to disable old deployments when you supersede them. In the absence of that advice/documentation, I have to draw upon prior experience with MS products. Based on GPO and WSUS behavior I would expect supersendence in SCCM to mean the same thing or something similar.

So far I have not be able to find any documentation from MS on the expected behavior of supersedance as it applies to old and new versions. Most blogs on TechNet or the rest of the web just cover a simple app deployment, not lifecycle management of applications. Those blogs that do mention supersedence just show you how to do it, and have not delved into the ramifications or expected behaviors.

I sometimes see superseded applications being re-installed after a successful install of a new version. 

You did not provide enough information to find out the cause of that behavior. Just setting up supersedence for an application does not change anything on the client side. There needs to be a deployment for the superseding application so that it becomes active on a client.

Okay, lets give a scenario and see if anyone can provide best practice for deployment.

I have and application called "App 2.0". I deployed the application using a three stage user based deployment - Alpha, Beta, Prod. Typically I have the deployment scheduled to become available at 4pm the day before it is released with a required install time of 5 AM. This way it installs right after user login at 8 am.

Alpha is a collection of test accounts strictly for testing the install. Alpha users are excluded from the Beta and Prod collections. Beta contains actual test users that will use the application on live data. Beta users are excluded from Prod collection.

Alpha is deployed week one, Beta week two and Prod week three. The 2.0 app deployed successfully to Alpha, then to Beta and then to Prod. The deployments did not include notifications of install.

Next we had to release "App 2.1". App 2.1 can be installed directly over 2.0, no uninstall or reboot required. I followed the same deployment methodology through Alpha, Beta, Prod. Since 2.0 did not have to be uninstalled, I configured supersedence without checking the uninstall box. I did select that the old deployment type should be replaced by the new deployment type. Since this is a user based install, I configured it to provide notification to users so they would be aware that App 2.1 was replacing an App 2.0.

During this set of deployments, no problems were discovered. I have not routinely checked the workstation logs to verify the deployments. I just thought that have the app installed and SCCM reporting 100% indicated success.

I really started seeing problems when "App 2.2" was released. Since App 2.1 was configured with notifications it became apparent fairly quickly that it was not working as expected. App 2.2 deployed at login and 2 hours later users started getting popups that App 2.1 failed to install. This occurred because the app does not allow a newer version to install over it. I didn't see this in the app 2.1 deployment because the 2.0 deployment did not have notifications enabled.

Now what is even stranger, is that after about 24 hours, SCCM quits trying to install the previous application. At least according to the logs, there is a large gap that coincides with the deployments.

On deployment day, one computer's appenforce log showed 2.2 being deployed to the user at 7:52. Then at 7:56, 10:16, 11:24, 12:20 and 2:12 it attempted to install 2.1. It's been two days since and it hasn't tried to install again.

If supercedence is not supposed to be factor in determining if an application should be installed, why do deployment reports show supersedence as a reason for requirements not being met? In my case, on all the computers that were upgraded from 2.0 to 2.1, the deployment report for 2.0 shows 100% success with all of the users under "Requirements not met" and a reason of "Superseded by App 2.1".

I have come across the same situation with other applications before and had similar questions.  Experiencing first hand that a superseded application will try to install if an advertisement is still active on a collection for the "old" version due to it's detection method not being fulfilled, I've resorted to "quick and dirty" means to get around this behavior when needed.

Probably not best practice, but what I've done on occasion is to add an additional detection method on the "old" application that fulfills the "new" application.  i.e. adding an additional MSI GUID or registry key with an "OR" statement.  That way when the new app installs, the old app will stay detected and not try and re-run. 

Again, not the prettiest scenario, but it can be a temporary workaround until you get things updated and can delete/retire the original application and advertisement.

• Marked as answer by Tim Boggs 14 hours 52 minutes ago

Brian635, your answer is not what I expected, I am going to mark it as a solution. I think there is something wrong with the implementation of supersedence in SCCM. It sort of half works, sometimes.

Based on the other feedback I have received I don't see the point in even configuring supersedence on new apps that install over the older versions. They only time you would need it is when you need to force the uninstall sequence to run for the older app. All you have to do is delete the old versions deployment since supersedence won't block it from redeploying anyway.