ConfigMgr 2012, the Application Model and advanced Detection Logic

Two previous blog posts, here and here, detail the inner workings of the new ConfigMgr 2012 application model. When properly used the application model is a capable mechanism to help administrators manage and track applications throughout their lifecycle. As administrators use and are successful with the application model their understanding of its various capabilities increase along with a willingness to investigate how the application model can be better leveraged to solve unique business scenarios. There are several places in the application model that administrators might leverage to uniquely address specific needs. This article focuses on the detection methods available for an application and how they can be used to do more than just detect whether an application is installed.

For this example, consider that Tailspin Toys has an interest in moving to the application model but, due to the need to support legacy business systems, that move is viewed as difficult. The legacy systems in question require the creation of a local ‘flag’ file on systems where deployments are executed to indicate to legacy systems that the deployment was successful. These ‘flag’ files may also contain other information relevant to the deployment.

Because of the stated requirements a decision has been made to continue repackaging and delivering deployments with the legacy package model, which has been useful to support these legacy systems historically.

If the above decision were to be made it would result in the continued use of a legacy approach to package creation and delivery and also likely lead to significant delays in updating dependent legacy systems. Instead, what options exist with the application model to solve this scenario? There is no feature of the application model that will allow deploying a ‘flag’ file as part of application deployment after all! If limiting only to ‘in box’ options as described that statement is correct. With some inventive thinking, though, the application model is fully capable of solving this scenario.

From the title of this article it is obvious that discussion will focus on the detection methods available in the application model. Before getting into details of the example scenario a review of the options available for detection is useful.

Detection methods
Application detection methods are used to determine whether the application is installed. If an application is deployed to a system where it is already present, then a properly configured detection method will find that application and the application reinstall will be avoided. If the application is not present it will be installed and the configured detection method will be used to verify the installation once complete. An install that can be verified by the detection method will be viewed as successful while an install that cannot be verified with the configured detection method will be seen as a failure. For required application installs the detection method will be reevaluated every 7 days (be default and changeable in client settings) to confirm the application remains installed. If the application is still installed no further action is taken. If the required application is no longer installed it is reinstalled.

There are four categories of options that can be used for a detection method – MSI, File/Folder, Registry and Script.

MSI

An MSI detection method leverages the unique product ID of an MSI application to determine if that application has been installed. In addition to the product ID it is possible to also configure a version check. For a manufacturer supplied MSI this method is reliable. For applications that have been repackaged into an MSI take care to make sure the configured detection method is actually configured to detect the installed application rather than the repackaged MSI. Failure to do so can lead to failure or inaccuracy in other areas of the application model.

File/Folder

For applications other than MSI’s or if a detection method is preferred that does not rely on the MSI then file system based detection is an option. With this option it is possible to configure detection of specific files and folders that must be present in order to consider the application installed.

Registry

Most modern applications will write to the registry during install. If this is the case for the application being deployed the registry can be a very useful choice for detection method. Detection logic configured here can focus on any registry hive – HKEY_CLASSES_ROOT, HKEY_CURRENT_CONFIG, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE or HKEY_USERS – and configuration can focus on a specific key or a specific value.

Script

Scripts – the ultimate in flexibility! If a detection method is needed that is beyond what can be delivered with other options detection scripts provide a great solution. There are three supported scripting languages – VBScript, PowerShell and Jscript. The script window isn’t much of an editor so use an external editor to build the script and, when ready, paste into ConfigMgr.

With script the detection options are almost infinite and it is scripts that are the solution to the scenario described earlier. The scenario details specify that a ‘flag’ file be created to indicate that an application is installed. If the application is not installed the ‘flag’ file should not be present. In addition, the contents of the ‘flag’ file need to contain certain detail. A scripted detection method is the perfect solution to not only handle detecting the application in a more modern and sophisticated way but also can handle creation or deletion of the ‘flag’ file depending on the results of the detection.

Two script examples are show – the first and more complete one was built using VBScript. The second and bare bones script was built using PowerShell.

VBScript

PowerShell

Putting it all together
Bear in mind that there is no requirement to only use one type of detection. Mix and match as much as needed between MSI, file/folder and registry. Note that with script there is no ability to add other options. Whatever the choice bear in mind to avoid creating detection logic that is unnecessarily time consuming.

Finally, the scenario described is but one example scenario. Many more scenarios exist that may not exactly fit within the application model on first inspection but with additional thought many things are very workable.