General discussion


Best practices to monitor Exchange 5.5

By jasonhiner Moderator ·
This question is being posted by the TechRepublic staff. The response(s) from this post will be turned into an article on the TechRepublic site. This is a winner-take-all scenario and the winner will be the person who provides the best and/or most complete answer in our judgment. If there are multiple correct answers we will select the one that was posted first. In addition to offering a generous amount of TechPoints, the winner will also receive a free piece of TechRepublic gear (e.g. a coffee mug, a desk flag, or another item sporting the TechRepublic logo). This competition ends at 11:59 PM on Sunday, May 23. Good luck and let the best techie win!

HERE IS THE SCENARIO: A network administrator has inherited an Exchange 5.5 server and wants to set up some best practices for monitoring it. What does the admin need to monitor in terms of CPU utilization, RAM utilization, and Exchange-specific variables? What are some are the most important red flags to look for?

This conversation is currently closed to new comments.

23 total posts (Page 1 of 3)   01 | 02 | 03   Next
Thread display: Collapse - | Expand +

All Comments

Collapse -

by Joseph Moore In reply to Best practices to monitor ...

I don't have an Exchange server (I've been in a Lotus Domino shop for 3 years now), so I don't recall what to keep an eye out for specifically, in regards to Event Viewer logs and such.
So, I would suggest to look for open ports.
I would run something like IPMonitor ( which can connect to a remote machine on various ports. If a connection cannot be accomplised on any monitored port, alerts can be triggered.
So for Exchange, I would 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 popup windows on machines, dial digital pagers, etc.
That is how I would monitor the Exchange server.
That way, if the SMTP service were to fail in Exchange, then that means port 25 would stop be in a listening status on the Exchange server. And a monitor program like IPMonitor can tell this, and send me alerts with its own SMTP engine; it does not need an existing (or working) SMTP engine! One really good feature of it.
So, that's my idea on this.

Collapse -

by jasonhiner Moderator In reply to

Poster rated this answer.

Collapse -

by CG IT In reply to Best practices to monitor ...

Exchange 5.5 has been around for a long time so one could just go to Microsoft's Exchange web site and just copy their "Best Practices" for Exchange.

Based upon your senario, CPU utilization, RAM utilization I would venture the admin is looking at an old box and wondering if it is sufficent to handle the amount of user use. One could use performance optimizer [perfwiz.exe] for Exchange 5.5. Analyzes and logs just about everything. Again, determining if the box Exchange resides on can handle the amount of use users put it to depends upon how many users there are. If this is a relatively small company 100 to 300 users and users are complaining that it takes a long time to update folders in Outlook once they log on, or takes a long time for mail to be sent to exchange once they click the send button, could be time to upgrade hardware.

Monitoring mailboxes and public folders store as well as message transport agents is probably one of the more important areas. Red flags? MTA errors in the event viewer, information store errors. Public folder store is another area to watch. I would also look at antivirus software activity on exchange. I use Norton Corporate Antivirus with the Exchange antivirus. The scanning of inbound and outbound mail for viruses tends to slow down the message transport agent if you have one Exchange Box and a lot of users sending and receiving a lot of email [like sales departments] and users who use their work email address to fill out web site info forms which in turn causes huge amounts of spam. Spam email and filtering is probably the biggest area to monitor and chews up Exchange and looking at user mailbox storage is another area to watch [red flag area].

That's my 2 cents on admin Exchange.

Collapse -

by jasonhiner Moderator In reply to

Pretty good stuff.

Collapse -

by tundraroamer In reply to Best practices to monitor ...
Collapse -

by jasonhiner Moderator In reply to

Let's assume that's not an option in this case -- which is the situation in many companies right now.

Collapse -

by taro In reply to Best practices to monitor ...

Like any other server, monitor
- Processor/%Processor Time and %User Time. Look for divergences between overall and user time as that means trouble. Overall CPU should have at least 50% headroom in the middle of the afternoon.
- Memory/Pages per sec -- should be zero some/most of the time and low the rest of the time and you are short of memory if it isn't
- Physical Disk/%Disk Time -- if the disk light is on a lot of the time, the server needs more memory ..... perhaps
- For Exchange, Process/Working Set _Total always seems to be all physical memory, all the time; but it's nice to see anyway.

Specifics for Exchange include
- Process/%Processor Time for the STORE process is worth watching. Normally when the CPU load goes up, it's STORE consuming it. If STORE gets busy check the queues and the App Event Log
- ExchangeMTA/Work Queue Length should be zero. If it grows, use Exchange Admin to isolate the problem to the specific queue. There will be clues in the MTA messages in the App Event log.
- Also take your pick from the message rates on the MTA and the Private IS.

Disk space is surprisingly easy to run out of:
- Assuming you have circular logging off (and you should) watch the free space on the log spindle. The IS will stop and fail to restart start when you run out of space -- successful backups delete the logs.
- Of course you need to check free space on the system drive and the IS drive. It's worth checking the App 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.

Use Exchange Admin to nose around the site.
- On the individual server, check mailbox sizes in the Private IS properties. Discipline the hogs with the Limits tab on their boxes.
- Set mimimum or medium logging on the connectors -- the information is not bulky and can be good to read.

Collapse -

by jasonhiner Moderator In reply to
Collapse -

by 1BAD68 In reply to Best practices to monitor ...

To find out how your Exchange 5.5 environment is running you need to monitor the CPU, Disk (I/O), Network, Memory and Exchange for red flags such as:

Is your CPU going above 80% and staying there for consecutive sample intervals? If it does you may have a problem with the server or you monitoring sample interval.

What is your Disk I/O on your log file drive and you database drive? You need to make sure that your log file drive is not constrained and then the database (they're related), then the MTA, swap file, etc.

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

The next item to check is your Network. Do you have a lot of errors? Do you have a large queue? Is there a bottleneck?

The last item to check is the Memory as it is something that Exchange uses a lot of (it's designed that way). Because of OS and other limitation, you don't want to go over about 1GB of physical memory configuration. If you are running Exchange 5.5 on and NT 4 server, it can degrade performance.

The last items to be monitored related to overall system health such as queue levels, error logs, disk space remaining, and operations level issues (you can use the performance monitor to check these). As for thresholds, most of them are related to the OS. You can reference the OS reskit to find out what the levels are suppose to be for a healthy server.

To check the Exchange specific thresholds, what the queues for any hang ups.

I am at a small company, so I check the above items manually; however, if you are 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, Spotlight and MOM softwares).


Collapse -

by jasonhiner Moderator In reply to

The was the best all-around answer

Back to Windows Forum
23 total posts (Page 1 of 3)   01 | 02 | 03   Next

Related Discussions

Related Forums