It is important to understand the difference between Microsoft SCCM packages versus SCCM applications and which type to use in your Citrix environment.
Microsoft SCCM 2012 offers two installation types: applications and packages. Applications is a new feature; packages is the equivalent of what was offered in SCCM 2007.
The following table lists some of the the main differences between packages and applications:
SCCM package | SCCM application |
---|---|
Intended for device deployment | Intended for user deployment |
- | Contains detection methods (an installation only runs if all conditions are met) |
- | Older versions of an application can be superseded. The new version installs without having to deploy it. |
Better suited for state-less systems | Better suited for state-full systems |
Can be executed from the SCCM Distribution Point directly | Needs to be download to the local machine first before installation |
- | Supports Apple, Google and Windows Store |
There are more differences between packages and applications. However, the ones mentioned in the previous table are the most critical when deciding which type to use in a Citrix environment.
I prefer to use packages in a Citrix environment. This applies to both Citrix infrastructure components (such as a Delivery Controller or StoreFront server) and worker images. In summary, packages are simply much more suitable for a state-less environment such as a Citrix environment.
You see, an SCCM application is basically an SCCM package on steroids. Whereas a package only serves as a software container, an application is so much more.
An application contains detection methods which can be configured to trigger the installation based on certain criteria. Within an application, dependencies to other software can be defined. If the application detects that other software is needed, than this software will be installed first. New versions of the application can be automatically installed when an older version is detected.
These features are great when I want to assign an application to users on a state-full system. The user logs on to their desktop or laptop, SCCM notifies the user that new software has been assigned and that this software can now be installed. The user triggers the software installation, the SCCM application checks if the user’s machine meets all requirements (= dependencies), installs what is missing and continues to install the main software component.
In short, this is perfect for a FAT client scenario when deploying applications directly to users.
In a Citrix environment, many, if not all of the nice features of applications cannot be used.
In a Citrix environment all software components are installed globally, based on the local machine and not on a per-user basis. Citrix infrastructure components, as well as the worker image, requires that all software is pre-installed before the first user (or administrator for that matter) connects to the system.
Dependencies to other software is covered in the task sequence. The order of the software (the SCCM packages) within the task sequence determines when which component is installed.
Also, in a Citrix infrastructure, software should not be able to update itself.
The fact that SCCM packages can be executed directly from the SCCM Distribution Point is also a plus since the Citrix infrastructure is located in the same data center.
My point is that applications are much better suited for the classic FAT client scenario. It simply would be “over-kill” to use applications instead of packages; most of the cool feature would or could not be used.
There is only one exception to this rule: installations of Citrix components on FAT clients. Citrix wrote a nice article about How To Deploy Citrix Receiver for Windows Using SCCM 2012 R2.
So, there you have it. I gave my reasons for using packages and it has worked well for me so far. You may not agree with me of course. You can use applications instead of packages if you so choose, but be warned! The choice is yours! 😉