| Downloads |
|---|
| 44066.zip |
Many Windows IT pros rely on Active Directory (AD) Group Policy to centrally manage the technical behavior and rights of their Windows 2000 Server and later infrastructures. Some use the default Group Policy settings to enforce password policies, lock workstations after a certain period of inactivity, and customize user desktops. Some recent applications, such as Microsoft Software Update Services (SUS) and Windows XP Service Pack 2 (SP2) Windows Firewall, include Group Policy administrative templates that further leverage this centralized policy framework.
Most IT pros are familiar with the two most common methods for applying Group Policy: directly on the container (e.g., site, domain, organizational unit—OU, local object) and indirectly through security permission restrictions. In Windows Server 2003, Microsoft added Windows Management Instrumentation (WMI) filtering capabilities to let you further hone the scope of a Group Policy Object (GPO). WMI filters let you apply a GPO to only certain members of a container, according to whether the member satisfies the criteria that the filter specifies. For example, you can use WMI filters to target a Windows Installer package to client computers that have specific hardware configurations or a minimum amount of RAM and disk space on a particular drive. To take advantage of this filtering functionality, you need to know a bit about WMI.
WMI Architecture
WMI is the Microsoft implementation of Web-Based Enterprise Management (WBEM) technology, which defines a cross-platform standard and framework for managing systems. Microsoft exposes WMI providers that permit programs to query details about a particular system. You'll likely be interested primarily in properties such as the amount of memory or manufacturer of a computer system. A WMI property (e.g., manufacturer) is associated with a WMI class (e.g., Win32_ComputerSystem). This class is a member of a namespace (e.g., root\CIMv2). To learn more about WMI, read the Windows IT Pro article "Scripting with WMI," May 2003, InstantDoc ID 38498.
If you run a Windows 2003 domain, you can use WMI Query Language (WQL) result sets to target Group Policy to specific computers. Note that only target computers that run Windows 2003 or XP support WMI filtering. Earlier systems will simply ignore the filter.
Let's look at a simple example before we delve further into WMI filtering. Let's say you want to create a GPO that automatically installs software updates on all employee workstations that run XP Professional Edition but doesn't install the updates on computers that run Windows 2003. You've organized your computers into various OUs that are based on function and location, and you don't want to reorganize them into OUs that are based on whether to apply the updates. WMI filters provide a handy solution. Here are the basic steps for using WMI filters in this situation. I discuss the details later.
1.Create a new GPO that defines how you want to apply software updates (e.g., via SUS).
2.Link this GPO at a level high enough to affect all OUs that contain computers. (Note: Never create a WMI filter on your Default Domain GPO. All computers in your domain must be able to access the Default Domain GPO without restriction.)
3.Create a WMI filter that uses WQL to query a computer's OS version. The WQL syntax will look similar to the following:
SELECT * FROM Win32_OperatingSystem WHERE Caption LIKE "%Windows XP Professional%"
4.Link the WMI filter to your newly created GPO, and you're off and running.
Be careful how you use WMI filtering. If you misconfigure WMI filtering or apply it ad hoc, your Group Policy architecture can become cumbersome, confusing, and ultimately less effective. For example, applying specific GPOs directly to OUs that contain target computers is more effective than applying several GPOs at a higher level, then using WMI filters to prevent these GPOs from running on specific computers. However, the extra level of targeting granularity that WMI filters provide can help you apply GPOs to certain classes of users or computers for which OU organization isn't practical.
Setting Up Your Test Bench
WMI filtering hones the scope of a specific GPO based on the results of a WQL query, so you'll want to test and refine your query to be sure it returns the proper results. This testing also will help you determine whether a GPO doesn't get applied to a computer because of an error in your WMI query syntax or because the computer doesn't satisfy the query conditions.
You can use a simple test environment that consists of an isolated OU with its own GPO and one test computer object within the OU. Use the GPO to enable something that you can easily test (e.g., setting the desktop wallpaper). In many cases, you can simply log on to the computer and witness the change (i.e., the wallpaper change in this example). In other cases, you'll need to use a tool such as the Microsoft Management Console (MMC) Resultant Set of Policy (RSoP) for Users and Computers snap-in to confirm that the GPO executes for your test computer. After you determine that the GPO executes correctly, disable the GPO and run gpupdate.exe from a command line to force a user and computer GPO refresh. (On Windows 2003 and XP systems, the Gpupdate tool replaces Secedit for refreshing both computer and user Group Policy.) Repeat the test to confirm that the GPO doesn't execute. After you're satisfied that GPO execution is working properly, you can introduce WMI filters and know that any failure to execute a GPO is a result of the filter.
Accessing WMI Filtering Options
Group Policy WMI filtering works only with a Windows 2003 domain and Windows 2003 or XP member servers. If you use an XP computer to manage your Group Policy, you'll need to install the Windows 2003 adminpak.msi file, which you can download from http://www.microsoft.com/downloads/details.aspx?familyid=c16ae515-c8f4-47ef-a1e4-a8dcbacff8e3&displaylang=en. The adminpak installs additional domain administration tools, such as the MMC Active Directory Users and Computers snap-in. Microsoft has also released Group Policy Management Console (GPMC), which you can download from http://www.microsoft.com/grouppolicy. These tools provide an ideal way to access the Group Policy WMI filtering options as well as methods to test your WMI queries and filters.
WMI Filtering Through Active Directory Users and Computers
First, let's explore the WMI filtering options available from the Active Directory Users and Computers snap-in. Launch the snap-in, navigate to the desired OU (or other object that has the policy you want to edit), right-click the object, and select Properties. Go to the Group Policy tab and select the GPO links to which you want to apply the WMI filter. Click the Properties button to open the properties for that policy. Next, click the WMI Filter tab, and either select or create a WMI filter. To create a new WMI filter, follow these steps:
1.Select the This filter radio button and click Browse/Manage to show the Manage WMI Filters dialog box.
2.Click the Advanced button to expand the dialog box, which Figure 1 shows. You can manage all your WMI filters from this dialog box and later apply them to any GPO.
3.To create a new filter, click New.
Complete the Edit Filter section by filling in the Name, Description, and Queries fields.
4.Click Save.
After you create your WMI filter and link it to a policy, you'll need to test it. Ensure that the filter targets a computer in an OU or other container within the GPO's scope. If your filter is complex, testing and correcting the WMI filter will likely be an iterative process. After each change you make to a GPO, be sure to run the Gpupdate command from your client computer to force a user and computer GPO refresh; otherwise, you won't capture the recent changes until the next automatic GPO refresh.
You can use the Gpresult command-line tool to test whether a WMI filter activates and prevents the GPO from running on the target computer. Run Gpresult and specify either a local or remote system. Figure 2 presents Gpresult output showing that a WMI filter named Dell Optiplex successfully blocked execution of a GPO named Run Dell Upgrade Software. Gpresult provides a quick view of which GPOs have been applied. To see the results of applying each of your GPOs, run the MMC RSoP tool. Note, however, that although this tool tells you which GPO settings have been applied, it doesn't tell you which GPO link caused which changes nor which WMI filter might have come into play.
WMI Filtering Through GPMC
The most flexible tool for managing your WMI filters is GPMC. This tool requires the Windows .NET Framework to run, and it provides centralized Group Policy management across forests, domains, OUs, and sites. The .NET Framework is automatically installed on every Windows 2003 computer, and XP machines can download the tool from the Windows Update service.
GPMC stores all your WMI filters in one location called, appropriately, WMI Filters. The process for creating and editing filters via GPMC is similar to the process I described for creating filters through the Active Directory Users and Computers snap-in. Launch GPMC and expand the Forest branch. Select the domain or OU to which you want to apply the WMI-filtered GPO. Next, create a new GPO if one doesn't already exist.
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.
