Task 2: Who Sends the Most Mail?
We have a couple of problems to solve when we want to use messagetracking logs to determine which users with mailboxes on a server send the most messages. The first problem is which event ID to look for. Messages submitted by local users have an event ID of 1027, which looks promising, but Exchange hasn't yet fully resolved the Sender-Address field when that event is recorded, so the field contains the sender's X.500-like distinguished name (DN—e.g., EX:/ O=XYZ/OU=EMEA/CN=RECIPIENTS/ CN=AJR), instead of the display name. Event ID 1031 is a better option because the Sender-Address field in that event contains the sender's resolved SMTP name. However, if you select only 1031 events, you ignore any message a local user sends for delivery to a recipient on the same server. We're forced to use event ID 1027.
The next problem is that Exchange creates a 1027 event for each addressee on a message—including each recipient in a Distribution Group (DG). To establish who the top message senders are, we therefore need to look for unique message-tracking log entries such that each message is included only once before we start analyzing the data. There isn't an elegant way to do this kind of two-step process in Log Parser; the best advice is to use a temporary file. First, use a query such as the one that Listing 4 shows to reduce the data down to individual messages by using the unique message identifier field, and write the message ID and sender address to a temporary file. Second, use a query such as the one that Listing 5 shows to extract the count of unique message IDs. Note that this query trims the leading EX: from the DNs, making the resulting output (which Figure 4 shows) a little easier to read.
Unfortunately, Log Parser lacks the ability to join queries, which would let you compare the Exchange DNs with AD (using the Legacy-ExchangeDN field) and output something more user-friendly, such as the user display name or SMTP address. This functionality might appear in a future version of Log Parser, but for now, gaps such as this demonstrate the advantage of commercial reporting packages. (See the sidebar "Commercial Alternatives" for more information about third-party options.)
Task 3: Where's the Mail Coming From?
Sometimes you want to know where the messages that end up in your users' mailboxes originated. Listing 6 shows a Log Parser query that examines event ID 1019, which marks the arrival of a message onto a server. (A query to examine domain traffic for outgoing messages would simply look for event ID 1027 instead of event ID 1019.) Figure 5 shows the query's output.
Looking at the output, we can see that the vast bulk of messages come from servers in our Exchange organization (i.e., xyz.com), but there are also many messages from sybari.com. This doesn't necessarily indicate that users receive many messages from users in sybari.com. Examining the messagetracking logs themselves might reveal that the bulk of these messages are generated by Sybari Antigen when its scanner restarts after loading new virus-pattern files, at which time Antigen sends a message from me@sybari .com to you@sybari.com on the local server. To eliminate these messages, you can use the same technique we used to remove public folder replication messages from the count.
Free and Easy
Log Parser has a lot more functionality than I have room to explore in this article. For example, if Microsoft Excel is installed on the system from which you run Log Parser, you can output data in chart format or write data into a SQL Server database so that you can perform more sophisticated queries, combine message-tracking data into other reports, or analyze information from Microsoft IIS logs to find out more about Microsoft Outlook Web Access (OWA) or Microsoft SharePoint Portal Server activity. If you're interested in expanding your use of Log Parser, check out http://www.log parser.com or http://www.microsoft .com/technet/scriptcenter/tools/log parser/default.mspx. You can also find out more about the tool by reading "Log Parser," May 2004, InstantDoc ID 42174; "Troubleshooter: Troubleshooting Message-Tracking Logs," May 2002, InstantDoc ID 24449; or "Mining the Depths of Exchange Tracking Logs," July 2000, InstantDoc ID 8903.
As with any free utility, you have to do some work to make Log Parser reveal what you are interested in, but using the tool to generate basic reports is a relatively easy process. After you begin to discover the wealth of information that the messagetracking logs hold, you might decide to move on to a more robust commercial product—or you might let the inexpensive combination of Log Parser, SQL Server, and Excel chart your way to Exchange admin nirvana.
End of Article
Prev. page
1
[2]
next page -->
