Our team of consultants at 1E – Paul Bateman, Shaun Cassells, John Devito, Jerry Dismukes, Duane Gardiner, Ian Godfrey, Rob Haines, Bruce Hethcote, Vishal Ladwa, Peter Murray, Mike Terrill and Adrian Todd – have taken a deep dive into System Center 2012 Configuration Manager. They have been looking at the key differentiators, new features and functionality it offers. So here's the first in a series of 10 posts about what's useful to know:

  1. Application Model

The deployment of software is probably the primary function of most ConfigMgr implementations. In ConfigMgr 2007, software distribution was achieved by defining Packages and Programs then advertising the Programs to Collections of clients. Different installation types (e.g. a 32-bit and 64-bit installation) would require separate Programs. Typically, a Collection would define the target for each installation type (query-based Collections define the logic that determines which systems should run the Program).
This legacy model is still available in ConfigMgr 2012, and is in fact still required for some of the content required in an OS Deployment Task Sequence (such as boot images, OS images, driver packages and he ConfigMgr client agent). However ConfigMgr 2012 introduces a completely new alternative approach to software distribution – the Application Model. With the Application Model, an Application has a number of Deployment Types, each defining the required source files, install and uninstall command lines and user experience (e.g. does a user need to be logged in?), similar to the properties of the legacy Package and Program.
Deployment Types are deployed through a Deployment, which isn’t a million miles away from the concept of an Advertisement. The significant difference with the Application Model is that the Deployment Type also defines the targeting logic, which is evaluated on the client each time the Application Deployment Evaluation Cycle occurs.
The Application Model uses the same ‘engine’ as the Desired Configuration Management (DCM) feature, so the decision whether to install can be based on values from WMI, the local registry, the return code of a script, even the result of a SQL database query and can also be based on the user (either logged on at the time, or the primary user of the device). The Collections targeted by a Deployment can therefore be much more encompassing – now you needn’t panic when you accidentally deploy to All Systems (as long as you have the right conditions defined in the Deployment Type Requirements!).