Examining Windows 2003 Server Group Policy Enhancements, Part II
May 13, 2003
In the first article of this series, I presented new and enhanced features of Windows 2003 Group Policy Objects. However, Group Policy improvements introduced in the new operating-system platform are not limited to functionality covered by GPO entries -- they also include ability to apply them with much higher degree of granularity (via WMI Filters), easier design and troubleshooting (via Resultant Set of Policies), and better manageability (with Group Policy Management Console). The focus of this article will be use of WMI Filters.
WMI, the Windows Management Instrumentation, is a set of technologies for managing Windows0based environments. Its popularity, which increased drastically over the last few years, is best exemplified by the fact that starting with Windows 2000 WMI became an integral part of every operating system developed by Microsoft. WMI provides access to properties of practically every hardware and software object in the computing environment (such as a list of Windows Installer applications installed on a computer, free disk space on all its drives, amount of physical memory it has, maximum speed of its modem, profile settings of currently logged on user, and so on).
Before we take a closer look into how WMI can help us with Group Policy Object filtering, let's first discuss its implementation. Each of the software and hardware components manageable through WMI is represented by a class. For example, Win32_LogicalDisk class represents logical disks, Win32_PhysicalMemory class represents the computer's memory, and Win32_Share is a list of all file shares on a target computer. As you can imagine, the number of all available classes is enormous. In order to provide some kind of ordering, speed up searches, and prevent accidental name conflicts, classes are organized into a hierarchy of namespaces, starting at the one called root. The majority of the classes that Windows administrators deal with reside in the namespace called root/Cimv2.
The real-life representation of a class is its instance (also referred to as its object). For example, the Win32_LogicalDisk class can have multiple instances, each corresponding to a single logical disk on a computer. The size of a disk, amount of available space, its type, status, etc. are described using Win32_LogicalDisk class properties. There are different ways of extracting values of these properties. One of them, which you need to get familiar with in order to fully understand WMI Filtering, is called WMI Query Language (or WQL in short). WQL is similar to (although more limited than) Structured Query Language, used to query information stored in relational databases. For example, in order to determine how much free disk space is available on a local C: drive, you could query value of FreeSpace property of "C:" instance of the Win32_LogicalDisk class. This would take the following form:
SELECT FreeSpace FROM Win32_LogicalDisk WHERE DeviceID = "C:" AND Description = "Local Fixed Disk"
If you want to find out the computer name, service pack level, and location of the Windows directory of a target computer running Windows XP Professional, you can simply check the values of CSName, CSDVersion, and WindowsDirectory of Win32_OperatingSystem class instance with the Caption value of "Microsoft Windows XP Professional". You could do this by running the following query:
SELECT CSName, CSDVersion, WindowsDirectory FROM Win32_OperatingSystem WHERE Caption = "Microsoft Windows XP Professional"
Although these two examples are very simple, they should give you some idea about enormous capabilities of WMI. These capabilities can be used when determining the scope of Group Policy.
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:
Root\CimV2; 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.