CM: Deployment Requirements

I was recently asked about how to deploy a single application but with varying installation command line parameters, using Configuration Manager. Luckily we can do this fairly easily using the Requirements screen on your Application Deployment Type.

In this scenario we were installing a school classroom management program, and needed to provide a different string in the install command line depending upon what kind of PC it was going to - e.g. setup.exe /template=TEACHER or setup.exe /template=TECHNICIAN. The PCs were already organised by Organisational Unit in Active Directory so that was the obvious target. The other way we could have done this was to create multiple device collections in Config Manager, and then multiple applications, and deploy to each of them - but we wanted to keep all this within a single application.

The basic concept behind this is to create multiple deployment types within the single application, and optionally a fallback entry at the end if you want the software installing where none of the requirements have been met, perhaps with a generic template passed via command line.

In this example I've created a simple program which just drops a text file onto the C drive, with the content of the command line string, as proof of concept but this technique should work for most use cases - depending on device OU, registry setting values, or even CPU speed, RAM, Disk space. I've targeted device OU here, and split my VMs into two OUs - Azure and Garage (for Azure hosted VMs, and those running off a Hyper-V server in my garage).

So our first step within Configuration Manager is to create a new Application (under Software Library). Follow through the wizard in the usual way - via MSI or as in my example, it'll be manual install as it's an EXE. Work through the flow as normal until you get to Deployment Types.

Here you'll want to add one entry for whichever specific requirements you're trying to set - in my case I'll call this one "Test App Deployment - Azure" and fill out the install parameters appropriately. Make sure you click on the Requirements page and add your requirement - in my case I've gone for "Device OU is one of:" and picked the OU with my Azure test VMs.

I've expanded the Condition dropdown in the screenshot to show you what options there are - I think device OU is the most useful here for this kind of scenario. It's a shame you can't target a Config Manager device collection here.

Changing the Category drop-down, you can pick Device (as detailed above), User (which just lets you query whether they are on their primary device), or Custom, which will bring up the custom condition editor:

This will allow you to either leave the Condition type at "Setting" and create a condition based on a registry setting, or change it to "Expression" to get the expression builder, where you can add as many Device/User clauses as you like.

Once you've set that one up, you should be back at the Deployment Types screen, where you can create a copy the deployment type you just created - and then go in and edit the name, install parameters and requirements. So in my case, I clicked Copy, then renamed the copy from Azure to Garage, altered the install command line, and altered the OU targeted by the requirements.

You can also add a third entry with no requirements, if you need a fallback option where none of your requirements were met, but you want the software installing anwyay.

If for some reason you have clashing sets of requirements you can order by priority on this screen, and also in the Applications > Deployment Types tab once you've closed the wizard.

Finally, deploy the application to your target device collection(s) in the usual manner. You should find the relevent deployment type is run on each PC based on the requirements we set. Note that if you're testing this with OUs and you recently moved OUs about, the Config Manager client uses registry settings populated by gpupdate to determine the device's OU - so wait a bit, or run gpupdate on the clients first.

In my case with this proof of concept, I found that my program had dropped a file containing "Azure" into the Azure VMs and "Garage" into the Garage VMs.