Messages that Outlook Web Access (OWA) clients submit log the same sequence of entries. POP3 and IMAP4 clients use SMTP to submit messages directly to the Routing Engine. The messages don't go through the Store Driver, so the sequence begins at event ID 1019.
Other common entries include event ID 1023 (successful delivery to a local mailbox) and event ID 1029 (transfer to the MTA for onward delivery). Unlike Exchange 5.5 logs, Exchange 2000 logs have no special entry to mark the expansion of a distribution group. Instead, you'll see an event ID 1020 entry written into the log for every member of the group after expansion.
Complex messages addressed to a mixture of single recipients and distribution groups that resolve to local and remote addresses pose a particular challenge for email servers, especially if some of the recipients are members of multiple distribution groups. The fact that the number of messages sent to a distribution group is determined by the properties of the group further complicates processing. For example, the group properties that Figure 7 shows reveal that any delivery reports for messages sent to this group go to the sender. In other words, if the group contains an invalid address (e.g., a contact whose email address is no longer valid, a mailbox with an exceeded quota), the sender will receive a nondelivery notification. You can set the group properties to suppress delivery reports to decrease email traffic, but then users can never be quite sure that their message arrived. The Routing Engine performs the same per-message processing for out-of-office notifications, which you can also suppress or enable through distribution group properties. Obviously, the different values you can select for these properties result in message-generation permutations.
Because Exchange 2000 processes delivery reports and out-of-office notifications on a per-message basis, if you send a message addressed to two groups— one that permits delivery reports and one that suppresses reports—the Routing Engine must generate two sets of messages. Thus, the recipients in the first group receive a copy of the message with its properties set to allow delivery reports and the recipients in the other group receive a copy with its properties set to suppress delivery reports.
You don't want users to receive multiple copies of a message, and this situation can easily occur if the Routing Engine code doesn't handle all possible circumstances when the Routing Engine builds the recipient list for a message. To optimize the recipient list, the Routing Engine must expand all distribution groups, check the delivery reports and out-of-office-notification properties of the distribution groups, then generate the appropriate number of messages to meet the requirements as determined by each group's properties. The result of the complex nature of recipient lists is that you might see multiple event ID 1020 and event ID 1028 entries for each address on a message when you look through tracking log data.
By comparison, Exchange 5.5 MTA uses a process called fan-out to expand DLs (or groups). MTA builds the address list, then determines the best possible route for sending a single copy of the message to every addressee. Exchange 5.5 doesn't support the same set of properties to control out-of-office messages and delivery reports, so building a recipient list is easier.
In Exchange 2000 or Exchange 5.5, if duplicate messages get through, the Store on the receiving server can use the message identifier to detect the duplicates and suppress them. This backstop mechanism ensures that Exchange doesn't deliver duplicate messages.
Further Analysis
Loading a message tracking log into a program such as Microsoft Access, in which you can analyze the data to your heart's content, is easy. However, if you want to use message tracking data as the basis for analyzing traffic volume, identifying the generators of the most messages, or analyzing traffic on individual servers, you'll probably want to write some code to reduce the data to its essential numbers (such as the number of messages sent during a period, the number of addressees, and the size of the messages). Expect to process a large amount of data because one message sent to a large distribution group generates hundreds of entries in the tracking log. For example, a message sent to two common distribution groups that total 1350 users (with some duplicates) at my company generates more than 4000 entries. Judging by comments made at conferences and in Internet mailing lists, I'd say that Perl is a particular favorite of those who write homegrown code to analyze message tracking log data.
Alternatively, you can buy a commercial product such as PROMODAG Reports for Microsoft Exchange Server to do the job. Quest Software's MessageStats provides more sophisticated analyses of message log contents to report on many different statistics, such as the most popular DL and who sends the most messages. Utilities don't handle some situations well—for example, some utilities can't process messages sent to nested DLs (lists composed of lists rather than individual recipients)—but in most cases, an off-the-shelf product is an easier and more functional choice than developng your own message tracking tool.
You might have overlooked the Message Tracking Center if you aren't often asked to track a message. However, if you are asked to track a message, you can be sure that the message is important—and you need to know how to go about the tracking, including analyzing the raw data if necessary.
End of Article
Prev. page
1
2
3
4
[5]
next page -->
