TechRepublic Tutorial: Monitoring your Exchange 2000 server

Configure Exchange 2000 to watch for certain conditions and send you an e-mail or execute a script when those conditions occur.

One of the coolest new administrative features in Exchange 2000 is the ability to closely monitor your Exchange servers. Of course, Exchange 5.5 included a few methods that you could use to monitor your server either through the Performance Monitor or through the Event logs. While these capabilities exist and have even been expanded in Windows 2000, I’ve always thought it was a pain to have to go look at the event logs every day to hunt for signs that a problem may be occurring.

However, Exchange 2000 provides a method by which you don’t necessarily have to hunt through the event logs searching for signs of a potential problem. Instead, Exchange 2000 can be configured to watch for certain conditions and send you an e-mail or execute a script should the predefined conditions occur. In this Daily Feature, I’ll show you some of Exchange 2000’s server monitoring options.

Implementing server monitoring
To implement server monitoring, open the Exchange System Manager and navigate through the console tree to organizational root | Tools | Monitoring And Status | Notifications. When you select the Notifications container, you’ll see a list of your Exchange servers appear in the column on the right. Now, right click the server that you want to monitor and select Properties from the resulting context menu. When you do, you’ll see a properties sheet for the server, as shown in Figure A.

Figure A
Exchange 2000 is set up to automatically watch for the failure of critical services.

As you can see, Exchange monitors one event by default and automatically watches for the critical Exchange services to stop. If you select this condition and click the Details button, you’ll see a list of the critical Exchange services and their current run states. You can also add or remove services from the list. You can even select whether to set the condition’s state to Critical or to Warning when a service fails.

There are also other conditions that you can monitor besides failed services. To do so, click the Add button on the properties sheet shown in Figure A. When you do, you’ll see six additional conditions that you can monitor. These are:
  • Available Virtual Memory
  • CPU Utilization
  • Free Disk Space
  • SMTP Queue Growth
  • Windows 2000 Service
  • X.400 Queue Growth

Using these monitoring mechanisms can alert you to all sorts of problems. For example, monitoring available virtual memory, CPU utilization, and free disk space can alert you to critical conditions in which the system may be running low on resources. By doing so, you can avoid having to periodically check the Performance Monitor to see how many of the system’s resources are being used.

Likewise, monitoring SMTP queue growth and X.400 queue growth can alert you to problems related to a failed network link, failed Internet connection, or a flood of mail that’s too big for the server to keep up with. Such a mail flood could occur during a denial of service attack. The option to monitor Windows 2000 services allows you to keep an eye on other non-Exchange-related services that you consider to be critical.

Reacting to warning states
Once you’ve decided which conditions you want to monitor and have configured the critical state and/or warning state for the conditions, it’s time to configure the way that Exchange reacts to the condition. Although Exchange 2000 is set to automatically monitor the failure of critical services, it isn’t set to automatically react to failure conditions.

To control the way that Exchange reacts to conditions that you monitor, navigate through the Exchange System Manager to organizational root | Tools | Monitoring and Status | Notifications. Then, right click Notifications and select New and E-Mail Notification from the resulting context menus. When you do, you’ll see a properties sheet that allows you to set up an e-mail message to be sent when a monitored condition reaches either the warning state or the critical state.

In Figure B, you can see an example of how I’ve configured this dialog box to report errors via e-mail. Keep in mind that if you’re monitoring the Exchange services, a server can’t report failed services via e-mail because it depends on those services to send the message. Therefore, it’s a good idea to set up one mail server to monitor another server as I did.

Figure B
You can generate an e-mail message to be sent either during a critical situation or when a warning needs to be issued.

If you’d rather have Exchange respond to failures via a script, navigate through the Exchange System Manager to organizational root | Tools | Monitoring and Status | Notifications. Right click Notifications and select the New and then Script Notification from the resulting context menus. You’ll then see a properties sheet where you specify the name of the script to be run. You can set Exchange to run this script after either a critical failure or during a warning condition.

Remember only your imagination limits what you can do with a script. For example, if the server was running low on disk space, you could write a script that would delete the files out of a Temp directory. Since you can send an e-mail and run a script, Exchange could alert the administrator of the problem and the administrator would know what steps Exchange has already taken to deal with the problem.

If you want, you can just buy a server, install Exchange 2000, and walk away hoping that everything works smoothly. Chances are, you wouldn’t do such a thing unless you weren’t worried about the consequences of a poorly performing server. For those of us who do worry, Microsoft includes some powerful monitoring tools in Exchange 2000.

Editor's Picks