Table of Contents
Useful but Aging Cmdlet
I’m bemused when I see sites treat the Get-MailTrafficSummaryReport cmdlet as if it has some magical powers, like proclaiming it to be one of the top 10 cmdlets for email monitoring. The sad fact is that although the cmdlet is useful, it has aged without much progression over the last few years, which might be why Microsoft attempted to retire it in 2021. That venture failed because of customer feedback, but I’m insure why people feel so strongly about the cmdlet.
Summarizing Message Trace Data
Essentially, the Get-MailTrafficSummaryReport cmdlet takes the message trace data retained by Exchange Online for the last 90 days (give or take a day or two depending on background processing) and summarizes the data under various categories. The most popular are:
- TopMailSender: Report the number of messages sent by different mail-enabled objects, including user mailboxes, shared mailboxes, and guest accounts. Separate counts are given for each proxy address assigned to a mail-enabled object.
- TopMailRecipient: Report the number of messages received by different proxy addresses for mail-enabled recipients. As for senders, separate counts are available for each proxy address assigned to a mailbox.
- TopMalware: Report malware (like Win32/Tnega.SM!MTB) detected in inbound messages.
- TopSpamRecipient: Report the number of spam messages intercepted for mail-enabled recipients. I use different test accounts for articles. Within a week of publishing a test account’s email address in an article, I know that spam begins to arrive for that account. The report also shows spam addressed to mail-enabled recipients that no longer exist, like mailboxes belonging to deleted accounts.
- TopMalwareRecipient: Like spam, but these messages are deemed by Exchange Online Protection to contain malware.
- InboundTransportRuleHits: Report the transport rules which process inbound email. The report lists the individual rules and the number of messages processed by each rule. You can filter by the name of one or more transport rules by passing the names of the rules in the TransportRule parameter.
- OutboundTransportRuleHits: Report transport rules which process outbound email.
The cmdlet supports reporting for Data Loss Prevention (DLP) rule hits. I don’t use categories like OutboundDLPPolicyRuleHits (DLP rules detected a policy violation in an outbound email) as much as the categories listed above.
The statistics generated by the cmdlet come from a data warehouse. As such, the information is not real-time in the same way that running Get-MessageTrace can report the progress of a message sent a few seconds ago. Having a time lag for usage data isn’t unusual within Microsoft 365. The normal delay before data becomes available is around two days.
Example of Get-MailTrafficSummaryReport
Most articles covering Get-MailTrafficSummaryReport focus on the top senders and top recipients reports. Looking at something different, here’s how to run a report for outbound messages processed by transport rules. The outbound shows that the transport rule to apply a disclaimer to responses for calendar meeting requests is the most popular in my tenant.
Get-MailTrafficSummaryReport -Category OutboundTransportRuleHits -StartDate $StartDate -EndDate $EndDate | Select-Object C1, C2, C3 C1 C2 C3 -- -- -- Calendar Disclaimer SetAuditSeverityLow 201 Automatic BCC SetAuditSeverityLow 22 Block Email to Tenant Admin Accounts SetAuditSeverityLow 11 Block Power Automate SetAuditSeverityLow 7
The cmdlet output uses C1, C2, and C3 (columns 1, 2, and 3) as non-specific header names because the various reports generate different pieces of data. Sometimes C1 is used for email addresses, and sometimes, like in this example, for the names of transport rules.
Alternatives
The alternatives to using the Get-MailTrafficSummaryReport cmdlet include:
- Export message trace information to an external repository like Splunk. Organizations do this to retain data for longer than the 90 days supported by Microsoft and to gain more sophisticated querying capabilities. Here’s an example of a script written to extract large quantities of message trace data.
- Use the Microsoft Graph reports API to work with the same data as appears in the usage reports in the Microsoft 365 admin center. The data is limited to a 90-day horizon and the email usage data is nowhere near as comprehensive as message trace data and doesn’t include access to data about spam, malware, and rule-based activity. The major advantage of this approach is the ability to build a picture of overall user activity across multiple Microsoft 365 workloads.
My bet is that Microsoft’s focus will be on Graph-based usage reporting. It’s likely they will try to deprecate the Get-MailTrafficSummaryReport cmdlet in the future. With that in mind, I don’t plan to spend much time on this cmdlet going forward as I don’t anticipate any change in coverage or functionality. But if Get-MailTrafficSummaryReport does a job for you, continue using it until the future direction becomes apparent.
Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.