SQL Server Magazine

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

• 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 Win2K 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, 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.

   Prev. page   [1] 2 3     next page