The Exchange Reports Codeplex Project
I received some interesting comments after writing about the loss of the Messaging Tracking Explorer (MTE) in Exchange 2013. Some people felt that it was absolutely fine to junk MTE as the utility was long since passed its best-sell-by date and PowerShell is much more powerful and flexible when it comes to extracting information from message tracking logs. Others believe that many administrators haven’t quite steeled themselves to mess with PowerShell and will regret the passing of a utility that provides a graphical user interface to following the path of messages as they wend their way through Exchange’s transport system. Both sides are quite correct. Of course, the Get-MessageTrackingLog cmdlet is very powerful and does a great job of extracting information from message tracking logs. In the right hands, Get-MessageTrackingLog is faster and more precise than MTE. But that’s like saying that a violin produces great music, if only you know how to play it. The point being that if you don’t know how to use the Exchange Management Shell (EMS) and are unfamiliar with the way that PowerShell behaves, knowing that the Get-MessageTrackingLog cmdlet exists is not very productive when you have to find out whether a message was processed correctly. Which brings me to Exchange Reports, a Codeplex project dedicated to helping Exchange administrators extract information from various sources more easily than they can through EMS, including the interpretation of message tracking logs. Various other reports are included including distribution groups and mailboxes, all of which are produced rather more easily than if you had to code the PowerShell yourself. I ran the reports against Exchange 2013 on Windows 2012 servers, but it also supports reporting against Exchange 2010 and Exchange Online in Office 365. Of course, other reports exist that can be downloaded to make it easier to manage Exchange servers. My two personal favourites in this respect are Steve Goodman’s Exchange
March 7, 2013
I received some interesting comments after writing about the loss of the Messaging Tracking Explorer (MTE) in Exchange 2013. Some people felt that it was absolutely fine to junk MTE as the utility was long since passed its best-sell-by date and PowerShell is much more powerful and flexible when it comes to extracting information from message tracking logs. Others believe that many administrators haven’t quite steeled themselves to mess with PowerShell and will regret the passing of a utility that provides a graphical user interface to following the path of messages as they wend their way through Exchange’s transport system.
Both sides are quite correct. Of course, the Get-MessageTrackingLog cmdlet is very powerful and does a great job of extracting information from message tracking logs. In the right hands, Get-MessageTrackingLog is faster and more precise than MTE. But that’s like saying that a violin produces great music, if only you know how to play it. The point being that if you don’t know how to use the Exchange Management Shell (EMS) and are unfamiliar with the way that PowerShell behaves, knowing that the Get-MessageTrackingLog cmdlet exists is not very productive when you have to find out whether a message was processed correctly.
Which brings me to Exchange Reports, a Codeplex project dedicated to helping Exchange administrators extract information from various sources more easily than they can through EMS, including the interpretation of message tracking logs. Various other reports are included including distribution groups and mailboxes, all of which are produced rather more easily than if you had to code the PowerShell yourself. I ran the reports against Exchange 2013 on Windows 2012 servers, but it also supports reporting against Exchange 2010 and Exchange Online in Office 365.
Of course, other reports exist that can be downloaded to make it easier to manage Exchange servers. My two personal favourites in this respect are Steve Goodman’s Exchange environment report and Paul Cunningham’s DAG health report. Although it’s great that people can create these kind of reports for Exchange, I’ve long thought that reporting is an area that the Exchange product lacks. Various protests, suggestions, and hints to the product group over the years have been ignored, probably because they had much better things to do, but it is a continuing 17-year pity at this point that a product like Exchange comes with zero reporting capabilities.
The Exchange Reports project is still in its early days and a number of rough edges still exist in the code (it falls over far too easily at the moment), but it’s a laudable effort that deserves support. The more eyes that go onto the project, the better it will be in the end. Please consider downloading and running the project and then provide your feedback. It will help!
Follow Tony @12Knocksinna
About the Author
You May Also Like