Tracking Messages in Exchange 2007

Executive Summary:

Every version of Exchange includes options to generate message tracking logs and to then analyze the contents of the logs to discover the path that a message takes within an Exchange organization. Many companies use message tracking log data as the basis for analyzing email patterns and volume. In Microsoft Exchange Server 2003 and Exchange 2000 Server, you use the Message Tracking Center to track messages. A similar feature exists in Exchange Server 2007, as part of the Exchange Management Console (EMC) toolbox. Most of the time, administrators use the toolbox’s tracking facility to search for messages because it’s the easiest way to access the message tracking log data. However, like all of the EMC’s options, the options to track messages are based on PowerShell commands that you can use to interrogate message tracking log data directly.

Related: In the Know: Message Tracking

You might wonder why you’d bother with PowerShell if you can track messages through the EMC. The answer is that PowerShell lets you hand craft solutions to problems that Exchange’s developers might not have anticipated. Because all of Exchange 2007’s business logic is provided through PowerShell commands, anything you can do through the console you can also do through PowerShell—and more!

Exchange 2007 Differences
Before getting into the details of how you use PowerShell to track messages, it’s important to note that Microsoft made some changes to the message tracking logs in Exchange 2007, including how the logs are generated and managed. The most important changes are:

Setting Server Properties
Exchange 2007 Mailbox servers, Hub Transport servers, and Edge Transport servers generate message tracking logs by default. Client Access servers don’t, because these servers are designed to handle client connections rather than to route messages. You use the Set-TransportServer (for Hub Transport servers and Edge Transport servers) and Set-MailboxServer (for Mailbox servers) commands to control whether servers generate logs. For example, to disable message tracking log generation on a Hub Transport server called ExchLondonHT1 and a Mailbox server called ExchLondonMB1, you’d use the commands

Set-TransportServer -id ExchLondonHT1 -MessageTrackingLogEnabled $FalseSet-MailboxServer -id ExchLondonMB1 -MessageTrackingLogEnabled $False

To enable log generation, change $False to $True.

You can discover the current log generation status of all servers in an organization with the Get-TransportServer and Get-MailboxServer commands. For example:

Get-MailboxServer | Where-Object {$_.MessageTrackingLogEnabled -eq $True}

This command returns a list of all Mailbox servers that generate message tracking logs.

The Set-TransportServer and Set-MailboxServer commands are also used to control the properties that dictate where Exchange creates message tracking logs, the size of the logs, and how long they’re retained. During Exchange 2007 installation, a default location for the logs is created under the folder where the Exchange program files are installed. You can discover the location and other information about the current configuration for message tracking logs on a server with a command such as the following:

Get-TransportServer  -id ExchLondonHT1 | Select-Object *Track*

As the output in Figure 1 shows, message tracking logs are enabled on the server, and the logs are kept for 30 days, with a maximum size for an individual log of 10MB and a cumulative maximum of 250MB of logs in the folder indicated. Allocating 250MB to store logs should be more than sufficient for 30 days on most Mailbox servers, although you might need to increase the allocated space on heavily trafficked Hub Transport servers or servers that support both Mailbox and Hub Transport roles. The extra space lets you retain logs longer in case you want to analyze their contents.

The output from Get-TransportServer also reveals that this Exchange server captures the subject of messages in the tracking logs (MessageTrackingLogSubjectLoggingEnabled is True). Some companies suppress this information because they don’t think they need to know the subjects of the messages their users send. However, capturing subject data is preferable in most cases to create a more complete picture of message traffic. Users who ask for a message to be tracked often know the subject, so you can also use the subject to create a more focused search. To move your message tracking logs off the C drive to somewhere more appropriate, use a command such as the following:

Set-TransportServer -id ExchLondonHT1 -MessageTrackingLogPath "D:LogsMT"

Log Creation
Exchange 2007 creates new message tracking logs daily when the first message passes through a server. This message doesn’t necessarily have to come from a user—Exchange generates a lot of system messages for purposes such as public folder replication, reminders to users that they’re approaching or have exceeded their mailbox quota, and so on. Logs on Mailbox servers are named MSGTRKMyyyymmdd-1.LOG, where yyyymmdd is the date (e.g., MSGTRKM20070510-1.LOG). If Exchange has to create multiple logs for a specific day (e.g., because the mail traffic is so high that the maximum log size is exceeded), it increments the last figure in the log name from -1 to -2, -3, and so on. Note that this behavior is new to Exchange 2007; previous versions create a single log daily, no matter how large it becomes. Logs generated on Mailbox servers contain information about events that occur as messages are submitted by users and then pass from the Information Store to the transport service. The transport service is local if you run a multi-role server that supports the Mailbox and Hub Transport roles. It is also local if you operate pure Mailbox servers.

The names of message tracking logs are similar on Hub Transport servers and Edge Transport servers (i.e., MSGTRKyyyymmdd-1.LOG). These logs contain all the events that occur as Exchange accepts messages from the Store into the transport service then routes them onward to other Hub Transport servers or Edge Transport servers, connectors, or back to the Store for local delivery.

