Does having access to a variety of valuable Exchange Server-related data sources, including the Windows event log, the system registry, Active Directory (AD), and Exchange Server message-tracking logs sound like a wish come true? Then Log Parser is the tool for you. This free Microsoft utility can quickly interrogate those data sources and output results in a variety of formats, including plain text, HTML, charts, or data that you can easily import into a Microsoft SQL Server database. Read on to find out how you can use this fast, powerful, and flexible utility to extract information about your Exchange servers' messaging traffic.
Using Log Parser
You can download the Log Parser kit from the Microsoft Web site (http:// www.microsoft.com/downloads/ details.aspx?familyid=890cd06b-abf8-4c25-91b2-f8d975cf8c07&display lang=en). The rudimentary installation procedure, which typically takes less than a minute, creates the Log Parser 2.2 directory under \program files. This directory contains all the Log Parser files, including the logparser .exe executable. If you've ever used SQL, Log Parser will be familiar. For example, to count all the messages received on the local server, I used the following command:
logparser "SELECT COUNT(*) FROM
C:\temp\server.log
WHERE [Event-ID] = 1028" -
i:W3C
This command generated the output that Figure 1 shows. All I asked Log Parser to do is to count the number of records in the log file (i.e., C:\temp\server.log) to which I pointed the utility. You can pass parameters such as c:\logs\*.log to instruct Log Parser to process all the message-tracking logs in a directory. In the previous example, Log Parser looks for records with an event ID of 1028, which is the identifier that Exchange writes into the message-tracking log when it delivers a message to a local mailbox on a server. The -i:W3C parameter tells Log Parser that the input file is in World Wide Web Consortium (W3C) format. This speedy utility can process even very large message-tracking logs in a flash: When I ran this sample command, Log Parser processed more than 1,000,000 records in 16.5 seconds.
Task 1: Who Gets the Most Mail?
Let's execute a more sophisticated (and useful) query. You can use Log Parser to look for the top 10 recipients of messages delivered to mailboxes on the server.
First, you need to know which fields exist in the source logs. You can ask Log Parser to parse a file and report what it finds:
logparser -h -i:w3c
C:\temp\tracking.log
Log Parser treats fields in message-tracking logs as either strings (S) or integers (I). Listing 1 contains a query that collects 1028 events and groups those events by recipient. That query is obviously more complex than the others and wraps over several lines in a command window. For the purpose of debugging and ease of use, it's more convenient to create such queries in a text file that you can then feed to Log Parser by passing the name of the text file as a parameter. Notice also that in the query that Listing 1 shows, I've taken the liberty of including a logs parameter that lets me specify the location of the input logs (i.e., C:\temp). So, to simplify the process, I can save the complete query into a file called recipients.sql, then execute the query by running the following command:
logparser
file:recipients.sql?logs=
c:\temp\*.log -i:w3c
Figure 2 shows the resulting output.
By default, Log Parser outputs results to the screen, pausing output after every 10 lines. You can pipe the output to a text file by including the following syntax at the end of the query command:
C:\temp\output.txt
Note, however, that when you send the output for this query to a file, there's no point in specifying anything other than "TOP 10" in your query as Log Parser pauses after every 10 lines and the command will never finish.
Let's refine things a little more. Take another look at Figure 2. Notice the entry for Server-IS@xyz.com; this is the address of the local public folder replication agent. I might want to know how many incoming replication messages arrived on the server, but I'm more interested in the activity of real people, so I need to exclude public folder replication messages. To do so, I can tell Log Parser to exclude any message sent to an address that includes the string -IS@, as callout A in Listing 2 does.
Now that we know who our top recipients are and how many messages they each receive, what other information do we need? How about the total size of those messages? We can tweak our query to compute the size of the total bytes field that Exchange logs for each message. Reporting the size in megabytes is more useful than reporting it in bytes; we can use a combination of Log Parser's DIV and SUM commands, then divide the computed value by 1048756 to get the result in megabytes, as Listing 3 shows. Figure 3 shows the results.
Looking at the output, we can see that one recipient—alerts@xyz.com— is receiving a much smaller total message size than the others. This recipient is likely a special mailbox used to receive notifications from an administrative process. Exchange generates a separate 1028 event for each recipient of a message; an individual message might have 20 or more recipients on a server, all of which result in separate 1028 events in the log. The fact that an individual message can feature in multiple events isn't a problem when we analyze message recipients, but it can be when we want to analyze message senders. We can use Log Parser to tackle that issue as well.