Message Tracking from the command line in Exchange 2010 and Exchange 2007

by Bharat Suneja

I’ve forever envied folks (including some colleagues— you know who you are… ) on the Linux/Unix side of things who were able to parse text log files generated by MTAs like Postfix/SendMail/EXIM in a fraction of the time it takes one to fire up Message Tracking Center on Exchange and search for a message. I tried for a while to put together some scripts that could do something as cool as those guys, but it was nowhere as close.

Thankfully, Exchange Server 2010/2007 and the Exchange Management Shell (Exchange shell) bring an end to that Linux/Unix-MTA envy (yes, I’m indeed talking about the Exchange Management Shell (EMS)…. I’ll just call it Exchange shell, and you can probably tell how much I love Microsoft naming conventions… Powershell=cool name for new Windows shell, Exchange Management Shell=not even close! ).

Message tracking using the shell is easy. (Yes, it is a shell, and…. Yes, you’ll need to remember a syntax. No, you may not always remember it. No, you don’t need to remember every single option… Yes, there’s help! Get over it. Or use the GUI – more about that in a little bit.)

The magic cmdlet: Get-MessageTrackingLog

If you want to track messages using the shell, the magic cmdlet to remember is Get-MessageTrackingLog. It’s capable of doing wonderful things very quickly.

Avoid typing too much: Using aliases for commands

Yes, that’s a long command to type in every time. Luckily, the shell has tab completion which allows you to type a partial command and have the shell complete the rest. In case of multiple matches, you can continue to hit tab and cycle through all the matches till you find the one you want.

Windows Powershell, and therefore the Exchange shell, allow you to create your own preferred aliases for commands. I use the alias track for Get-MessageTrackingLog. To create an alias:

New-Alias track Get-MessageTrackingLog

Now you can simply use track blah.

What can you do with it? A lot.

Message Tracking log fields

First, let’s take a look at a typical record in the tracking log. A single message generates multiple records in the log, one for each message tracking event. Familiarity with the fields and the kind of information they contain will help you filter and find what you’re looking for. If you frequently use message tracking for troubleshooting or otherwise, this familiarity can be rewarding.

Filtering Message Tracking Logs

You can filter Message Tracking logs by the following properties:

Property

Description

StartEnd

By default, Message Tracking logs are kept for a maximum of 30 days. If you’re trying to find a message that may have been sent or received in the last day or two, or a specific period, it’s inefficient to search 30 days worth of logs. It’s a good idea to narrow down the search by specifying a start time, and preferably the end time as well.

Event ID

This is by far one of the more important parameters of Message Tracking logs that we need to understand. Whereas Exchange Server 2003/2000’s Message Tracking log was an easy-to-use application that shielded the user from this complexity, it also provided much less flexibility. Message Tracking logs have a lot of details about a message as it originates from an internal user or external sender, and makes its way through the different stages of message routing and transfer, and finally gets delivered (or not). You can now track messages based on these events.

Sender

Sender’s SMTP address

Recipients

SMTP address(es) of one or more recipients

MessageSubject

The subject field in the message header

MessageID

This is the MessageID in the header. It is constant for the lifetime of a message, and can be used to track messages across different mail systems.

InternalMessageID

An integer field assigned by the Exchange 2007 server that is currently processing the message. The same message will have a different InternalMessageID on different Exchange servers.

Message tracking events

Here’s a list of some of these EventIDs:

EventID

Description

DEFER

Message delivery delayed

DELIVER

Message delivered to a mailbox

DSN

A delivery status notification was generated.Messages quarantined by the Content Filter are also delivered as DSNs. the recipients field has the SMTP address of the quarantine mailbox.

EXPAND

Distribution Group expanded. The RelatedRecipientAddress field has the SMTP address of the Distribution Group.

FAIL

Delivery failed. The RecipientStatus field has more information about the failure, including the SMTP response code. You should also look at the Source and Recipients fields when inspecting messages with this event.

POISONMESSAGE

Message added to or removed from the poison queue

RECEIVE

Message received. The Source field is STOREDRIVER for messages submitted by Store Driver (from
a Mailbox server), or SMTP for messagesa) received from another Hub/Edgeb) received from an external (non-Exchange) host using SMTPc) submitted by SMTP clients such as POP/IMAP users.

REDIRECT

Message redirected to alternate recipient

RESOLVE

Generally seen when a message is received on a proxy address and resolved to the default email address. The RelatedRecipientAddress field has the proxy address the message was sent to. The recipients field has the default address it was resolved (and delivered) to.

SEND

Message sent by SMTP. The ServerIP and ServerHostName parameters have the IP address and hostname of the SMTP server.

Finding messages

Here are some examples that show how to use different parameters such as sender, recipients, start and end times to find messages. These examples demonstrate the power of the Exchange shell and how it can help you be very productive when managing Exchange 2010/2007 using this great new too.

To get all fields from a message in a list format, you can pipe the output into a fl (format list).

By default, the Get-MessageTrackingLog command returns up to 1000 results. This can be hard to work with in a command screen that keeps scrolling endlessly. In addition to the above parameters used to filter the logs, you can also restrict the number of results returned using the ResultSize parameter.

Combine the above with the out-html | out-ie scripts/commandlets that I blogged about earlier (read previous post “More about the out-html | out-ie functionality“), and you have a nifty little message tracking report displayed in a browser. One step further, there’s an out-email script that can be used to directly email the tracking results to a sender/recipient.

Having said that, yes, there’s a Message Tracking GUI as well under Tools | Message Tracking in the Exchange console. I know it’s a pre-release version, but all I can say is it’s not something you’ll fall in love with. (Although not a pre-release version any more, the remainder of the previous statement is still true). I would even go as far as to say I liked the old one better. It needed some tweaks but it worked for a lot of folks.

Message tracking using the Exchange shell is much faster than using the Message Tracking tool in the Exchange console, and chances are it will help you get rid of the Sendmail/Postfix-envy.

Great info shared !
By the way, due to not much technical expertise, I use Lepide exchange reporter (http://www.lepide.com/exchange-reporter/) that works fantastic in my environment. It tracks all sent/received emails by users and provide the reports at granular level in real time.