Application Relationships in ConfigMgr 2012 (B2)

As we all know now for a while already, ConfigMgr 2012 (B2) has a new Application Model. The old fashion Packages are still possible, but there is nothing changed and no features added. They are just there to make a migration easier… Instead we’ve got Applications now, which make it easier to detect installed products, to create dependencies, to supersede, etc.. This post I want shine a light on the different relationships of an Application. ConfigMgr 2012 (B2) knows three different types of relationships for an Application:

  1. Dependencies
  2. Supersedence
  3. Global Conditions

Dependencies

DependenciesViewRelationshipLet’s start with the first relationship, dependencies. Dependencies make it easy to specify the software prerequisites of an Application. The cool thing is that this can be multiple things and it can even contain AND and OR statements. For example it’s possible to say that Adobe Reader 9.0 OR Adobe Reader X needs to be present. Besides that it’s also possible to define what needs to be done when neither of them is present. It’s possible to specify which version needs to be auto-installed, or it’s possible to just let it do nothing.

Also good to notice is that this can be done per Deployment Type. See as example the picture on the right. This picture shows the 7-Zip Application, which contains three Deployment Types. One x86 -version, one x64 -version and one App-V –version. This App-V version has as dependency that the App-V Desktop Client needs to be installed.

Supersedence

SupersedenceViewRelationshipThe second relationship is supersedence. Supersedence makes it easy for an administrator to create a relationship between two Applications and “declare” one Application newer than another previous Application. This is actually the same idea that is used with Software Updates already for years now. The supersedence –relationship needs to be specified on an Application –level, but the actions can be specified on a Deployment Type –level. This makes it possible to specify per Deployment Type what the new Deployment Type will be and whether the old version needs to be uninstalled, or that the new version will do an upgrade to the old version (default is upgrade). By specifying the uninstall option, the uninstall command of the superseded Application will be used.

See as example the picture above. This picture shows the new 7-Zip Application, which contains two Deployment Types. One x86 –version and one x64 –version. The x86 –version supersedes the x86 –version of the old Application and the x64 –version supersedes the x64 –version of the old Application.

Global Conditions

The third relationship is Global Conditions. Global Conditions are the most “variable” relationship, because these conditions can be almost everything. Actually Global Condition is, in my opinion, not even the correct term here, it should be Requirement Rules. The relation between these two is that a Global Condition has to be added to a Requirement Rule to be evaluated. Besides this a Global Condition can contain one or more System Attributes, which can be anything from WMI Queries until Registry Values.  The extra cool thing is that Global Conditions can be assigned per Deployment Type. This makes it possible to deploy multiple Deployment Types to the same (User) Collection, but only the one which has all requirements met will be truly deployed.

GlobalConditionsViewRelationshipSee as example the picture on the right. This picture shows the x64 –version Deployment Type of the 7-Zip Application, which contains three Requirement Rules. One for the required Free Disk Space, one for Desktop Type and one for Primary Device. In this case this means that there has to 100 Mb free disk space AND it has to be a x64 –system AND it has to be the users primary device.

Think of all the possibilities this will generate, like deploying the App-V –version Deployment Type only to non primary devices. There is a whole new world going open!

Leave a Comment