February 18, 2016

Windows Management Instrumentation (WMI) Filters give you the ability to create Group Policy Objects (GPOs) that have a dynamically determined scope based upon the target system's attributes. This can be extremely useful whenever you want to apply a policy to specific systems that share a common attribute, such as Operating System or Model type. Without using WMI Filters, you would likely need to add these systems to a Domain Group which the GPO is applied to, or manually add them into the GPO itself. This can save you precious time, and headaches, once you fully grasp its potential.

For this particular example, we will design a WMI Filter that will deploy a GPO to all Domain Computers, except for those that are Windows 8 / Server 2012 or newer. Since we will be using WMI queries, we will need to reference the Operating System Versions that Microsoft uses in order to ensure that the correct ones are included within our query. For this, I referenced the Operating System Version MSDN page. For easier reference, I have copied the OS Version table below.

Operating System
Version Number
Windows 10 10.0*
Windows Server 2016 Technical Preview 10.0*
Windows 8.1 6.3*
Windows Server 2012 R2 6.3*
Windows 8 6.2
Windows Server 2012 6.2
Windows 7 6.1
Windows Server 2008 R2 6.1
Windows Server 2008 6.0
Windows Vista 6.0
Windows Server 2003 R2 5.2
Windows Server 2003 5.2
Windows XP 64-Bit Edition 5.2
Windows XP 5.1
Windows 2000 5.0

Based off of this information, we can see that we will need to query for Operating Systems that are lower than, but not including, Version 6.2. Unfortunately, WMI does not treat these Version numbers as numerical values, but instead handles them as string values. This means that Version "10.0*" will be viewed as the string value of "1." That being the case, we cannot just do something along the lines of "Version < 6.2" for what we are wanting, as Version "10.0*" will be viewed as the string value of "1," which would be lower than "6.2." In order to build a WMI query that would work for our requirements, while working within WMI's number/string limitation, we can do something that would logically look like the following.

"Version < 6.2 & Version != 10*"

Now that we have a general idea of how the query used for the WMI Filter will be setup, we can move forward with actually creating it. In order to get started with creating this, you will need to launch the Group Policy Management MMC on your Active Directory server. From here, right-click on WMI Filters (near the bottom) and select "New" in order to start creating your filter.

Once you have a Name and Description for the WMI Filter, you can click "Add" in order to designate the WMI query that will be used for it. Using the logical query we came up with previously, we can convert it over to the syntax used by WMI. If you are familiar with using the WMIC command within Windows, then this might look a bit familiar. What we end up with is the following:

SELECT Version FROM Win32_OperatingSystem WHERE Version < '6.2%' AND NOT Version like "10%"

What this query does is check the Version information located under the Win32_OperatingSystem object, and selects anything that has a Version less than 6.2 and not 10. Within the query we also utilize the % symbol as a wildcard for the Version information. Once this has been entered within the WMI Filter, you should end up with something that looks like the following.

At this point, you can go ahead and save the WMI Filter that you have created. It should now show up under the WMI Filters item within the Group Policy Management utility.

With the WMI Filter having been created, you can now assign it to the corresponding Group Policy Object. In order to do this, you will need to select the GPO that you want to apply this WMI Filter to, and from there reference the Scope tab. Near the bottom should be a drop-down for WMI Filtering. Click the drop-down and select the filter that you have created.

You should now have your GPO successfully applying to system's based off of the WMI Filter. In this case, your GPO will be applying to all Domain Computers, except for those that are Windows 8 / Server 2012 or newer. In order to begin testing this, you will need to run a GPUpdate on your machines. This can easily be done via the following command, which may require the currently logged-in user to log off in order to take effect.

gpupdate /force

In order to test if the GPO is applying as expected, you should run this command on a system that it should be applied to (e.g. Windows 7) and on one that it should not be applied to (e.g. Windows 10). Once you have run the GPUpdate command on these systems, you can verify the GPO assignments by using the command GPResult. Since this command tends to generate quite a large output, it is sometimes best to pipe the output to a text file. This can easily be done via the following command, which will create a text file containing the results on the root of the system's C drive.

gpresult /v >> c:\GPResult.txt

If everything is applying correctly, you should see the following on your system that falls within the WMI Filter and therefore is to be excluded from the GPO. On your other system, however, you should see that the GPO is applying successfully.

Having followed these steps, you should now have a basic understanding of setting up WMI Filters with which you can apply Group Policy Objects to systems based off of their attributes. There are many different possibilities available for deploying your GPOs other than just by Operating System Versions. For example, you can deploy GPOs based off of whether the system is a Virtual Machine or not, the time zone that the system is within, the name of the system (e.g. system names beginning with "Finance"), and many more. No matter what type of dynamic filtering you want to take advantage of, they are all setup relatively the same way. In the event that you decide to try to build out your own WMI query, there is a fairly decent tool called the WMI Filter Validation Utility that is provided as freeware by SDM Software. I tested this utility out during the setup of my WMI Filter, and it seems to do a good job of helping you test out how your filter will function.


Post a Comment

Subscribe to RSS Feed Follow me on Twitter!