Programming Microsoft Outlook and Microsoft Exchange 2003, Third Edition [Electronic resources] نسخه متنی

Windows Management Instrumentation

Besides using CDOEXM to manage your Exchange infrastructure, you can also use the WMI providers that ship with Exchange.

Exchange 2003 adds a large number of new classes and some additional capabilities to existing WMI classes (such as ExchangeLink). Table 18-9 lists the new classes. I won't cover all of them in detail—just the new classes that you are most likely to use in your applications.

Besides the Exchange WMI providers and classes, other providers and classes ship with other software products and Windows. Table 18-10 describes some of these other WMI providers.

Exchange WMI Classes

The Exchange WMI classes are well documented in the SDK, so I won't go into detail on each one. Instead, I'll show how to code to these classes from an application. I'll highlight some of the key properties for the classes. The SDK is included with the book's sample files, so you can browse through the details of each class there.

The Exchange WMI classes are located in the WMI namespace \\.\root\cimv2\Applications\Exchange. You can access WMI in two ways. If you are used to standard programming, the easiest way is to use CreateObject. The following code creates the WMI locator that allows you to connect to a local or remote WMI namespace. It then calls the ConnectServer method of the WMI locator and passes the name of the server and the namespace to connect to. Finally, the code uses the InstancesOf method to retrieve an instance of a couple of the Exchange classes.

strConnectServer = "thomriznt52"
Set objLocator = CreateObject("WbemScripting.SWbemLocator")
Set objService = objLocator.ConnectServer(strConnectServer, _
"root/cimv2/applications/exchange")
Set Clusters = objService.InstancesOf("ExchangeClusterResource")
Set ExchangeLinks = objService.InstancesOf("ExchangeLinks")
Set ExchangeServerState = objService.InstancesOf("ExchangeServerState")

The other way to get the WMI objects is the same way you retrieve ADSI objects—using the GetObject method. The following code accomplishes the same thing as the previous code:

Set Clusters = GetObject("winmgmts:{impersonationLevel=" _
& "impersonate}!/root/cimv2/applications/exchange" _
).InstancesOf("ExchangeClusterResource")
Set ExchangeLinks = GetObject("winmgmts:{impersonationLevel= " _
& "impersonate}!/root/cimv2/applications/exchange" _
).InstancesOf("ExchangeLinks")
Set ExchangeServerState = GetObject("winmgmts:{impersonationLevel=" _
& "impersonate}!/root/cimv2/applications/exchange" _
).InstancesOf("ExchangeServerState")

Notice that instead of using LDAP:// in the GetObject call, we use winmgmts: to specify WMI. No matter which method you use, the same classes are returned. I prefer using the winmgmts: method.

Once you get the classes, retrieving properties from the WMI classes is straightforward. First you have to determine the number of instances in the class if the class has multiple instances. (For example, Win32_Processor might have multiple instances if the machine has multiple processors.) To do this, you can use the count property on the class that is returned or you can use a For..Each loop to loop through each instance.

Once you have an instance, you can retrieve or set properties on that instance. To retrieve a property, you specify the property just as you would for any other type of object you program against. The following example displays information about your Exchange server by using the ExchangeServerState class:

strConnectServer = "thomriznt52"
Set objLocator = CreateObject("WbemScripting.SWbemLocator")
Set objService = objLocator.ConnectServer(strConnectServer, _
"root/cimv2/applications/exchange")
Set ExchangeServerState = objService.InstancesOf("ExchangeServerState")
For Each ExchangeServer In ExchangeServerState
MsgBox "Exchange Server Name: " & ExchangeServer.Name
MsgBox "Exchange Server State: " & ExchangeServer.ServerStateString
MsgBox "Exchange Server State: " & ExchangeServer.ServerStateString
MsgBox "Exchange Server CPU State: " & ExchangeServer.CPUStateString
MsgBox "Exchange Server Disks State: " & ExchangeServer.DisksStateString
MsgBox "Exchange Server Services State: " _
& ExchangeServer.ServicesStateString
Next

WMI Query Language (WQL)

WMI provides a SQL query language for querying WMI providers for specific criteria. Rather than having to write looping code, you can use this query language to search for information in WMI. WQL, as you can see in the following example, is similar to SQL. Also, you only need to call the ExecQuery method on WMI to execute your queries. I'll cover only data queries here, but you can also create event and schema queries in WMI. These types of queries allow you to look for specific system events or query on specific schemas in WMI. The following example finds out whether the services on the Exchange Server are OK:

Set oExServer = GetObject("winmgmts:{impersonationLevel=" _
& "impersonate}!/root/cimv2/applications/exchange" _
).ExecQuery("SELECT * FROM ExchangeServerState " _
& "WHERE ServicesState = 0 OR ServicesState =  2 " _
& "OR ServicesState = 3")

This is just a quick look at what you can do with Exchange Server and WMI; you should learn more about WMI in general on your own. WMI provides a universal way to access not only Exchange Server management information but also a host of Windows and other Microsoft product information. It is a general-use Application Programming Interface (API) that is very useful if you are writing programs to manage Windows-based servers. (See the WMI section in MSDN for more information.)

The Antivirus API

I want to mention the Antivirus API (AVAPI)—also called the Virus Scanning API (VS API)—so you know that it exists and that independent software vendors (ISVs) can write to it. I don't expect non-antivirus software vendors to write to this API—or even care about it. But as a developer, you can use the performance counters and logging that the API provides to display information in your applications about successful scans, number of quarantined messages, loading and unloading of vendor DLLs, and the number of detected viruses.