In this post I will be discussing on difference between Application Model vs package deployment. What are the difference between 2 different kinds of Models to deploy software in your organization using Configuration Manager.

What is Application Model

Application model was introduced with SCCM 2012 version and this completely changed the way we deploy the software previously. Application model comes with such an immense feature which can’t even come close to old way of deploying the packages.

Application Deployment Evaluation triggering re-installation if removed

At very high level just think about how software updates are deployed. When we deploy patches with required deployment, it will forcefully install the patches. No matter if patch fails during that period, software update evaluation cycle will trigger again after 1 week (depending upon client agent settings specified for this) and will force the installation again. This will happen in scenario if somebody uninstalls the patch, hence triggering the patch installation one more time.

This kind of approach is used in Application model where we force the application deployment and every week or so (client agent settings) it will trigger the “Application Deployment Evaluation cycle” and force the application install again.

Detection Method functionality

When application is created, you have to create deployment type to provide the source. When we select msi file, it creates install and uninstall command automatically. No only that it creates the detection logic which can be seen under Detection Method.

The benefit of Detection Method is that, the application will only get installed if it is missing. Detection Method will first detect if this application is required or not, if it is missing, then only application will be downloaded and installed.

Supersedence

Application Model comes with Supersedence feature. Let’s say new version of application is released. Create application for new version, under Supersedence tab, specify the old application by defining:

Old Deployment Type
Replacement Deployment Type
Uninstall

Once you deploy this setting, your old application will be uninstalled and new version will be installed.

Dependencies feature

Dependency is one of the important feature of application deployment type. Let’s say an application requires few other applications to be installed before getting the current one installed. One of the scenarios you can think of is to install .Net Framework application.

Under Dependencies tab, specify list of “Software dependencies” which will trigger all other applications to get installed as part of one single application.

Requirement

SCCM Application Deployment type comes with Requirement feature which allows various conditions. If the condition is met, it will be evaluated as True for the device or user as an applicable application and it will get installed. If Requirement is not met, application won’t be installed.

Requirement can be used for Device, user or can have custom setting as category. Following list of conditions can be used for Device category:

• Active Directory site
• Co-managed device
• Configuration Manager site
• CPU speed
• Disk space
• Intune O365 ProPlus management
• Number of processors
• Operating system
• Operating system language
• Organizational unit (OU)
• Ownership
• Total physical memory
• Windows Store Global Condition

Let’s say, we can create a condition for “Total physical memory” to be minimum 8192 MB. Hence, use operator as “Greater than or equal to” as 8192 MB

We can have multiple conditions specified under same deployment type.

Multiple Deployment types

One single Application can have multiple deployment types. Each deployment type will be having its own different source. Few points to remember about multiple deployment types:

1. You can deploy an application; you can’t deploy 1 specific deployment type.
2. You can think about a case of an application with 2 source, x64 and x86 bit. Needs to create to deployment type and each of them will be having their own “Requirement” or say condition set to use relevant x64 / x86 operating system version set. Hence x64 bit software will install on All windows 10 64-bit version and x86 for All Windows 10 32-bit version.

• Multiple Deployment types will have Priority. At a time only 1 deployment type will get installed on device. If condition / requirement is met for both deployment type, then Priority kicks in lower the priority – means it will get installed. You can change the priority. Usually deployment types are made in such a way that only 1 deployment type will be applicable others will become “not required”. Check the link to know more about How Application Deployment type Priority works.

What is Package Model

Packaging model or we can see legacy packages are the old way of deploying to packages. It still works and Microsoft is still supporting it with the latest versions of Configuration Manager. Deploying packages using package model is the most straight forward way used before introduction of Application Model.

Packaging Model doesn’t have any of the features which Application model has such as Supersedence, dependency, requirement and others.

Difference between Application and Package model in SCCM

Let’s see side by side comparison of the 2 different kinds of models:

Application Model	Package Model
Modern way of deploying the applications.	Old Legacy packaging model which is still supported with Configuration Manager
Comes with Application deployment evaluation feature for evaluating the required application and if missing reinforcing it again on device. It will never try to install again if app is already present.	Packaging model can only be deployed once. You may use reschedule feature but that will only force the application to get installed every time.
You can supersede the old application with new one.	No such feature available
You can create dependency for an application to trigger other application install as part of installation	Packaging model doesn’t have this feature. Though Package / program has a feature “Run another program first” by specifying another package, but this feature is not so versatile and smart like dependency feature.
Comes with a huge list of “Requirement” feature to set the condition for application installation such as OS version, CPU Speed, disk space, no. of processors, AD Site etc. Can create custom condition as well.	Package model just have estimated disk space and Operating System condition only

Do we still require Packaging Model?

The answer would be yes. There will be cases when we still need to use packages. Moreover, questions comes when to use packages? what are the use case?

Deploying packages will make sense for scenarios when we wanted to skip “application deployment evaluation” or I can say a package which needs to be run only once. For an instance, copying files to specific location or getting hosts, lmhosts files getting replace with new ones (just an example).

Another case would be to run the package directly from Distribution Point, this feature is only available with packages when you select the option under Data Access and enable “Copy the content in this package to a package share on distribution points”

Once you select this option, package will be copied to Distribution Points c:\smspkc$ or d:\smspkgd$ share with PackageID folder name created and will copy the content.

With this option selected, the benefit would be when you try to deploy a package, you will see another option under “Deployment options” as Run program from distribution point.

This feature comes handier with Task Sequence, when deploying you have have deployment options as “Access content directly from a distribution point when needed by the running task sequence”.

Task Sequence step for Apply Operating System can be selected to use Access content directly from the distribution point. This will access the UNC path to get the content directly from smspkgc$ or smspkgd$ directly.