Creating Global Conditions for the Application Model in ConfigMgr 2012

Most of you have probably used the Application Model in ConfigMgr 2012 and above right about now. If you still haven’t made the switch to Applications instead of Packages, I urge to do so. Something that I see at customers and around the internet is the lack of usage with Global Conditions. What is a Global Condition you may ask? In the Application Model when you deploy a software, you have the option to specify certain requirements that will be evaluated to either a certain value or perhaps a boolean value locally on the client. These requirements are constructed by Global Conditions, which in fact is a rule that represents technical conditions. By default Microsoft has provided us with a set of Global Conditions that should suffice in most of the situations when deploying an Application. But sometimes you need to create your own rule to meet the deployment scenario requirements.


In order to illustrate how you can create your own Global Condition and use it as a requirement for an Application deployment, we first need to create it and specify what should be the criteria for the rule. Before we go ahead creating a Global Condition, it’s important to know that it will be evaluated locally on the client. If the requirements for an Application is not met, the deployment will not begin and the content will not be downloaded.
I’d urge you to think twice before you decide to create a Global Condition. Most of the times ConfigMgr already has something that might suite your needs. But when you need to create a Global Condition, there’s a really good documentation page on TechNet which I’ve used several times around. You’ll be able to find it at the following link:

How to Create Global Conditions in Configuration Manager


For this blog post, I’ve come up with a scenario where we’re gonna deploy an Application called 7-Zip 9.20 x64. We want to deploy this Application to devices running a 64-bit version of Windows. Instead of creating a collection containing only 64-bit devices, instead we’ll offload that compute to the clients instead. We do that by specify a certain requirement (Global Condition). For this we need to create a Global Condition called Operating System 64-bit.
This scenario could actually be solved by using existing Global Conditions, by selecting one called Operating System and choose all of the 64-bit entries it holds. But I think it’s to many clicks and it’s bound to fail at some point due to human errors.

Create a Global Condition

Let’s go ahead and create a Global Condition. In order to meet the requirements of the scenario we’ve set up, we need to decide on some ground rules. How do we want to determine the compliance state and how do we want to query for the information determining the compliance state? There are several options we could choose from, and what I tend to use most frequently is the WQL query method although it depends on what the scenario is. To determine what version of Windows is running on a device, I already know that there’s a WMI Class called Win32_ComputerSystem. In this class, there should be a single instance that has a property called SystemType. This property holds either two values depending on the Operating System architecture:

  • X86-based PC
  • X64-based PC

For our Global Condition to work, we need to construct a query that will get us the SystemType where it is equal to X64-based PC. To evaluate the compliance of this condition, we can use a string data type and check if it’s existential.
1. Open the ConfigMgr console and go to the Software Library node.
2. Expand Application Management.
3. Right-click on Global Conditions and select Create Global Condition.
4. In the windows that appears, configure accordingly:
Name: Operating System (64-bit)
Device type: Windows
Condition type: Setting
Setting type: WQL query
Data type: String
Namespace: root\cimv2
Class: Win32_ComputerSystem
Property: SystemType
WHERE clause: SystemType like ‘X64-based PC’
5. Click OK.
The Global Condition has now been created. Next step is to specify it under the requirements tab on an Application.

Using a Global Condition

In this scenario I’m deploying an Application called 7-Zip 9.20 x64. In order to use our Global Condition with this Application, we need to configure the Deployment Type settings.
1. Go to the Software Library, expand Application Management, choose Applications and select your application.
2. Go to the Deployment Types tab and select Properties on the desired Deployment Type.
3. Select the Requirements tab and click on Add.
4. In the Create Requirement window, configure accordingly:
Category: Custom
Condition: Operating System (64-bit)
Rule type: Existential
Radio button: The selected global condition must exist on client devices
5. Click OK and then OK once again on the Deployment Type Properties window.


Before you go ahead and deploy an Application where you’re using a custom Global Condition, it should be considered best practice to perform a simulation of the deployment and verify the results. Do do this, follow the instructions below:
1. Select your application, right click and select Simulate Deployment.
2. Select a collection to use for this simulation.
3. Click on Next and then Next once again until you can click Close on the Completion page.
We can now verify the results of the simulation once the clients have reported back their status messages. Once they’ve done so, hopefully it will look similar to this:


