Application Packaging for MECM

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

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

MECM Application Deployment Type

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

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 MECM also provides support for mobile applications on Windows, Nokia, Apple and Android platforms.

Importing Packages and Applications into MECM

When application packaging for MECM 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 MECM 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:

MECM Detection Methods

This automated configuration is extended by the use of detection methods. A detection method is a piece of logic that enables MECM to detect whether an MECM 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, MECM 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!

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 MECM 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" }

MECM and Supersedence

Supersedence in MECM 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.

MECM and the PowerShell API

MECM 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 MECM import script can save a massive amount of time down the line, whilst also creating a really consistent and clean SCCM environment.