Microsoft Exchange 2000 Operations Guide — Version 1.068
Client Monitoring
While it is very important to monitor the availability and performance of servers running
Exchange, domain controllers, and the network, none of these directly cover one critical
area – the experience of the Exchange end user. This area can be very challenging because
your clients can differ greatly. They may be HTTP, POP3, or IMAP4 clients running over
an intranet or the Internet. They could be MAPI clients connecting over an internal
network, or using a VPN to tunnel in. While this makes client monitoring more difficult, it
also makes it more important. After all, the main reason you monitor at the server level is
to ensure better performance and availability for the end users of Exchange. Without
monitoring at the client level, you cannot prove that your improved server performance is
reaching the client. Furthermore, in many cases, you will be required to deliver particular
levels of performance at the client level. You will need to be in a position to prove that you
are meeting the client expectations. Client monitoring tools give you the ability to prove
that you are meeting your target levels of performance and availability.
Monitoring at the client level differs dramatically from monitoring at the server level in
that you will almost certainly not want to monitor all clients. Monitoring affects the
performance of the client, but more significantly, if you monitor all workstations, you will
generate a significant amount of network traffic, which could affect the overall perfor-
mance of Exchange. Furthermore, if a server running Exchange is unavailable, you do not
need to be told this by 5000 clients. Being told by one is usually sufficient.
There are a number of third-party tools on the market for monitoring clients. These tools
generally work by having an agent installed on the client, simulating typical Exchange
client activities (starting up Outlook, performing an address book lookup, accessing public
folders, sending e-mail, and so forth). Agents report to a central management server, which
collates their information and issues reports, notifications, and alerts in the event of
problems.
For more information about how to handle problems when they arise, see Chapter 6,
“Support.”
Think of client monitoring not as something that examines the performance levels of each
client, but rather as something that you use to verify that your server performance and
availability levels are being reflected in appropriate client performance and availability. It
is generally a good idea to ensure that you have at least one agent running per subnet
because this will help you to identify problems at the client due to lack of network connec-
tivity to a server running Exchange or to the domain controller/global catalog server. You
should also have at least one agent running for each type of client. If, for example, the
clients differ in operating system or in the Exchange client software they use, they could be
affected differently, and so should be monitored separately. If you give users some freedom
over the configuration of their computers, it is usually a good idea to run the agent on
computers that users do not directly interact with. (It is important not to confuse a loss of
service on the client due to Exchange 2000 Server issues with loss of service on the client
due to user error.)