In "Managing Exchange 2000, Part 1," February 2001, and "Managing Exchange 2000, Part 2," March 2001, I reviewed how Microsoft Exchange 2000 Server leverages Microsoft Management Console (MMC), how Exchange 2000 interacts with Windows 2000 Active Directory (AD), and how Exchange 2000 retrieves and provides monitoring and status information. All this functionality depends on a set of programming interfaces. In the past, Microsoft generally kept the details of such interfaces to itself and left you to work with whatever management tools the company delivered. Now, Microsoft has turned 180 degrees and built Exchange 2000 around a documented set of interfaces. If you don't like the standard management consoles that come with Exchange 2000, you can build programs to manage Exchange 2000 the way you want. Although this capability might not be important to small systems, large deployments will welcome the extra flexibility with which they can better integrate Exchange Server into their administrative frameworks.
This final article in the series details two crucial interfaces: Windows Management Instrumentation (WMI) and Collaboration Data Objects for Exchange Management (CDOEXM). I also take a quick look at the data in the System log and at how administrators and systems management products can use that data.
Forging Ahead with New Interfaces
The Exchange Server 5.5 administration program supports a minimal set of command-line interfaces that you can use to import and export directory information. You can use Directory API (DAPI) and Messaging API (MAPI) to programmatically manipulate the objects in the Exchange Server directory, and developers can use the Microsoft Exchange Development Kit (EDK) to create connectors to fax systems and messaging systems such as Lotus Notes. These powerful interfaces are effective, but they have a steep learning curve.
Exchange 2000 provides interfaces to support programming languages (e.g., Visual Basic—VB) and scripting languages (e.g., VBScript) as well as Web-browser access to management data. These interfaces include a set of COM-based management objects that work with the WMI model and a new set of interfaces—known as CDOEXM—that simplify management-task programming.
Active Directory Service Interfaces (ADSI), OLE DB, and WMI provide the foundation for the Exchange 2000 management architecture. ADSI enables access to AD so that Exchange 2000 can interact with users, contacts, groups, and other objects in AD. OLE DB provides a route into the Store. WMI delivers a set of interfaces to other applications and basic system components, such as hardware devices.
CDOEXM's name link to Collaboration Data Objects (CDO) is intentional. Before Exchange 2000, CDO simplified the process of programming objects such as Exchange Server mailboxes and messages. In Exchange 2000, programmers can manipulate complex management objects through CDOEXM—for example, to deal with mailbox stores and their properties. The net effect is that programmers can build custom-made or commercial products to manage Exchange 2000, or they can integrate Exchange 2000 into existing management tools.
The decision to use these features remains in your hands. On the one hand, management in Exchange 2000 is much more complex than in Exchange Server 5.5. On the other hand, the new management architecture can be as simple as you want it to be. If you manage one server that hosts a small user community, you'll probably never need to bother with WMI or CDOEXM. The important point is that you now have the flexibility to manage servers the way you want rather than the way Microsoft thinks you should.
Win2K Certification Standards
Before vendors can endorse their products with the Win2K logo, they must comply with certain Microsoft standards. The product must use Windows Installer for its installation procedure, MMC for its administration, and standard WMI interfaces for its management-data display.
As a Microsoft product, Exchange 2000 naturally meets these criteria. In Part 1 and Part 2, I discussed how Exchange 2000 meets the first two criteria: The product uses a new COM-based Windows Installer installation procedure and a set of MMC snap-ins for administration tasks.
To meet the third criterion, Exchange 2000 publishes management data through WMI and provides a programmable interface (i.e., CDOEXM). In addition, Exchange 2000 provides updated versions of previously released Exchange Server monitoring tools as well as a redesigned version of the Message Tracking Center.
Gathering the Data
The introduction of new management-data interfaces in Exchange 2000 doesn't mean you should replace third-party products that you use in your Exchange Server 5.5 environment. Instead, look for upcoming versions that make use of WMI and CDOEXM. Exchange Server has always been a target for third-party specialized monitoring applications, such as NetIQ's AppManager or BMC Software's PATROL. In most instances, these products must collect data from several sources (including Performance Monitor counters and the System log), store the raw data in a repository such as a Microsoft SQL Server database, then use proprietary tools to analyze the data.
The event logs are a rich source of information for these management tools. (For example, Figure 1 shows event ID 1221, which reports the result of a defragmentation pass on a mailbox store. This information is useful in tracking the growth of mailbox-store databases. See the sidebar "In a Jam," for suggestions about how to keep your logs running smoothly.) Apart from analysis data, the event logs also hold information about critical errors, such as the infamous -1018 database error. (A red flag for any Exchange Server administrator, this error indicates that something is seriously wrong between a database and the disk subsystem that serves the database.)
System monitoring is especially important in Exchange 2000 because CDOEXM enables easier access to management information, which might also serve as the basis for another category of tools. You can analyze a server's performance based on data extracted from the server while it's operational. Configuration data in the registry and in AD are also valuable for analysis, especially in enterprise deployments. The contents of the registry are esoteric; only a select circle of people at Microsoft know the true meanings of many settings. Also, some software introduces settings to the registry when you install the software to fix a specific problem on your Exchange Server machine. Two servers might appear to be the same, but a full-configuration comparison can reveal key differences. Products such as Ecora Application Server (which also supports Exchange Server 5.5) demonstrate the value of full documentation for all the settings you apply to a server. (For a review of this product, see Rodney S. Landrum, "Ecora Application Server," page 74.) CDOEXM simplifies the task of documenting server configurations, although the contents of some parts of the registry remain deep, dark secrets to the majority of humankind.
Putting the Pieces Together: WMI
WMI is Microsoft's implementation of the Web-Based Enterprise Management (WBEM) architecture as defined by the Distributed Management Task Force (DMTF), an industry body devoted to the definition of cross-platform management standards. (For information about WBEM and the DMTF, visit http://www.dmtf.org.) WBEM's purpose is to provide a method of uniform access to management information (e.g., system state, memory usage, a list of installed and running applications, connected clients) from different types of servers.
WMI's goals are to provide a comprehensive management infrastructure and to remove the need for separate management agents for every application. The management infrastructure enables systemwide and application-level observation and control through management utilities that receive data feeds from WMI providers. To provide management information to WMI, applications implement WMI calls throughout their code and register as WMI providers during installation on a server. The providers institute a consistent schema and API that applications can access through standard queries, methods, and events. The COM-based WMI API gives applications (e.g., MMC, a Web browser) access to a management-information repository—the CIM repository, which then directs the applications to the appropriate data. The Common Information Model (CIM) is a schema that defines manageable objects, including application objects (e.g., Exchange Server objects) and hardware devices (e.g., disks). WMI extends the WBEM model through
Exchange 2000 uses WMI to examine many aspects of a server, including the amount of free space still available on a disk. Figure 2, page 88, illustrates WMI architecture, which revolves around the WMI API that works with the CIM object manager and CIM repository to access a server's registered WMI providers.
The advantage of having a consistent interface to obtain and display management data from multiple sources is obvious. The challenge is for applications to write WMI providers so that management applications from Microsoft, third parties, and installation-specific routines can sensibly exploit the WMI interface (e.g., so that you could write a script to use several WMI providers to manage mailboxes through a specifically designed Web interface).
WMI Providers
Win2K includes a set of WMI providers that let the OS and applications such as Exchange 2000 access necessary management-data sources. These providers include the following:
These providers deal with data that specific applications produce. In addition, Win2K includes a View provider, which combines information from many providers into one management-data access point.
Win2K limits WMI-data access to Win2K administrators. If you attempt to access information from an unprivileged account, the Application log records the following event:
Figure 2 shows common Win2K WMI providers, including the Event Log and Registry providers, as well as the three Exchange 2000 WMI providers:
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.
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:
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.
