WMI Filters have been available as a mechanism for filtering the effects of Group Policy Objects (GPOs) since Server 2003 & XP shipped. They are a valuable tool in your Group Policy Management arsenal. As the name implies, WMI filters allow you to filter the effects of a GPO based on queries that execute against the WMI repository on a given client machine (server or workstation). A WMI filter needs to be expressed in terms of a WMI Query Language (WQL) query, which is a subset of SQL. This usually takes the form of a query that looks like this: “Select * from <WMI Class> WHERE <Property> = <Value>”.

The key is that the query has to evaluate to either true or false when evaluated by the client system. This limits what you can do with WMI Filters, within the universe of all the things that are supported in WMI. For example, you cannot query for the presence of a particular registry value because of the way WMI exposes these, by default.  The query itself executes at the time that GP is processed by the client. This is an important point because some WMI queries can be expensive, from a processing perspective (check out our WMI Filter Test utility as a way of seeing how a proposed WMI filter will perform) and can elongate GP processing time, if you’re not careful with the query you choose.

Another point to note is that, unlike security group filtering, which is specific to per-computer or per-user settings (e.g. you need to use a user security group to filter per-user settings, etc.) a WMI filter that evaluates against “per-user” WMI criteria (e.g. who is logged into a system currently) can be used for per-computer settings or per-user settings. This is a subtle and sometimes confusing point, but important to remember.

Now let’s talk about how WMI Filters are stored and attached to GPOs.

 WMI Filter Structure and Linking

WMI Filters themselves are stored within AD.  Specifically, they are stored under the CN=SOM, CN=WMIPolicy,CN=System container within the domain naming context of a given domain, as shown in Figure 1 below

WMI Filter storage in AD

What you’ll notice in the image above, is a number of GUID-Named folders which have an object class of msWMI-Som. These are the actual WMI filters defined within the domain. The attributes on these objects contain the various aspects of the WMI filter, as shown in Figure 2 below:

Figure 2: Viewing the attributes on a WMI Filter

As you can see, the msWMI-Parm2 attribute holds the actual WQL query that was defined for this WMI filter, along with some other metadata, as well as the name and description of the filter. Once a WMI filter is defined, the next step is linking it to a GPO. A given GPO can have only one WMI filter linked to it at a time. This linking happens by modifying an attribute on the GPO object within AD. You might know, if you’ve followed previous postings of mine, that these objects exist under the CN=Policies, CN=System container within the domain naming context of a given AD domain and are of objectClass groupPolicyContainer. When you link a WMI filter to a GPO, you are actually modifying the gPCWQLFilter attribute on the GPC object in AD, as shown in Figure 3 below:

Figure 3: Viewing the attribute that stores a WMI Filter Link

So, now we know where WMI filters stored, and how they are linked to GPOs. Now let’s look at how you can automate management of WMI filters with PowerShell.

Automating WMI Filter Management with PowerShell

Let’s start off by figuring out what is available as far as PowerShell support of WMI Filters. Unfortunately, the GroupPolicy PowerShell module that Microsoft shipped in Win7/Server2008-R2 did not include any suppor for managing WMI filters. The good news is that there is some help. Our SDM Software freeware GPMC cmdlets (www.sdmsoftware.com/freeware) include 3 cmdlets that provide some PowerShell support, including:

Get-SDMWMIFilter, Add-SDMWMIFilterLink and Remove-SDMWMIFilterLink

Get-SDMWMIFilter retrieves information about a specific WMI filter (or all of them at once). Add- and Remove- SDMWMIFilterLink, as the name implies, lets you add or remove a particular WMI filter from a GPO.

The only thing that is currently not supported in the SDM cmdlets is the ability to create WMI filters using PowerShell. One reason for this is that the GPMC APIs actually don’t provide an interface for this task (a curious omission). But fortunately, there is some precedent for doing this and armed with the information above about how WMI filters are stored in AD, it is possible to script this as well. The following TechNet article does a pretty good job of providing a template for this:

http://gallery.technet.microsoft.com/scriptcenter/f1491111-9f5d-4c83-b436-537eca9e8d94

Armed with all this information, hopefully you have a better sense of how to take full advantage of WMI filters and what’s going on behind the scenes when you do!

Darren