To create a WMI filter for the GPO, right-click the WMI Filters node and select New to open the New WMI Filter dialog box. Name the filter, provide a description, and add your query, as Figure 3 shows. You can specify a namespace other than the default root\CIMv2 if you have specific needs, but for most situations, the classes in the default namespace are adequate. Also, you can add several WQL queries to one WMI filter; simply click Add and define the additional queries. Click Save.
Finally, link the WMI filter to your GPO by opening the WMI filter in GPMC and right-clicking in the white space under
GPOs that use this WMI filter. Click Add, then choose the target GPO. Figure 4 summarizes the results of these steps and shows a WMI filter named Dell Optiplex, which finds matches for all computer objects for which the Model property of the Win32_ComputerSystem class contains the word OptiPlex. The WMI filter is linked to the GPO named Run Dell Upgrade Software. GPMC presents the data in such a way that from one view you can determine that the Run Dell Upgrade Software GPO, applied at the domain level, will run only on Optiplex model computers.
What's in a Query?
Constructing the WQL query syntax is perhaps the trickiest task that you'll encounter when you begin working with WMI filters. Your system contains more than 200 WMI classes, but you'll likely use only a few of them for your WMI filters. The classes usually begin with the prefix Win32_, followed by a descriptive name such as ComputerSystem or OperatingSystem.
Microsoft's handy Scriptomatic tool, which you can download at http://www.microsoft.com/technet/community/scriptcenter/tools/wmimatic.mspx, lets you view all the WMI classes and their properties. You can run this small HTML Application (HTA) on a workstation to return the WMI classes, the properties for those classes, and their values for the computer you run it on. Class names and property names are key components of your WMI filter.
You'll want to test the WMI filter's fundamental WQL query before you use it in your filter. (The WQL query is what you enter in your WMI filter query field.) You can use a simple Windows Script Host (WSH)based WMI script, such as the one that Listing 1 shows, to validate your WQL query and ensure that your syntax is correct.
The crux of this script occurs in the code at callout A. This code sets the strWQL variable to a WQL query. The code then connects to the CIMv2 namespace of the local computer and uses the ExecQuery method to execute the query. The code in this example connects to localhost, but you can also specify the NetBIOS name, IP address, or fully qualified domain name (FQDN) to query a remote computer. The script stores the query results in the WMICollection object. The For Each statement at callout B iterates through the items in the WMICollection object and displays confirmation text when it finds a match.
The script should return a data set that contains all computers on which the Win32_ComputerSystem class's Model property contains the text OptiPlex. The actual Model value is OptiPlex GX260, but if you don't need to differentiate the OptiPlex models, you can use the wildcard character % before and after the string to provide a broader match, as the code at callout A shows.
Using GPMC to Test Your Filter
After you test your WQL query, you can use GPMC to test your WMI filter. GPMC includes two wizards: the Group Policy Modeling wizard and the Group Policy Results wizard. The modeling wizard lets you test a what-if situation in which you specify an object and scenario. The wizard then displays which GPOs will actually execute for that scenario. The wizard lets you specify a user and computer object or container, whether the computer is on a slow network connection, and on which site the object resides. You can also specify user or computer objects to model other than you or the computer on which you're running GPMC. Finally, you can specify the WMI filters whose query results you want to be true for this simulation. The model will apply specified WMI filters as if the specified query criteria were true. This tool is great for testing how several GPOs will be applied, but it doesn't let you test the syntax of the WMI filter.
You can use the Group Policy Results wizard to show the RSoP. You can specify a local or remote computer and user and view the RSoP for that combination. Although the modeling wizard presents a simulation, the results wizard returns the actual RSoP. The results will show the effects that a WMI filter has on evaluated GPO links for the specified computer and user combination. If you run the results wizard against a computer running Windows 2003 or XP, you can also view the effects of applying the WMI-filtered GPO, as Figure 5 shows. These sample results are for a user named Administrator on the DC3 computer in the solar.local domain.
Filters Add Flexibility to GPO Application
Group Policy is a powerful tool for centrally managing an enterprise of Windows computers. Windows 2003 and XP let you use WMI filters to control which GPO links are executed. Now, in addition to targeting a GPO to execute against an object according to the object's location (site, domain, or OU) or security group membership, you can use WMI filtering to hone a GPO's scope. Using WMI filters, you can execute a specific GPO based on computer properties such as OS, make and model, or free disk space. This flexibility extends the usefulness of Group Policy for centrally managing your AD environments. WMI filters are a welcome addition to every IT pro's arsenal of management tools.