Managing Exchange 2000, Part 2

In "Managing Exchange 2000, Part 1," February 2001, I reviewed how Microsoft Exchange 2000 Server has embraced the Microsoft Management Console (MMC) framework, and I described the interaction between Exchange 2000 and Windows 2000's Active Directory (AD). I also examined the division of server-management tasks, which Exchange 2000 performs through the Exchange System Manager (ESM) console, and user- related management tasks, which Exchange 2000 performs through extensions to the standard MMC Active Directory Users and Computers console.

All this knowledge lays a solid foundation for operating Exchange 2000 servers and introduces you to your next task: keeping all your Exchange Server machines running. In this installment, I explain how to monitor servers and what type of status information you can expect to retrieve from the components that represent a healthy server. I also introduce some of the Windows Management Instrumentation (WMI) providers that enable access to Exchange 2000 data.

Back to Basics
Exchange Server has always provided a mechanism to monitor servers. Exchange Server 5.5 implements a primitive form of the Ping command in server and link monitors to determine whether servers are currently reachable on the network; this pinging also informs you whether the set of services (e.g., the Information Store—IS, Message Transfer Agent—MTA) that constitute a fully running Exchange Server system are active. Conceptually, this procedure hasn't changed in Exchange 2000—you can still monitor and retrieve status information from servers. The difference lies in how you go about monitoring servers, the data you can retrieve from servers, and the interfaces that Exchange 2000 uses. (Exchange 2000 supports a full set of documented interfaces that you can exploit to better integrate Exchange Server into an overall systems-management strategy. This point hasn't been lost on third-party developers, who are upgrading their products to take advantage of the new interfaces.)

The ESM console's Monitoring and Status node replaces the server and link monitors that previous Exchange Server versions support. This node lets you set up email or script notifications for events that have occurred on monitored servers, as well as display the status of the servers and connectors within a routing group.

Figure 1, page 106, shows the ESM console, which is the basic working environment you use to manage and monitor Exchange 2000 servers. You can select the Notifications node to expose the set of notifications that operate from a server; you can select the Status node to reveal information about the servers and connectors in the server's routing group.

Monitoring Servers
Exchange Server 5.5 uses server monitors to periodically confirm that services are running as expected on a target server. Exchange 2000 implements the same basic principles but now refers to server monitors as notifications. You establish a set of conditions that you want to monitor on a server and assign a server to monitor those conditions. Exchange 2000 uses remote procedure calls (RPCs) to retrieve information from a server, so you can monitor a server only when the network connection between the two servers supports RPCs. This requirement is a design consideration when you decide which server to use as a monitoring base.

Exchange 2000 supports both email notifications and script notifications. An email notification results in Exchange 2000 sending an email message to a predefined set of email addresses. A script notification invokes an executable or Windows Script Host (WSH) script to perform required operations. Clearly, a script notification—which can perform several different programs and other operations in sequence should an error condition arise—is much more powerful than an email notification. As the Monitored Items column in Figure 2, page 106, shows, the QEMEA-ES1 server is monitoring itself (i.e., This server) and two other servers (i.e., QEMEA-DC1 and QEMEA-ES0). If a specified condition, such as disk space dropping under a predefined threshold, occurs on any monitored server, the monitor will send an email message. (A systems failure can stop Exchange Server dead, so never rely completely on the arrival of an automated notification message.)

You can define monitoring parameters for a server in two ways. First, you can expand the Administrative Groups folder, select a server from the list, open the Properties sheet, and go to the Monitoring tab. Alternatively, you can open the ESM's Status node, select a server from the right pane, and open the server's Properties sheet. Either method opens a Properties dialog box similar to the one that Figure 3 shows. (The disks that you can monitor for the Free space threshold condition differ from server to server. This condition is important because services such as the IS or MTA will stop when a disk that they use runs out of free space.) Table 1, page 108, lists the conditions that you can monitor.

The Disable all monitoring of this server check box permits or prevents server monitoring. The check box is cleared by default, so servers automatically publish monitoring data through WMI. Don't select this check box unless you have a good reason for not monitoring the server.

After you establish monitoring conditions, Exchange 2000 will fire notifications if the server meets the specified threshold condition. Figure 4, page 109, shows how the ESM defines parameters for an email notification. The Servers and connectors to monitor drop-down list includes options such as This server, All servers, Any server in the Rout-ing Group, and Any connector in the Routing Group. The Customize button lets you select a specific set of servers from a dialog box that lists all the known Exchange Server machines in the organization.

The ESM validates the To and Cc fields against AD. You can send alerts to users, contacts, or groups. If you want to send the alert to a special address, such as a Short Message Service (SMS) or Wireless Application Protocol (WAP)-enabled cell phone, you need to create a contact and specify the email address to generate the SMS or WAP message. (Typically, you can send messages through SMTP, so this requirement isn't a big problem.)

You can edit the subject and content of the message as long as you're careful not to change the predefined fields that Exchange Server will insert values into. TargetInstance references the name of the server being monitored and, as Figure 4 shows, has several properties that Exchange Server uses for reporting. These properties include QueuesStateString, which Exchange Server uses to insert the current status of both the SMTP Routing Engine and the X.400 MTA message queues.

Figure 5, page 109, shows an example of the message that Exchange 2000 will send to the nominated email addresses if it detects one or more exceeded thresholds. The details are limited but certainly enough to alert you to take action, if only to gather additional information about the problem. In this case, the message shows that the monitored services are running but that a backlog of messages has built up on one or more queues and that the report thresholds for Drives (i.e., disk space), Memory, and CPU (i.e., percentage of CPU utilization) are in an Unknown state. At first glance, the primary problems seem to be with the system's resources; exceeding the CPU threshold or a lack of memory might be the root cause of Exchange Server's inability to clear the message queues. After I connected to and examined the server, everything seemed to be in order and the queue had cleared—which proves that you can expect an occasional false alarm. Better that the alarm sounds than you experience a system failure.