Windows Management Instrumentation (WMI) Filtering

WMI, or as it’s known by its longer name “Windows Management Instrumentation”, is a technology that has been around since the Windows NT 4.0 days. WMI provides an easy way for you to probe all sorts of data from your computer. You can determine what software is installed, what operating system (exactly) you have, and a lot of other useful things.

Why is this important to you when it comes to Group Policy? WMI provides a way for you to filter Group Policy Objects based on the result of a WMI query. Where might this come in handy? It can help you custom target your GPOs so the right GPOs apply within just the right conditions.

Where are the ideal ways in which to target GPOs?

• Applying GPOs just to laptops
• Applying GPOs only to a specific version of Windows.
• Applying GPOs just where a specific service is installed

There are a couple of ways to accomplish this task. You could create separate OUs for each of these scenarios. But these OUs would be mutually exclusive and impossible to design for.

This is why WMI filters can come in handy. Let’s look at creating a GPO that will only apply to our Windows 10 clients.

Let’s say you are in the process of migrating a Windows 7 environment to Windows 10. You have a brand new Windows Server Update Services (WSUS) server that you don’t want to clutter up with Windows 7 updates. You only want the Windows 10 clients to use the new WSUS server. WMI can help.

Create a filter for just Windows 10

Open the Group Policy Management Editor and select the WMI Filters node.

You will want to name it and give it a description and click add to enter the query. Hit Ok, then Save.

Let’s look at the query itself. You want to leave the root\CIMv2 namespace. CIMv2 is the default namespace; it contains the most common and useful classes that you would want to query. [[Define what is meant here by root namespace and why I want to leave it. -jm]]

Here’s the final query you can use to target Windows 10 (any version) but specifically client versions, and not Windows Server versions. (More on this in a second.)

Select * from Win32_OperatingSystem where Version like “10.%” and ProductType=”1”

Here’s the breakdown of the query:

• Select * returns information from your selected provider and all of its subclasses.
• Win32_OperatingSystem is the WMI provider used to grab the information. You are matching the Windows Version, in this case, 10.%.
• The special % character means character match (so any subversion of the main version 10 are caught.)
• product type we specify “1” because you only want client versions. As Windows Server 2016 would also return version 10

So now that the WMI query has been created, let’s see it in action.

On a Windows 7 PC the policy currently applies:

Check with GPResult /r

Now apply the WMI filter. Do this from the menu under the security filtering pane. Select the WMI filter you just created.

After selecting this WMI Filter, the GPO will only apply to the computers that return true.
Back to the Windows 7 machine after applying the WMI Filter:

The GPO is now filtered from applying to the Windows 7 machine.

If WMI filters are so great, then what is the downside? There are several issues:

• WMI filtering is per GPO. The trouble is if you need to filter many settings with different filters, you would need a separate GPO for each setting.
• The other thing to be aware of is that WMI Filtering is done client-side. Poor WMI queries can lead to long login times. Wait times can be particularly true for queries using Win32_Product, as it will list and validate every installed installation package.

If you want to measure your WMI query times you can use PowerShell on an example machine.
The structure of the command you want to try out in this would be something like this:

measure-Command {Get-WmiObject -query 'Select * from Win32_OperatingSystem where Version like "10.%" and ProductType="1"'} | Select Seconds, Milliseconds

The output can be seen here. In this case, the query wasn’t ever longer than a second and ranged between 98 to 115 milliseconds.

Note that the time to execute a WMI query can vary from machine to machine, and even vary upon each evaluation. You can see this in the above screenshot with some variation in the results being returned.

Some queries are fast, and others are really slow. Here’s a test example looking for iTunes on a machine.

measure-Command {Get-WmiObject -query 'Select * from Win32_Product where Name like "iTunes"'} | Select Milliseconds, seconds

You can see the runs vary between 10 and 25 seconds!

So, WMI queries have their place, but let’s switch gears and talk about another targeting mechanism, Group Policy Preferences, and Item Level Targeting.

Group Policy Preferences and Item Level Targeting

