With the introduction of SCCM 2012, Microsoft debuted a new way of managing software. This method is Applications. The new application model closed a lot of the gaps left by packages in SCCM 2007. This article will go through the similarities and differences between the two, and will also tell you when one may be better then the other.
The application model, combined with the application catalog, is where Microsoft is going. The day will most likely come where there is no Software Center and everything is done via the website that hosts the application catalog. Learning how to create and manage applications now, as well as beginning to slowly migrate your legacy packages to applications, will benefit you in the long run.
Differences
I will start with a quick run-through of the differences between applications and packages. First, applications are primarily designed for user deployments, while packages are primarily designed for device deployments. You can still use packages for user deployments and applications for device deployments – the settings in each type are just more geared for one versus the other. Either of these types can also be installed using required deployments, either for user or device.
Second, applications can utilize the new approval request feature. This is the feature that allows the administrator to deploy applications to a wider user base, while still maintaining license control. You can find an entire article on approval requests here: SCCM 2012 – Application Requests and Orchestrator Alert – (windowsmanagementexperts.com)
Third, applications provide a much greater level of detail when looking at the application’s deployment status. It pulls up error codes, and also has more categories of statuses.
Fourth, the application feature can deploy apps to devices that are in the Apple App Store (for iOS devices), Google Play store (Android devices) or the Windows Store (for Windows Phone or Windows 8). This allows administrators to provide these apps in a managed format.
Applications
Applications give you more options to target particular devices. You can set detection method clauses to determine if a particular file, folder, registry key, or Windows installer code exists. If the condition is met, then the application either runs or it doesn’t, depending on what the administrator specifies. With packages, the administrator would have to specify certain files or file types in the Software Inventory section of the SCCM client. SCCM must have a pervious inventory record of these files or file types to create collections based on them. The application model makes this whole process much simpler, because it can look at any criteria on the fly. An article on these methods is forthcoming.
Applications can also be superseded. This means that if you update your version of Flash player, and you supersede the old version, the application will re-run, and install the new version of Flash without having to redeploy it. Applications provide an entire process of developing an application, deploying it, and then eventually retiring it.
For certain installer types, applications are very easy. If you have a MSI, SCCM will automatically set the name, manufacturer, version, and uninstall string (you change these if you want) for you. It will also set the detection clause for you based on the Windows installer code. This doesn’t only apply to MSI’s. It also applies to apps for the Windows Store that comes with Windows 8. Applications that come in a Scriptable installs format (i.e. EXE’s) will still work with the application method, but the administrator must add all of this information manually.
Finally, applications utilize single-instance storage (now called the content library), meaning that they only need to store the content once on your distribution points. For packages, content must be saved to the distribution point and to the package share to deploy software from the network (i.e. not have to download the content then run it). Applications do not have this restriction. They get saved one time, and run either from the network or by downloading the content first.
Packages
Packages are far easier and less time consuming to set up than applications. For an application, the administrator must figure out the correct detection clause, and fill out a lot more information. Packages are created the same way they are created in SCCM 2007, and the administrator only has about five screens to go through.
Also, management of the deployment of specific programs is separated with packages. With applications, you are deploying all of the deployment types that you set up. You cannot pick only one to deploy. The biggest issue this gives is if you need different user experience settings for an install from Software Center versus an install from a task sequence. Say you have one deployment type that is set to run only when a user is logged in or allow the user to interact with the program. Applications or Packages cannot be added to a task sequence with either of these settings. For applications, you would have to have two separate applications to do this.
One glaring disadvantage to packages is reporting. Applications have much more detailed reporting then packages. With packages you only get whether the install was success or failed.
Example of Application Deployment Status
Example of Package Deployment Status
Summary
Because Microsoft is moving towards the application model, enterprises running SCCM 2012 should begin migrating their legacy packages to applications. A tool to help you convert your packages to applications is available at: https://www.microsoft.com/en-us/download/details.aspx?id=34605. I hope this article helped explain a little bit of the differences between the two.
