Configuration Manager 2012–Application Model Part 1
Dear Application Model,
Ever since I laid eyes on you I have been blown away thinking of the all possibilities that you will bring. Sometimes I wake up at night with nightmares that this is all just but a dream. Pinch me am I awake! You wouldn’t believe the things that I’ve been through over the last few years. Now don’t get me wrong, the SMS platform has provided a best of class infrastructure for my master System Admins to use. In fact they are quite creative and have done things that are of epic proportions, such as delivering to my peers a flawless upgrade of Office 2010 with 20 language packs across networks that I am sure were 50% shoestring. I can’t wait for them to discover you. Are you ready?
This brings me back to my first memory of you. When you first deployed an application using the new Application Model in Configuration Manager 2012 the force was strong in my WMI layers of goodness. Without much effort was I able to apply state management to the application you delivered. I immediately told the nearest machine about the wonders I’ve discovered. At first they didn’t grasp it. I created the following diagram to help in my discussions:
Before we discuss this in detail you should review the Application Management of Configuration Manager 2012 located here view.
Forever Yours,
Windows Operating System
Now on a more serious note I’d like to review the areas of Detection, Requirements, Supersedence and Dependency of the Application Model which I find to be so much fun.
In this Part 1, I will focus on the Detection section.
I summed up Detection as “Things that tell me I exists”. It is the area in which the new application model uses to discover if a targeted Deployment Type is present.
There are 5 ways to determine this:
- MSI Product Code
- File
- Folder
- Registry
- Custom Script
Note: Detection runs after a Application Deployment Evaluation policy refresh
#1 MSI Product Code - is pretty self explanatory, find the MSI product code and if it exists then it is present. Key here is getting the MSI product code. Thankfully when you create an new application it will detect and automatically provide this for you and generate a Deployment Type.
#2 File - is based upon a file (yes it that simple):
There are additional options in this section to either choose to have just the file or a rule to check for Date Modified, Date Created, Version or Size (in Bytes)
#3 is Folder and is very similar to the file item.
Note that the options change you now have only Date Modified and Date Created:
#4 is the Registry:
You can browse to a machine and select the appropriate key OR you can manually enter the information. Additional options are available. (equal, not equal, etc)
Note:
#1 through #4 can be joined together with And / Or for detection. If you select the next option #5, script, you lose the above and will have to move them to your script if desired.
#5 is scripting. This is where the fun can really begin for those applications that have complicated installations. Wait, we never see those right?
Script options are PowerShell, VBScript and JScript.
All of these Detection options can be found in the Deployment Type under the Application. There can multiple deployment types per application.
In the next parts I’ll cover Requirements, Supersedence, Dependency, Examples/Expected Behavior and end with Troubleshooting (thread chasing).
Go forth and deploy!