ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
As you know, settings in a Group Policy object apply essentially to all users and computers (but not groups — which makes this term another confusing Microsoft misnomer) residing in a site, domain, or organizational unit where the Group Policy object is linked. In Windows 2000, the only way to work around this limitation was to use Group Policy filtering based on group membership. This was done by selectively assigning allow or deny Read and Apply Policy permissions for individual Group Policy objects to domain groups. If a domain group was denied these permissions for a specific GPO, then its members (users or computers) were not subjected to its settings. On the other hand, if the permissions were set to Allow, then GPO settings were applied to group members.
In Windows 2003, you can use WMI Filters in addition to group filtering. WMI filters contain the WQL based queries, which are evaluated dynamically at the computer startup or user logon, and depending on their outcome, allow or disallow the GPO settings to be applied. As you can imagine, the number of possibile conditions is huge, since you can test value of any property available via WMI.
WMI filters consist of two parts, separated by a semicolon. The first one is the namespace where the class, whose objects you will query, resides. The second part is the WQL-based query which results will determine whether a particular GPO will be applied or not.
WMI filter is a property of the Group Policy Object — and as such it applies only to that single GPO (note also that only a single WMI Filter can be assigned to a GPO). You can access filters from the same interface from which you access Group Policy Objects (which was described in the first article of this series) either by using Active Directory Users and Computers, Microsoft Management Console with Group Policy Editor snap-in, or via Group Policy Management Console, which is a separate download from the Microsoft Web site.
With the first two methods, you need to first locate the Group Policy Object for which you want to configure a WMI filter. This is typically done by finding an Active Directory container to which this GPO is linked. Once you found it, bring up its Properties dialog box. In Windows 2003 domain, this dialog box will have a new tab called WMI Filter. Clicking on the Browse/Manage… button displays the Manage WMI Filters dialog box, from which you can add, edit, delete, import (from specially formatted MOF files), or export WMI filters. Adding a new WQL query will also automatically check its syntactical correctness. Once the filter is created, it can be used for any number of Group Policy Objects.
When dealing with Group Policy Management Console, WMI filters can be created or imported in an appropriately labeled folder. After they are created, you can link any one of them to any of the existing Group Policy Objects. Since I will review the Group Policy Management Console in a separate article, we will describe here the first method.
Let’s imagine that you want to deploy a new software package, but only providing that a specific hotfix has been installed on targeted computers. Your task is to create a WMI filter that will allow to determine presence of that hotfix (which, in turn, would trigger the new software deployment via group policy). Information about installed hotfixes can be extracted by querying Win32_QuickFixEngineering class. Your filter would have the following format:
RootCimV2; SELECT * FROM Win32_QuickFixEngineering WHERE HotfixID = "Q810565"
Note that despite the fact that WMI filters increase flexibility in controlling scope of GPO targets, there are still some significant limitations. For example, current implementation of WQL does not allow joins, which means that is not possible to determine within the same query property values of two (or more) WMI objects from different classes. For example, you could not check within the same query the operating system version (property of Win32_OperatingSystem class) and amount of free disk space (property of Win32_LogicalDisk class).
Additional challenge is finding the property you are looking for among large number of available WMI classes. You can simplify your task by installing WMI Administrative Tools. One of them — CIM Studio — provides a familiar Internet Explorer-based interface for allowing browsing and searches among WMI properties and classes.
