Managing Exchange 2000

Updated : October 25, 2001

By Tony Redmond

This article is from the Spring 2001 issue of Windows 2000 Magazine.

Increased programming possibilities

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.

On This Page

Forging Ahead with New Interfaces
Windows 2000 Certification Standards
Gathering the Data
Putting the Pieces Together: WMI
WMI Providers
Combine and Conquer: CDOEXM
Take Your Time

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.

Windows 2000 Certification Standards

Before vendors can endorse their products with the Windows 2000 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.)

Figure 1: Event-log data

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.") 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.

In a Jam

Microsoft Exchange 2000 Server is a verbose product in terms of the amount of data that it writes into the event logs—the Application log in particular—especially when you've enabled diagnostics logging above the minimal level. The Application log's default size is 512KB, which is too small for any reasonably sized Exchange Server system. At this size, the log can fill too rapidly and overflow, obscuring important events. To avoid this possibility, consider increasing the Application log to 4MB (on servers that accommodate as many as 500 mailboxes) or larger (on servers that host more than 500 mailboxes). To change the size of an event log, edit the log's Properties dialog box.

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 https://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

• A set of extensions, called the Win32 schema, that WMI adds to the CIM. The Win32 schema describes objects that are relevant to Windows applications (e.g., services).

• A Windows 2000 service (i.e., the WMI service—winmgmt.exe) that manages the CIM repository. The service responds to queries from applications that want to read data from the repository or from a WMI provider.

• A COM-based API (i.e., the WMI API) and components that let applications write code to access the CIM repository and the WMI service.

Exchange 2000 uses WMI to examine many aspects of a server, including the amount of free space still available on a disk. Figure 2 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.

Figure 2: WMI architecture

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

Windows 2000 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:

• The Directory Services provider, which permits access to AD

• The Event Log provider, which permits access to data in the event logs

• The Performance Monitor provider, which permits access to managed objects' performance data

• The Registry provider, which permits access to registry entries

• The Security provider, which permits access to security settings on files, folders, and file shares

• The Win32 provider, which permits access to base Windows 2000 services

• The Windows Driver Model (WDM) provider, which permits access to hardware-device information

These providers deal with data that specific applications produce. In addition, Windows 2000 includes a View provider, which combines information from many providers into one management-data access point.

Windows 2000 limits WMI-data access to Windows 2000 administrators. If you attempt to access information from an unprivileged account, the Application log records the following event:

Event ID 1000 Source Perflib
Description:
Access to performance data was denied to TRedmond as attempted from
F:\WINNT\System32\WBEMWinMgmt.exe

Figure 2 shows common Windows 2000 WMI providers, including the Event Log and Registry providers, as well as the three Exchange 2000 WMI providers:

• ExchangeQueue—Exchange 2000 uses this provider to list information about the protocol servicing a queue (e.g., SMTP), to enumerate the messages in a queue, to display the date and time of the next scheduled connection, and to display the size of the queue in bytes.

• ExchangeRoutingTable—Exchange 2000 uses this provider to publish (to a routing table) information about the status of the local Exchange 2000 server and any connectors running on the local server. Exchange 2000 also uses the provider to retrieve (from the routing table) information about the status of other Exchange 2000 servers and other connectors in the organization.

• ExchangeCluster—Exchange 2000 uses this provider only in a clustered environment to list a cluster group's members, resources, and current state.

Within the three providers, Exchange 2000 specifies five new WMI classes:

• ExchangeLink—This class provides information about link status and properties. The properties include the retry count, the size of the queue waiting for each link, and the link's current state (i.e., unavailable or up). The SMTP routing engine uses this information to determine link-state routing.

• ExchangeQueue—This class provides detailed information about message queues' contents—such as the protocol that the queue uses (i.e., X.400 or SMTP) and the name of the link that the queue is waiting on. A program can enumerate the individual messages in the queue. For example, Exchange System Manager (ESM) can use this function to count the messages in a queue.

• ExchangeConnectorState—This class provides information about a connector's state. The most important information is whether the connector is running, but as Table 1 shows, the class can retrieve other information, such as the AD distinguished name (DN) for the connector. Programs such as ESM can use the DN to retrieve connector properties from the Exchange Server configuration container.

• ExchangeServerState—This class provides information (e.g., memory disk, system state, the services running on the computer) about the server's state. ESM's monitoring section uses this class extensively to monitor servers.

• ExchangeClusterResource—This class provides information (in clustered environments only) about the status of a given cluster resource and the name of the Exchange Virtual Server (EVS) that uses that resource.

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 Windows 2000 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
     ("winmgmts:{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.

TABLE 1 ExchangeServer Object Properties

Fields*

*Read-only, although some of these properties (e.g., Fields) are read-only because they serve as a way to access more information.

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.

Dig Deeper

For additional information about the programming interfaces and techniques that I mention in this article, visit the Microsoft Developer Network (MSDN) Online Library (https://msdn.microsoft.com/library/default.asp) and use the table of contents to go to Technical Articles, Database and Messaging Services, Web Storage System, Microsoft Exchange Server. In particular, I suggest Barry Steinglass's article "Building Management Components for Microsoft Exchange 2000 Server" (https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmes2k/html/e2k_cmpts.asp). Aside from the MSDN library, I suggest Alain Lissoir's white papers (https://activeanswers.compaq.com/aa_downloads/6/100/225/1/42365.pdf) for code examples of how to script common systems management operations.

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.

About the Author

Tony Redmond is a contributing editor for Windows 2000 Magazine, senior technical editor for the Exchange Administrator newsletter, vice president and chief technology officer for Compaq Global Services, and author of Microsoft Exchange 2000 Server: Planning, Design, and Implementation (Digital Press). For answers to your Exchange questions, send an email message to exchguru@win2000mag.com.

The above article is courtesy of Windows 2000 Magazine. Click here to subscribe to Windows 2000 Magazine.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

Click to order