The Exchange 2000 Message Tracking Center

Microsoft Exchange Server has always included the Message Tracking Center facility, which tracks the progress of messages as they make their way between servers in an organization. The Message Tracking Center is part of the Exchange Server 5.5 administration program and resides under Tools in Exchange 2000 Server's Exchange System Manager (ESM) console. In both versions of Exchange, the feature depends on the availability of message tracking logs for interrogation. Let's look at how Exchange 2000 logs a message's progress and how you can use the Message Tracking Center to track a message.

Message Tracking Logs
By default, the properties of an Exchange 2000 server enable message tracking. The server creates a new message tracking log each day, which it names according to the date (e.g., 20030725.txt). Exchange 2000 stores the logs in the server_name.log network share, which usually resides on the same drive as the Exchange 2000 binaries. Figure 1, page 36, shows a typical set of message tracking logs.

When a client submits a message to the server, Exchange 2000 generates a unique identifier for the message and records the identifier in the message tracking logs, thus making it possible to trace a message as it makes its way to its final destination. A sample message identifier that a Messaging API (MAPI) client generated is BE8B1DCC92D77E4C9CC70E141E3B583B02226F@EXCSERVER.acme.org. (Note that this identifier isn't the same as the MAPI message identifier that you see when you view the message properties.) The only part of this identifier that makes any sense to humans is the server name (EXCSERVER.acme.org) at the end of the string. The rest of the identifier gives the Message Tracking Center information to help it track messages.

POP3 and IMAP4 clients generate their own message identifiers in the form 000001c19dbf$78c6bf90$7705d110@acme.org. Aside from formatting, the major difference between MAPI identifiers and the identifiers that other clients (such as Microsoft Outlook Express) generate is that the other clients omit the originating server name. You find client-specific message identifiers in the message tracking log's Linked-MSGID field. You also see the client-specific message identifier when you track a message and view its history.

You use three server properties to enable message tracking. To set or check these properties, open ESM, right-click the server on which you want to start message tracking, select Properties, and click the General tab. Figure 2, page 36, shows the properties, which aren't enabled by default. Alternatively, you can use a system policy, as Figure 3, page 36, shows, to set the properties across a set of servers that might span multiple administrative groups. If the check boxes are shaded, the server is under the control of a system policy and you might not have the permissions to change the property values. The properties are as follows:

• Enable subject logging and display—This property controls whether Exchange 2000 records information about message subjects in the message tracking logs and displays the information when you track a message. Message subjects can contain confidential information, so some installations opt to not collect this data. However, users shouldn't put confidential data in message subjects (or they should encrypt it), and the subject field can help you isolate the message you want to track if the user who sent it generates a lot of traffic. In most cases, recording this data causes no harm.
• Enable messaging tracking—This property instructs Exchange 2000 to begin creating and populating the message tracking logs. When you turn on the property, the transport engine logs every message that it processes and creates a new log every day. System messages, such as those that transport details of public folder hierarchies between servers, aren't logged.
• Remove log files (after a specified number of days)—The default value is 10 days, and the Exchange 2000 System Attendant process cleans up old logs shortly after midnight each day. Given the amount of disk space installed on most servers today, you can probably opt to keep logs longer if you like. (Message tracking logs aren't likely to ever cause a disk to fill up—even the logs for 10 days should be comfortably less than 750MB on the largest server.) However, if a user waits for more than 10 days to ask you to track a message that he or she suspects hasn't been delivered to the intended recipient, the message likely wasn't important and you can probably ignore the request.

Obviously, you can track messages only if all the servers that process those messages record details in the tracking logs. Thus, you should make an enterprisewide decision about whether to log messages. You should either enable logging on all servers or not at all. I recommend enabling logging because it provides a useful facility at very little cost, and the easiest way to apply settings organizationwide is with a suitable system policy.

   Previous  [1]  2  3  4  5  Next