Starting with Windows Server 2008 and Windows Vista Microsoft included Group Policy Preferences (GPP) and Item Level Targeting(ILT). What are they and why should you care?

While standard Administrative Templates cover many settings you as an admin might want to use to control your environment, they don’t cover everything that you might need in your environment.

That is where Group Policy Preferences and Item Level Targeting come into play.

Group Policy Preferences has lots of well-known uses: Drivemaps, shortcuts, power settings and a lot more.

But inside Group Policy Preferences is a superpower where each item can be targeted based upon easy-to-understand criteria. In this example, let’s create a Group Policy Preferences shortcut item and use Item Level Targeting to get it just to the right place.

Now, how do we make sure that only people that need them get the correct shortcut? That is where Item Level Targeting comes in.

Under the common tab, you will check the Item Level Targeting box and hit the targeting button to open the targeting editor. The targeting button will bring up the targeting editor. The targeting editor will give you a wide variety of options to filter your Group Policy Preference by.

In this case, we only want our Finance group to get the finance shortcut and when we see iTunes on the machine.

So we will target by the security group and also an MSI query

Now add the second item you wish to filter by:

Select AND because both should be true and select the iTunes product.
Combined, your group selection and MSI query and settings will look like this:

Not only is this method completely graphical and easy to understand, it’s also super fast. Item Level Targeting doesn’t use WMI filters to do its evaluations; instead it uses API calls, so it’s up to 10 times faster.

The average evaluation time for any ILT is around 30ms a piece on average. So in our example, with a group and MSI query, on average you could expect to use about only 60ms total for the combined query.

You can see the inner logging for Group Policy Preferences with an ILT on Group and ILT on File. The whole thing took 15ms! Wow! Lightning fast!

This is a lot better than the 120ms or very very long multi-second queries you might get from WMI filters. Remember: one query above took 25 seconds for WMI to process. Ouch !

So, what is the upshot? You can define multiple settings or preferences in one GPO. All department shortcuts can be in one GPO thanks to Item Level Targeting. Item level targeting offers a wide variety of variable that you can apply or filter your Group Policy Preferences.

What a super powerful tool, right? So what’s the downside? Not much, actually.

But there is a hitch: out of the box, Item Level Targeting is only available for Group Policy Preferences. While Administrative Templates get left to traditional security filtering, separate OU linking, or WMI Filtering. Until Now…

PolicyPak Administrative Template Manager

The PolicyPak Administrative Templates Manager brings the ease and simplicity of Item Level targeting to the Administrative Templates.

Let’s look at the WSUS GPO that you wanted to filter to only Windows 10 clients. Instead of adding the WMI filter on the whole GPO all you need to do is use the PolicyPak Admin Template Manager to Item Level target the machines you want.

Create your Update GPO, linked to your computer root. Then select the Admin Templates Manager. Add a collection and select the Level Targeting.

Here you can select Windows 10 and use ILT to do it.

You can now define your WSUS settings with ease, knowing it’s going to hit just the machines you want.

Then you can make a new PolicyPak Collection in the same GPO (and NOT another whole new GPO), say, for Servers. And in that Collection, specify that the settings will affect only the machine types of servers.

Basically, now for every Microsoft setting inside your ADMX store, you can perform granular Item Level Targeting upon each one. This enables you to get the best of all worlds: fewer GPOs, and ILTs placed upon them (instead of multiple GPOs and using the slower and more complex WMI filters.)

Final Thoughts

PolicyPak and Administrative Templates manager brings the granular filtering capabilities of Item Level Targeting to Administrative Templates.

You can say goodbye to WMI filters which are difficult to create, and take a potentially long time to run.

When you use PolicyPak Admin Templates Manager, you get to have fewer GPOs, OUs, and security delegations and helping to bring a cleaner, simplified environment.

See some videos to check out PolicyPak Admin Templates Manager and reducing GPOs with ILTs by visiting https://www.policypak.com/components/admin-template-manager/.

If you’re looking to get started with PolicyPak, and get out of the WMI filter business, and literally have less GPOs, then sign up for our webinar at www.PolicyPak.com/webinar to get started with your free trial today.