App Model: Good.  Supersedence: Bad

From the start I’ve tried to make the most of the ability to define application dependencies and supersedence relationships.  For instance, we create dependencies for Visual C++ redistributables so that we can identify the apps that rely on those that are not longer supported.  The later however, supersedence, has rightfully earned a bit of a bad reputation which  Stephen Owen over at FoxDeploy brought my attention to.  In short, there was a default option the administrator could not change that would automatically update the superseded application if it was found.  So when you went to pilot your new application version using an available deployment you’ve actually just deployed it as immediately required to anyone that has the old version.  I’ve talked to several administrators who simply wrote off supersedence because they got bit too many times: once.  Thankfully, with the release of Current Branch 1802 the team remedied this by making the Automatically upgrade any superseded version of this application option appear in the deployment wizard for both device and user based deployments when deploying as either required or available and default that option to be off.

Now Go Forth and Supersede

Now that supersedence is ‘fixed’, what might you use it for?  The primary use case for supersedence is to handle new versions of applications that can’t upgrade the existing version in place.  You can tell the new app to uninstall the older app before attempting its own install.  With the introduction of ConfigMgr my organization moved to a self-service model for application delivery by almost exclusively using user-based available deployments.  Only truly global applications are installed during OSD and deployed as required.  With 1802 we can now easily use supersedence to pilot the latest version of a given app, validate that it works, and then enable the automatic upgrade to update existing users.  It’s a thing of beauty.

A Quick Note About the Application Model

They say ignorance is bliss and I’m generally a pretty happy guy.  I don’t have a ton of experience with the vagaries of the package model.  Just yesterday I had to learn the hard way that package and task sequence deployments will not appear in the Software Center if you’re not the first person logged into the device (fer-real … David James confirmed … go vote for this UVI).  On the flip side though I’m too ignorant to apply the deficiencies of the package model to the app model.  Packages lack detection methods and can’t detect if an application successfully installed or not.  All they can know is if the command line returned something considered a success or failure.  You are forced to use this success vs failure as a proxy for installed or not.  Applications on the other hand are determined to be installed or not solely by their detection methods.  That’s incredibly powerful for application installs but can also be used in a couple other interesting ways.

Un-managed Applications: Stop the Insanity

Like most organizations that implement a system management product for the first time we had a mess on our hands.  Our users were local admins (against my team’s recommendation) and used those powers as you would expect: for evil.  When we decided to take patching third party products more seriously that created a big problem.  We needed a way to level set and replace the myriad of product versions with the most current.  In most cases we did that by creating applications in ConfigMgr that had no working installer.  All we needed was their detection methods and an uninstaller that worked.  Now, that doesn’t mean we created applications for each version.  We judiciously used detection methods generic enough to detect multiple versions.  So instead of an MSI product code we would test for the presence of the EXE or maybe a registry key.  Those applications were then superseded by the new application and required to be uninstalled.  Crucially, this allows the current version’s application to work the same on new devices during OSD as well as existing devices.  After all, if the old version isn’t detected then there’s nothing to uninstall.

Now, I know what some of you are going to say here: you can script this.  Agreed, you can.  I’d argue that’s doing that from scratch is generally more complicated than using supersedence.  The most compelling argument along those lines is the use of the Powershell Application Deployment Toolkit‘s Remove-MSIApplications function which can uninstall all MSI applications based on a name (ex. ‘Java’).  If you’re comfortable with Powershell (get comfortable if you’re not) and the application uses well-behaved MSIs this is certainly an option.  Maybe it’s just a weird quirk of mine but even in this case I would use a superseded ‘dummy’ application that uses PSADT to do the uninstalling rather than a single app to do it all.  I won’t pretend to defend that preference.

Reporting the Truly Weird Twisted Stuff

Another interesting use for detection methods is for reporting.  Before you start replacing all your un-managed application like I describe above you might want to know how bad it is.  By deploying the ‘dummy’ application as available and hidden you can use the application compliance data either right in the console or the built-in reports to see what the situation is.  This can also be extended to the weird ‘applications’ in your environment that aren’t applications at all … files, reg keys, or the like.  To be sure, there’s other ways of accomplishing this with compliance items or extending hardware inventory so this is just one more tool in the box.  It’s up to you to decide which tool make sense for a given situation.