Best practices for monitoring Exchange 5.5

by Guest Contributor | Jun 22, 2004 7:00:00 AM

Tags: E-mail servers, E-mail, Guest Contributor, monitoring, Microsoft Exchange 5.5 Server, disk

Takeaway: Here's a group of tips that can help an administrator get up to speed on what to monitor on a Microsoft Exchange 5.5 system.

Submitted by

Submitted by 1BAD68 (with additional contributions from Joseph Moore, D.R. The Corporate Groups, taro@nub.co.uk, jburton@aflac.com, and mjost@cox.net).

Problem

Many organizations still rely on Microsoft Exchange 5.5 to handle e-mail and collaboration services, which means that a lot of administrators inherit Exchange 5.5 systems when moving into new positions as IT professionals. Because Exchange is almost always vital to the operation of the organization, it's important for these administrators to keep a close eye on Exchange.

Solution

The following tips can help an administrator get up to speed on what to monitor in Exchange 5.5. To find out how your Exchange 5.5 environment is running, you need to monitor the CPU, disk (I/O), RAM, network, and Exchange variables for red flags.

Is your CPU going above 80 percent utilization and staying there for consecutive intervals? If it is, you may have a problem with the server. Abnormally high CPU utilization is normally the side effect of a problem with a separate system component such as the disk or network subsystems. Also keep an eye on spam and antivirus filtering software, which can eat up a lot of CPU (and memory) resources. To help determine performance and configuration, you can use the Exchange Server Performance Optimizer (perfwiz.exe) that comes with Exchange.

What is the disk I/O on the drives that host the Exchange log files? You need to make sure that your log file disk is not constrained. The same goes for the disks that contain the database, the MTA, and the swap file. Disk space is surprisingly easy to run out of. Assuming you have circular logging off (and you should), watch the free space on the disk that contains the logs. The Exchange Information Store will stop and fail to restart when you run out of space. Of course, you also need to check free space on the system disk and the disk that hosts the Information Store. It's also worth checking the application event log for event 1221, which reports the white space in the IS after the overnight online defrag. When it gets too large, schedule an offline defrag.

If you've separated your I/O, you probably have your databases (Dir and Pub) on separate drives, or different machines if your company's size warrants it. You'll also want to have your MTA separated if you have a large implementation.

The next item to check is your network connectivity. You can run something like IPMonitor, which can connect to a remote machine on various ports. If a connection cannot be accomplished on any monitored port, alerts can be triggered. For example, in Exchange you can monitor the SMTP port (TCP port 25), POP3 port (110), and the IMAP port (143). If any of those ports closes (i.e., the process in Exchange crashes), then IPMonitor could be set to send e-mails, generate pop-up windows on machines, dial digital pagers, etc.

Of course, you'll also need to monitor the RAM, which Exchange 5.5 uses a lot of (it's designed that way). Because of OS and other limitations, you don't want to go over about 1.0 GB of physical memory on a server that runs Exchange 5.5 on Windows NT 4.0. If you do, it can degrade performance.

Check the Exchange-specific thresholds:

MSExchangeMTA—Work Queue Length: This counter should not be greater than zero for a sustained time period.
MSExchange Private & Public—Average Time for Local Delivery: This should never be above zero for more than a few seconds.
MSExchangeDS—Pending Replication Synchronization: With more than one Exchange server, replication requests should always decrement to zero.
IMS—Monitor queues to make sure mail is flowing.

You'll also want to monitor overall system health such as queue levels, error logs, remaining disk space, and operations level issues (you can use the Windows Performance Monitor to check these). As for thresholds, most of them are related to the OS. You can reference the Windows Resource Kits to find out what the levels are supposed to be for a healthy server.

In small companies, administrators usually check these items manually; however, if you're in a large company, it would be easier to purchase monitoring applications that understand what the recommended thresholds are out of the box (e.g., NetIQ for AppManager, Quest Spotlight, and MOM).

Next Steps: Build your skills with these hand-picked resources