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.
IE 7
Firefox 2.0