Today's complex OSs—including Windows—perform many tasks at the same time and generate many events. System users trigger additional events. For instance, a user or an administrator might perform some system configuration changes, disconnect the power plug from the machine, or shut down the OS. Each of these actions triggers one or more events. From a management perspective, the ability to capture and audit these events has great potential value. For example, you might want to write a script that would notify you if someone makes a certain system configuration change. If you submit the appropriate Windows Management Instrumentation (WMI) Query Language (WQL) query, you can catch OS events.
Submitting Queries
To submit the WQL event queries that I present here, you can use any application that can consume WMI events. Microsoft .NET application developers can use the System.Management classes available from the Windows .NET Framework. Administrators with some scripting knowledge can use a simple WMI script. If you have no programming experience, you can use the wbemtest.exe tool that's included in any WMI-capable Windows version (Windows NT 4.0 and later). If your Windows infrastructure already has enterprise management software such as Microsoft Operations Manager (MOM) or HP OpenView in place, you can catch WMI events from this software as well.
For the purposes of this article, I use GenericEventAsyncConsumer.wsf, a script that I wrote expressly for the purpose of submitting WQL event queries. You can download GenericEventAsyncConsumer.wsf by going to http://www.winnetmag.com/windowsscripting, entering InstantDoc ID 42371, and clicking the 42371.zip hotlink. The command syntax you use to submit a WQL event query is
GenericEventAsyncConsumer.wsf
"WQL event query"
[/NameSpace:Value]
[/Machine:Value]
[/User:Value]
[/Password:Value]
where WQL event query is the string that represents the WQL event query. The other parameters are optional. The /NameSpace switch specifies the WMI namespace to which you want to submit the query. By default, the script connects to the root\cimv2 namespace. The /Machine switch specifies the system to which you want to connect. By default, the script connects locally. For a remote connection, you must specify values for the /Machine, /User, and /Password switches. You don't need administrative privileges when you submit a query locally, but WMI default security requires administrative privileges when you access WMI information remotely. For more information about how GenericEventAsyncConsumer.wsf submits an event query, see "Exchange 2000 SP2 WMI Updates," January 2003, InstantDoc ID 27211.
To use Wbemtest instead of a script to catch an event, select Run from the Start menu of a Windows Server 2003 or Windows XP computer and type
wbemtest.exe
Click Connect and specify the WMI namespace to which you want to connect in the dialog box that Figure 1 shows. To connect to the local machine, just change the default namespace root\default to root\cimv2. To connect to a remote machine, specify the Universal Naming Convention (UNC) path to the namespace—\\machinename\root\cimv2—and specify the user and password in the Credentials section of the same dialog box. Click Connect. After you've connected Wbemtest to the namespace, click Asynchronous, then click Notification Query. A box will open in which you can enter your WQL event query.
Events to Query
Now that you know how to submit queries to capture system events, you might wonder which events to capture. Windows 2003 WMI exposes more than 600 classes and 3000 properties supported by more than 80 providers (Windows 2000 has fewer classes and properties and only 30 providers). Obviously, I can't examine all these in one article. Therefore, I concentrate on the following typical events supported by the WMI event providers (i.e. specialized providers that Microsoft developed to handle system events):
- Clock events supported by the clock provider available in Windows 2003 and XP
- Power state events supported by the power management provider available in Windows 2003, XP, Win2K, and NT 4.0
- Shutdown and logoff notification events supported by the shutdown provider available in Windows 2003 and XP
- Configuration change notification events supported by the configuration change provider available in Windows 2003 and XP
- Disk volume modification events supported by the volume change provider available in Windows 2003 and XP
Catching Clock Events
Accessing time information in a system is useful for many purposes. For instance, an application might need to start another application at a fixed time each day or perform some operation at a fixed interval (e.g., a cleanup process that must run every hour). The application must be able to access the system time so that it can perform its tasks as scheduled.
Windows 2003 and XP include the Win32 clock provider, which lets you easily access the system time information through WMI. Microsoft implemented this provider as an instance provider and an event provider. As an instance provider, it provides WMI instances representing the time of the system. To do so, the provider supports three WMI classes located in the root\cimv2 namespace: the Win32_CurrentTime class, the Win32_LocalTime class, and the Win32_UTCTime class.
The Win32_CurrentTime class is the parent class (also called a super-class) of the Win32_LocalTime class and the Win32_UTCTime class, which means that Win32_CurrentTime is used as a template to create the two subclasses. All three classes are singleton classes, which means that only one instance of each class is available per system. This restriction makes sense because one OS instance can't have multiple times. The Win32_LocalTime class represents the system's local time. The Win32_UTCTime class returns Universal Time Coordinate (UTC) time, which corresponds with Greenwich Mean Time (GMT). More information about the time classes is available at http://msdn.microsoft.com/library/en-us/wmisdk/wmi/win32_currenttime.asp.
Previous
Register