Searching Log Contents
Active Exchange servers generate a lot of message tracking data. The Get-MessageTrackingLog command lets you interrogate message tracking logs, but if you execute the command without passing any parameters, it dumps out the available log data in a continuous stream up to the limit set by the RecordSize parameter (5,000 by default), which isn’t very helpful. Figure 2 shows output from executing Get-MessageTrackingLog without passing any parameters. Several types of messages are reported, including a Delivery Status Notification (DSN) to tell a user that Exchange can’t deliver a message and some replication messages to replicate the public folder hierarchy between servers. The output even includes an Exchange service message informing a user of a full mailbox.

To have any chance of finding the information you want from the message tracking logs, you must supply some search parameters to limit the data Exchange returns. For example, if you know the name of a recipient for a message, you can pass it as follows:

Get-MessageTrackingLog  -Recipients '[email protected]'

If you have multiple users to search for, you can separate the names with commas:

Get-MessageTrackingLog  -Recipients '[email protected]', '[email protected]'

Even if you specify recipients, Exchange might still return a lot of data depending on how many messages the specified recipients receive. You can be more specific by adding a sender’s name and a date range:

Get-MessageTrackingLog -Recipients  '[email protected]', '[email protected]' -Sender '[email protected]' -Start  '5/10/2007 1:00:00PM' -End '5/10/2007 2:00:00PM'

Note that all email addresses are in SMTP format and use the primary SMTP address (recipients might have multiple SMTP addresses).

You now have a focused search that looks only for messages in a 1-hour period sent to a specific user by a specific user. This information should be enough to find the message, but if you capture subject data in the message tracking logs, you can narrow the search even further by including the subject. The following search looks for messages with the word “critical” in the subject:

Get-MessageTrackingLog -Recipients  '[email protected]', '[email protected]' -Sender '[email protected]' -Start  '5/10/2007 1:00:00PM' -End '5/10/2007 2:00:00PM' -MessageSubject 'Critical'

Of course, a search by subject relies on users spelling words correctly, which isn’t always the case. Language differences can also come into play, such as the difference between “prioritize” and “prioritise” in US and UK English.

Finally, you might want to focus on a specific step of a message’s path through the system, such as the initial submission by a client to Exchange. You can do so by including the -EventId parameter in the Get-MessageTrackingLog command. For example, -EventId "Submit" selects any instances in which a client submits a message.

Making Sense of the Output
When you execute a Get-MessageTrackingLog command, Exchange searches the set of message tracking logs on the local server. You can use the -Server parameter to specify the name of another server, but your account must have administrative permission for that server before the Exchange Transport Log Search service will let you access the log data.

Remember that Exchange 2007 maintains two different message tracking logs—one for Hub Transport servers and one for Mailbox servers. If you execute a search on a multi-role server, Exchange combines the data from both logs but doesn’t sort the data. You therefore need to sort the data by timestamp to ensure that you receive an accurate picture of how messages flow through the system. To sort the data by timestamp, add an extra step to the command to pipe the output from the Get-MessageTrackingLog command to the Sort-Object command:

Get-MessageTrackingLog -Recipients  '[email protected]', '[email protected]' -Sender '[email protected]' -Start  '5/10/2007 1:00:00PM' -End '5/10/2007 2:00:00PM' -MessageSubject 'Project X' -EventId  'Submit' | Sort-Object Timestamp

Once you know how to search the logs, you can search for traces of whatever messages you need to find. A scan of the logs can produce several hits, such as those shown in Figure 3. Exchange 2007 is reasonably quick at parsing the logs, so you shouldn’t have to wait long for a search to complete.

Suppose you locate a message that deserves further examination. You can select the message and view a more complete set of properties by adding some commands. For example, to select and view the properties of the last message in the list shown in Figure 3, add the following commands:

Select -Last 1 |  Format-Table

These commands output the properties of the selected log entry in table format to the screen. Capturing the data to a text file is sometimes more useful; to do so, change the command as follows:

Select -Last 1 |  Format-Table > C:TempX.tmp

Exchange will then pipe the output to a text file called C:TempX.tmp. Figure 4 shows sample output.

The output in Figure 4 shows only that a user submitted a message to the Store for delivery. You must trace the message path to discover where the message went and to determine its final disposition. Keep in mind that you can’t trace a message outside an Exchange 2007 organization unless you have the ability to interrogate message logs in the other mail systems that might handle the message en route to its final destination.

If you don’t want to use PowerShell directly, you can use the EMC toolbox option to track messages, as Figure 5 shows. An interesting thing about using the EMC is that it generates and shows you the PowerShell command it uses to interrogate the message tracking logs (see the circled code in Figure 5). You can cut and paste the code from the EMC into a text file to use as the basis of a PowerShell script—or just as an aid for learning the syntax of Get-MessageTrackingLog commands.

Exercise Your Options
Exchange 2007 provides two methods for searching message tracking logs—through the EMC toolbox option, or directly through PowerShell. Although most administrators will probably reach for the toolbox to perform searches, it’s useful to know that Exchange provides the flexibility for administrators to query this data through PowerShell to meet business requirements that the console might not satisfy.

Learn more: Handling Poison Messages with Exchange 2007