Since the release of ConfigMgr 2012 the new application model allows us to be more user-centric and define administrative intent for a deployment. As with all product the terminology has changed from the previous version, this post will help deliver an understanding of the package and application terminology in ConfigMgr 2012 and how we use them.
From experience of working with customers who are implementing ConfigMgr 2012 I get a lot of comments like “Microsoft have done it again, everything we learned is now not valid”. While this may previously have been the case I don’t think this is valid for ConfigMgr 2012. I think your understanding of how things work in ConfigMgr 2007 is still valid for ConfigMgr 2012 and its more of a case of upgrading your knowledge. For instance this applies for the new application model which I will explain later.
First let’s have a look at how a software deployment job would be compiled in ConfigMgr 2007. As you all know we have a package which is our group of files, programs within the package which execute command lines then we have an advertisement which will advertise our program within a package to a collection. We can represent this relationship in graphical terms as shown below.
So now if we think about the application model we can describe this as follows. We have an application, which inside has deployment types, these deployment types execute an application or script (or maybe App-V sequenced application), they also contain rules for our deployment. We then create a deployment where we deploy our application to a collection. Sound familiar? Here it is as a graphic.
You can chain deployment types together to build up your applications installation such as adding configuration for instance or maybe some patches. The graphic shows one deployment type but you can have multiple and they will execute in priority order.
Some customers find it difficult to understand the difference between a package and an application. At a very high level a package allowed for glorified script execution, we put a bunch of files on the client then told the operating system to execute a command line. The application model is much more elegant. This model allows for user-centric deployments of applications, much better monitoring of installations and installation failures. The ability to upgrade applications to users who have it installed and much much more.
I’m not sure if this is the perfect way to describe an application to someone who has been using ConfigMgr 2007 for a short space of time and just got used to the terms used in 2007 but I have found this works and helps to explain it a little easier to people. People find it hard to decide when to use a package and when to use an application, the simple answer is always application, unless you have a specific reason not to.
I tell people to think of the application as a super package and translate the terms used in ConfigMgr 2007 to the new terms in ConfigMgr 2012. For example, we have in ConfigMgr 2007 a program, what the program does is very similar to a deployment type in ConfigMgr 2012, the deployment type is just a cog in the application model, yes it does much more but from an explanation point of view it helps, check out the following graphic.
I have found that this explanation is the first step to getting people to understand why we have applications, you also have much more to this as the whole model is based around user centricity. Before people can embrace this new way of deploying you first have to understand the model. I hope this diagram does that.
Our deployment (ConfigMgr 2007: Advertisement) is now a way of signaling the administrative intent, for example, we want to make this application mandatory, or we want it to be available, we want to install at this time and so on. User device affinity and the tools available to users in the Software Center on setting their own working hours to control tasks is a huge step forward, this way we are still controlling our estate but we are giving some flexibility to the user, we understand today’s users rely on their technology a lot more and we can’t just force reboots of workstations, working hours and device affinity makes this possible.
When to Use a Package
This sounds like it should have a simple answer, and in a way it does, you should now have way more applications defined than packages. Valid uses I have had so far for packages are all around operating system deployment. The MDT Toolkit Files, Settings Package, USMT Package and Sysprep (if you still need it) are all valid times when you would use a package.
I hope this helps clear up any confusion anyone might have had or if you are indeed having trouble explaining the concept to clients and colleagues that this has also helped. It is a big learning curve for us all but once you understand how it can help you in your future deployments then you will never go back!