An Alternative to Application Supersedence in SCCM

For some software applications, it’s inevitable that you’ll need to deploy a new version now and then.  For example, you deploy an application, then a new version gets released and you want to upgrade all your clients.  Application supersedence in SCCM2012 is a useful way to deploy a new version of an application – you create the new application and specify supercedence of the old version.  You can also uninstall the old version if required.  But for some simple applications it seems overkill to have to create a new application with every release, especially as you have to create deployment types, add deployments, maybe update your task sequences to include the new application, retire the old application etc.

Is there a better way?  Well, for apps that don’t require you to uninstall the old version first, I think there is.  Simply add new deployment types to your existing application. Create a new deployment type with the new version number in the existing application.  Then create a ‘dummy’ requirement rule on the old deployment type to something it’s certain to fail during evaluation. This will effectively disable it, yet keep it should you need it in future.  And then increase the priority of the new deployment type to 1 so it will evaluate and install first.

An example with Adobe Flash (ok, I’m not using 3rd Party Update management yet!)

A ‘dummy’ requirement rule for the previous version, eg a WMI query for the computer manufacturer that will fail the evaluation:

There are several benefits:

• You can keep the previous application versions (deployment types) for as long as you want, should you need them
• You don’t need to create new applications for every new version
• You don’t need to update your applications in your task sequences
• You don’t even need to distribute the new content manually, as it will get distributed automatically after you created the new deployment type
• You don’t need to create a new deployment, as it will use the existing application deployment
• If you have a ‘required’ deployment, then clients will update themselves with the new version after the next Application Deployment Evaluation cycle
• You can name your Applications more generically, eg ‘My Application’, instead of ‘My Application V1’, ‘My Application v2’ etc
• It can save a lot of time if you update applications regularly

You might, of course, want to update the schedule on the deployment until after the new content has been distributed, or to control the deployment time.

For OSD applications which can only have one deployment type, you’ll need to update the existing deployment type instead.

Granted, it won’t work in every scenario, especially if you need to uninstall the old version, although you could run an ‘uninstall’ deployment first, then schedule an ‘install’ deployment after.  But for simple applications at least, it seems to me a better way to manage application version updates.