Who Needs Office 365 Message Tracking Logs
Who Needs Office 365 Message Tracking Logs?
For those thinking of, or who have already attempted, the migration path to Office 365, there is a major problem with Exchange reporting that needs to be addressed.
Reporting needs for on-premise Exchange server installations are met by accessing Message Tracking logs, as they contain the essential source data for messages that travel between servers within the Exchange Organization. This data can be obtained at any time and facilitates the analysis of email traffic for multiple reporting requirements as well as forensic search, an increasing important concern for organizations large or small. Since the information is stored indefinitely, for some organizations without formal or very basic reporting requirements, this was enough. Sleep easy - react when needed.
Office 365 also provides access to the same types of information but there are a couple of big problems that render this information both difficult to access and time-limited.
First of all you need to use the Get-MessageTrace PowerShell command to retrieve information about email messages. This is cumbersome, as I’ll explain below. What’s worse, however, is that the information expires after 30 days. Forget to retrieve it for whatever reason and it’s gone. Ouch!
Using the Get-MessageTrace PowerShell command
What do we mean by cumbersome?
First off, the maximum number of messages you can retrieve with a single command is 5,000. What this means is that you need to send successive commands with different parameters until you get them all. Friendly and easy it is not and of course very prone to error.
Next up the retrieved events come back in anti-chronological order: the first message of the day is found at the last line of the last file. This means you need to sort the messages back into order across different files. Not the best use of time!
Situation Anything But Normal
Imagine the situation: boss rings, there’s been a major snafu and he needs you to retrieve a specific set of email messages. Of course you’d started out retrieving those messages and put them in a storage location somewhere but any of the following could have happened:
Some of the messages are missing: you went on holiday and forgot to execute the relevant power-shell commands.
Some of the messages are missing: you forgot to change the parameters on one of the commands correctly so got duplicates and missed some.
Your smile, after you recall you’ve executed all the commands correctly, turns to horror when you examine the data and find its distributed across multiple files in reverse chronological order.
Of course, there is another possible situation. You installed StoreLog 4, pat yourself on the back and say: “fine, no problems boss; I’ll have what you need by lunchtime.”
StoreLog4 to the rescue
StoreLog circumvents all of the drawbacks of Office365:
It’s automated: you can go on holiday, extended business trips or even just be occasionally forgetful.
It’s a robot and formats all PowerShell command parameters as necessary to get the multiple sets of 5000 messages.
It’s easy: one log per day in the right time order, which means no need to scan multiple files to find that particular message exchange.
It’s familiar: if you have used on-premise Message Tracking Logs, you’ll find the format is the same.
It’s graphical and enables you to retrieve messages easily by data range.
And of course last but not least, it’s free.
What to do with those Message Tracking Logs?
So once you’ve let StoreLog 4 do all the tedious work you have a much better range of options:
Archive the data for further processing.
Open the logs in a text editor to search for a particular subject or recipient.
Import them using StoreLog 4 into an Access or an SQL server database so you can use standard SQL queries to produce simple reports.
Import them using the next major version of PROMODAG Reports that will support Office 365.