A useful report to generate from the Exchange Server 2010 message tracking logs is a summary of the different message tracking events that have occurred.

Each message tracking log entry records an event ID from the following list:

  • DSN
  • FAIL
  • SEND

Each event means different things. Healthy messages may record multiple receive, send, transfer, submit or deliver events, depending on your environment. Unhealthy messages may record badmail or fail events.

While there is no hard and fast rules about what percentage of each event you should see, it is still useful to take a look at a summary of the different events IDs in case you notice something that may warrant further investigation.

You can generate this summary using PowerShell and the Get-MessageTrackingLog cmdlet.

[PS] C:\>Get-MessageTrackingLog -ResultSize Unlimited | Group-Object -Property:EventId | Sort-Object Count -Desc | Select Name,Count

Name        Count
----        -----
RECEIVE     58679
DELIVER     47496
SUBMIT      20806
SEND        19863
RESUBMIT     8679
TRANSFER      351
DSN            96
FAIL           95
BADMAIL         2

For more tips and examples on searching message tracking logs with PowerShell check out this article.

Incidentally you may find this type of summary report to be faster to generate using Log Parser instead. In my tests the PowerShell command took almost 5 minutes to complete, whereas Log Parser took only 9 seconds on the same server. Your mileage may vary. You can check out the Log Parser query here.

About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for Practical365.com.


  1. Wale

    Sorry am New to Exchange PS, I need help to be able to do 2 things

    1. generate report to display -User – mailCount – ReceivedMail -SentMail, Mailbox size per Month
    2. Also use you tutorail script below per month rather than complete history.

    I tried this but did not work:
    Get-MessageTrackingLog -ResultSize Unlimited | Group-Object -Property:EventId -Start “9/1/2013 -End “9/30/2013″| Sort-Object Count -Desc | Select Name,Count

    But returned empty, can you help?

  2. James

    while tracking the emails, im getting the NAME as “SUBMIT FAIL” for few emails. the time is matching with the outlook time. the email sent from sender’s outlook and went to sent items of the sender but its not delivered to the recipients.

    is this know issue? can i have solution for this issue?


  3. Rob Campbell

    I suspect it’s taking so long because of the memory load. Group-Object is a blocking cmdlet, which means you’re essentially loading the entire contents of the message tracking log into memory.

    $ht = @{}
    get-messagetrackinglog -resultsize unlimited |
    foreach-object {$ht[$_.eventid] ++}
    $ht.getenumerator() | sort value -descending

    That doesn’t collect anything in memory except a hash table of eventids and counts. The message tracking info objects are discarded as soon as the appropriate key in the hash table is incremented for that event, and I believe that should run considerably faster.

    More on using hash tables as accumulators:

    1. Avatar photo
      Paul Cunningham

      Possibly. In my test lab the Get-MessageTrackingLog portion of your technique still takes roughly as long as my example in the article.

      If I trim down the -ResultSize to smaller amounts it is (as you’d guess) faster, and consistently so (eg 25000 takes 40 seconds to process, 50000 takes 80 seconds to process).

      So I guess a better performing “real world” server may run faster than my lab, but then again my prod servers have way more message tracking log data to process, so it may even out in the end anyway 🙂

      All that said, hash tables are something I need to become more ninja with 😀

      PS – this is going to be super-useful to me in better tuning our message tracking log settings.

      1. Rob Campbell

        If you’re doing that in an EMS shell, you can probably cut the time substantially by loading the snapin into a generic PS session instead, and eliminating the overhead of remoting and the associated serialization/deserialization of the data. Microsoft doesn’t recommend this because it bypasses RBAC, but you’re doing that anyway if you use logparser againt the raw tracking log files.

Leave a Reply