Automating Third-Party Application Packaging in Microsoft SCCM

Automatically packaging applications in Configuration Manager was a top request since we started our third-party update catalog in 2013. We’ll review how we automate application packaging in SCCM and review some of the challenges and benefits we believe this feature offers. 

• The Basics of Application Packaging Configuration Manager
• How to Automate Application Packaging in Configuration Manager
• Why Application Packing was an Important Complimentary Feature to Patching
• The Basics of Patch My PC Automated Application Creation
• Ability to Customize Applications when Needed

The Basics of Application Packaging Configuration Manager

Creating an application for deployment in Microsoft Configuration Manager requires a lot of moving parts. For example, Microsoft Docs lists the following items as just some of the properties available when creating an application: Content, task sequence, detection method, user experience, requirements, return codes, dependencies.

For more info on creating applications, you can also review a video guide we created that covers this topic. If you manually create applications in ConfigMgr, here’s a general overview of the high-level steps involved:

1. What Application to Package and When to Repackage/Update the Application

The first step in packaging applications is determining what application your company needs to package. The hard part is determining when you need to re-package the application when an update is available. For example, in 2019, Google Chrome had 64 releases. Many of those updates were security-based releases, so the most time-consuming task is maintaining the application.

2. Obtain the Installer Binary

Once you have determined the application you need to package or update, the next step is to figure out where to obtain the installer file from the vendor. This process often involves searching on a search engine or reviewing the vendor’s website.

3. Determine How to Install the Application Silently

• • Once the installer is downloaded, you need to figure out how to run the installer silently, so you can deploy it in an automated way using SCCM. If you are lucky, the installer may be a Windows Installer (*.msi file), which uses standard command-lines. Within our supported products, half of our installers are (*.msi) files, and the other half are (*.exe) installers. For (*.exe) installers, the fastest way is to search online or review the vendor’s docs to determine the correct command-line to use.
  • Once the steps above are complete, this is when you can actually start the process of building the application in SCCM. You will run the create deployment type wizard, and fill out the metadata, including content options, installation program, uninstall program, repair program, detection method, task sequence options, dependencies, and user experience.
  • Once packaged, the application is now ready to be tested to be deployed to a testing collection. If testing goes well, you have now packaged a Configuration Manager application!

How to Automate Application Packaging in Configuration Manager

Our Publisher can help you automate the steps listed above. After configuring basic application creation options as shown below, our service will sync automatically and allow applications to be automatically created and updated.

After configuring your SMS Provider and Source Folder, you can choose what products you want to enable automatic application creation. You can even configure helpful right-click customization options for applications, as shown below.

Once the sync is completed, you should see all the products you enabled appear as applications in the ConfigMgr console.

The applications automatically created are ready for deployment in task sequences or collection deployments and can be used for initial deployments of application to devices. Our application also will have all the relevant metadata pre-created such as icons, descriptions, keywords, etc.

Another benefit of automated synchronization is we can automatically keep the applications up to date.

Here’s an example of the content source folders and applications. You can see the content source structure and how much time you could save by not having to package hundreds of applications manually.

On average, our customers save around 6,000 hours per year.

Why Application Packing was an Important Complimentary Feature to Patching

In 2013 when founded, we only offered the option to create third-party software updates in ConfigMgr/WSUS. The ability to patch third-party updates provides value, but there still is a gap if third-party patching is all that is offered. One obvious gap is software updates are state-based, meaning they are only applicable/required if an older version of the same application is already installed.

This means for third-party updates to be helpful, you need to package the application using the steps above at least once. Before our application packaging feature, we found many customers would keep packaging applications manually to ensure their base application remained up to date. For example, our customers wouldn’t want to deploy an old vulnerable version of Google Chrome during their task sequence deployments.

Although the third-party updates would eventually update an outdated application installed during a task sequence, it will take some time to apply since a Software Update Scan Cycle and Software Update Deployment and Evaluation Cycle would need to run first. Often, third-party updates wouldn’t apply for days if customers use maintenance windows, and updates may require unnecessary restarts compared to deploying the latest version initially, to begin with. Our customers wanted to avoid having outdated and potentially vulnerable applications installed without the need to package application updates continually.