Application Packaging for SCCM

Throughout this blog we discuss application packaging for SCCM, and compare SCCM application and package deployment types.

In System Center Configuration Manager (SCCM) 2012, Microsoft introduced a new approach to deploying software. In previous versions of SCCM we used the ‘package’ deployment type but we now have the option of deploying via an ‘application’ deployment type instead.

SCCM Application Deployment Type

The SCCM application deployment type is a lot more versatile than the legacy ‘package’ deployment type, and provides native support for multiple types of software package:

SCCM Application Types

We can see from the screenshot that not only does it support the native import of commonly used packages such as MSI and App-V, but SCCM also provides support for mobile applications on Windows, Nokia, Apple and Android platforms.

Importing Packages and Applications into SCCM

When application packaging for SCCM we have the option of using the more modern ‘application’ deployment type as well as the traditional ‘package’ deployment type.

If we imported an MSI (Windows Installer) as a ‘package’ deployment type you would see that we are required to specify an install command line, and from this SCCM will automatically create a ‘program’ which is essentially a routine used to execute our command line. We can filter the program to only run on certain client platforms (operating systems).

Contrast this with importing an MSI as an ‘application’ deployment type. Doing it this way will automatically populate the install and uninstall command lines, whilst basing the uninstall command line on the MSI Product Code property:

SCCM command lines

SCCM Detection Methods

This automated configuration is extended by the use of detection methods. A detection method is a piece of logic that enables SCCM to detect whether an SCCM application is installed or not.

Detection methods can contain multiple detection rules, and all rules must be satisfied for a detection method to be successful. Rather than just restricting an installation to a client platform, we can specify just about anything in a detection rule. By default for MSI deployment types, SCCM will use the Product Code property as a basis for detecting whether the MSI is installed. We could even check for a specific MSI property!

SCCM Detection Method

There are built-in detection rules to enable the application to detect the presence of a file and/or registry key/value. But more interestingly, we can specify a custom script (PowerShell/VBScript etc) to detect whether our software has installed correctly!

In this article, Microsoft provide a table which describes how to return correctly from an SCCM detection script. It probably goes into slightly too much detail for the average punter, so put simply you probably only need to know the following:

Script exit code Data read from STDOUT Data read from STDERR Script result Application detection state
0 Empty Empty Success Not installed
0 Not empty Empty Success Installed

In other words, make sure there are no errors in your code and that it always returns an exit code of zero. And then you just need to ensure that if the application is detected as installed that you write something….anything (we write the word “Installed” below)….to the STDOUT (standard output). If it is not installed, do nothing. Here is a basic PowerShell example:

if (Test-Path "C:\Alkane\Path") { Write-Host "Installed" }

SCCM and Supersedence

Supersedence in SCCM applications provides an automated way of retiring old applications. When we supersede an application, we specify a new deployment type to replace the deployment type of the superseded application.

If the newer application is a completely different application (For example, if we’re swapping Adobe Acrobat X for CutePDF) we should check the ‘uninstall’ box to completely uninstall the superseded application. If there are other PDF writers installed, we may want to specify multiple applications to supersede.

Just note that for an ‘uninstall’ (and not merely an ‘upgrade’) supersedence to work correctly, the superseded target collection type (user/device) must be the same type as the new target collection type.

SCCM and the PowerShell API

SCCM also introduced a set of PowerShell cmdlets that can be used to automate many tasks such as importing a applications, creating collections, creating a deployment types, deployments and a whole lot more.

Investing a little bit of work up front in creating an automated SCCM import script can save a massive amount of time down the line, whilst also creating a really consistent and clean SCCM environment.

Application Packaging for SCCM

If your organisation requires automated application packaging for SCCM please get in touch with us using the details on our contact page.