As you’ve seen in this post, you can create Global Conditions for usage with the Application Model based on your special business or technical conditions.


Nickolaj Andersen

Chief Technical Architect and Enterprise Mobility MVP since 2016. Nickolaj has been in the IT industry for the past 10 years specializing in Enterprise Mobility and Security, Windows devices and deployments including automation. Awarded as PowerShell Hero in 2015 by the community for his script and tools contributions. Creator of ConfigMgr Prerequisites Tool, ConfigMgr OSD FrontEnd, ConfigMgr WebService to name a few. Frequent speaker at conferences such as Microsoft Ignite, NIC Conference and IT/Dev Connections including nordic user groups.


  • I have a question about setting up a global condition to basically see if a certain piece of software is installed, provided it exists in the specified WMI class of course. The use of the condition would simply be to choose the “Installed Software” condition I create, and the criteria would be specifying if a string exists/is contained within any of the Name properties returned from that class (all installed software).
    It sounded extremely straightforward but I seem to be having a hard time getting it to work like I intended, and I think it has something to do with the provided operators and how they apply to multiple properties being returned rather than a single string.
    In essence, what I’ve tried thus far goes something like this:
    Name: Installed Software
    Device type: Windows
    Condition type: Setting
    Setting type: WQL query
    **Data type: String? or String ARRAY ??**
    Namespace: root\cimv2
    Class: Win32_InstalledWin32Program
    Property: Name
    WHERE clause: None, as I want every instance in the class to be returned and then check for a string within the app requirement, not filter for a specific piece of software in the WHERE clause within the condition itself.
    Obviously I could use a PowerShell script instead and do this in five seconds but I’m trying to use native functionality where I can to reduce complexity for my colleagues and this would be fairly elegant if I just got it working.
    Here’s an example:
    I am trying to set a requirement on an application an Outlook add-in that makes sure that Microsoft Office is installed. When I use the condition detailed above, I specify that the value(s?) must contain the string “Microsoft Office”. I’ve also tried the begins with operator as well and each time, it results in the requirements not being met when deployed, even though I can manually verify that an instance of Win32_InstalledWin32Program with the Name property containing “Microsoft Office” does in fact exist.
    I then realized that I’m not really getting a single string returned by the query in my case, but every Name property in the class, so I thought I needed to set the data type to “String array” but that didn’t seem to work either and I wasn’t really sure how the “contains” or “begins with” operator really handled an array of strings. Is this correct? Would the WQL query and the way SCCM handles it be returning a true array of strings for the Name properties, or some other object/data type that string operators won’t apply to? I looked through lots of CCM logs and couldn’t find anything detailed enough showing me that actual data returned and the comparison results. The AppEnforce log only showed that the deployment was NotApplicable until I removed the requirement.
    Obviously I could also just setup a condition for each specific piece of software and use a WHERE clause to filter that software name directly, then I could use “existential” in the requirement rather than comparing values, but it’s not very universal or efficient to do it this way if I can just create one condition that can be used many times with whatever string I want and I feel like this should be easily possible. Does anyone have any ideas? It would be much appreciated.
    Also, if you have a recommendation for a better WMI class (or detection method altogether) to use for software, I’m all ears. I don’t use Win32_Product because not only does it only show MSI-installed programs, but it’s extremely slow to query because it reconfigures and verifies the local package for every product installed each time it runs. Win32_InstalledWin32Program is pretty immediate to return a query and it includes quite a lot of non-MSI installed programs as well. I just prefer to use classes like these instead of a registry key or two as old keys can be left behind by a product that was removed and it not really be installed. It’s more likely to be accurate this way.

  • Hi,
    Nice article. I had the same “Invalid Class” result running a simulation.
    Corrected it by changing the where cluase to SystemType = “X64-based PC”

    • Hi Edward,
      Do you get that error when you follow this guide? Could you tell me how your Global Condition looks like so I can try to replicate it?

      • Hi Nickolaj,
        I’ve solved it. I’m using the same Global Condition but I’m leaving the WQL query Where clause empty.
        At the application I’m using a requirement which Equals the value. This works for me and I only need one Global Condition:).