The WMI namespace at \root\cimv2\applications\exchange defines the five classes. Management applications access Exchange 2000 data through the classes rather than through the providers. Each class covers a particular part of Exchange 2000 and uses the same set of standard APIs that Exchange 2000 uses. For example, the ExchangeRoutingTable provider runs on top of the Routing API and creates the ExchangeServerState and ExchangeConnectorState classes. (Exchange 2000 uses the Routing API to control how the new SMTP-based routing engine processes messages.) The ExchangeQueue provider runs on top of the Queue API, which spans both the Message Transfer Agent (MTA) and SMTP routing engine and which creates the ExchangeLink and ExchangeQueue classes. (After the SMTP routing engine decides how to most effectively route a message, the routing engine places the message into a queue. The Queue API provides Exchange 2000 with an interface to such queues.) The ExchangeCluster provider runs on top of the Cluster API and creates the ExchangeClusterResource class. (As you might imagine, this interface is available only when Exchange 2000 is running on a Win2K cluster.)
As an example of the available data in the Exchange 2000 WMI classes, Table 1 lists the ExchangeConnectorState class's properties. Notice how straightforward these properties are. You can easily associate each property with the information that it provides. ESM displays this information when you view the status of all known connectors.
WSH and similar tools use the classes to automate operations. For example, the following snippet of code returns a list of each Exchange Server machine in the collection known to the local system, as well as the Exchange Server version on each machine. The code connects to the local Exchange Server machine, specifies the Exchange Server part of the WMI namespace, then uses the ExchangeServerState class to report the information.
Const ComputerName = "LocalHost"
Const WMINameSpace = "root/cimv2/
applications/exchange"
Const WMIInstance = "Exchange
ServerState"
Set ExchangeList = GetObject
("winmgts:{impersonationLevel=
impersonate}!//" & - Computer
Name & "/" & - WMINameSpace)
.InstancesOf (WMIInstance)
For each ExchangeServer in
ExchangeList Wscript.Echo
"Name: " & ExchangeServer.Name
Wscript.Echo "Version: " &
ExchangeServer.Version
Next
The Exchange 2000 software development kit (SDK) provides full details of the providers and classes and how your programs can exploit them.
Combine and Conquer: CDOEXM
Together with ADSI, OLE DB, ADO, and CDO, CDOEXM completes the lineup of interfaces that you need if you want to have complete programmable access to Exchange 2000 data structures. These interfaces perform the following functions:
- ADSI—You can use this interface to manipulate AD objects, including user accounts and groups.
- CDO—You can use this interface to manipulate complex Exchange Server objects, such as messages and attachments.
- OLE DB—You can use this interface to navigate within the Exchange Server Store through languages such as C++.
- ADO—You can use this interface to navigate within the Exchange Server Store through automation languages.
- CDOEXM—You can use this interface to manipulate Exchange Server objects, such as mailbox and public stores.
No one interface spans every aspect of Exchange Server. All the interfaces work together, but you probably need to combine calls from several interfaces to accomplish most tasks. For example, to create a new user and allocate a mailbox to the user, you need to first use ADSI to create a new object, then use CDOEXM to create the mailbox. You'll probably find that CDO's CDO.Person object and ADSI's ADSUser, ADSContact, and ADSGroup objects are the key building blocks for code that deals with Exchange Server user operations.
CDOEXM also enables programmable access to mailboxes, public folders (including top-level hierarchies), servers, and storage groups (SGs). The idea behind this capacity is that you can create management tools if you don't like the utilities that Microsoft provides. Independent software vendors (ISVs) are likely to use this interface to build extensions. For example, CDOEXM exposes the ExchangeServer object, which you can use to interrogate a selected server's properties. Table 2 lists these properties.
Not surprisingly, ExchangeServer is the most straightforward of the CDOEXM objects. This object acts as the starting point for many other operations. For example, you can use the ExchangeServer.StorageGroups object to retrieve a list of SGs. You can then use that list as input to the StorageGroups object, which reveals a set of properties that you can use to change settings such as circular logging or the path that an SG uses to access the transaction logs. Clearly, code that uses these interfaces can wreak havoc on a production server, so you should fully test code before you use it. You probably won't get much sympathy from users if code that you wrote hinders their ability to work. (You'll probably get the same amount of sympathy that you afford Microsoft when you discover one of its bugs.)
The possibilities of combining CDOEXM, WMI, ADO, CDO, and other components to create management and reporting utilities for Exchange 2000 deserve a much greater in-depth discussion than is possible in this article. (See the sidebar "Dig Deeper" for several sources of information about how to use the new programming interfaces.) I recommend that you gather as much documentation and sample code as possible, do a lot of reading, and experiment by writing code and debugging the code on test servers before you go anywhere near a production server—unless, of course, you enjoy living dangerously.
Take Your Time
Now that Microsoft provides suitably documented interfaces, the task of monitoring and managing Exchange Server is much easier than before. But don't expect to immediately start writing programs that use the Exchange 2000 WMI providers and CDOEXM. First, take the time to fully explore standard management tools. For most of us, Exchange 2000's dramatic strides in supporting standard management-data interfaces are interesting but not essential. After all, only a few people in the Exchange Server community write code. The rest of us look on with interest and benefit from those people's work. However, you need to know that these interfaces exist and what they do, if only to ensure that your third-party management utilities support the interfaces.