Finding Exchange Mailbox Audit Data Isn’t So Easy Anymore

From an engineering perspective, Microsoft’s decision to decommission the Search-MailboxAuditLog and New-MailboxAuditLogSearch cmdlets makes a ton of sense. Microsoft 365 apps consume shared services, and the unified audit service ingests the data used by these Exchange Online cmdlets. Why incur the engineering and support expense to keep the old on-premises cmdlets going?

Microsoft posted the news on January 14, 2025, and stopped writing audit log data to mailboxes on March 1, 2025. The cmdlets will disappear at the end of 2025. You might have missed this information because Microsoft posted to the security blog instead of the Exchange EHLO blog, where all the other Exchange-related news appears. Perhaps this is because audit data is related to Microsoft Purview and the topic therefore is in the security space. However, losing cmdlets that might be used in Exchange-related administrative processes is a big deal deserving better awareness.

In 2016, Exchange mailbox audit data was one of the first sources of audit events for the unified audit log. Ever since, mailbox audit data has flowed into the unified audit log and can be found by audit log searches, so what’s the problem?

Searching the Unified Audit Log for Exchange Mailbox Audit Data

Searches of the unified audit log can be performed synchronously using the Search-UnifiedAuditLog cmdlet or asynchronously through the Audit section of the Purview compliance portal or by submitting a job through the Graph AuditLogQuery API. Audit log searches can find mailbox data among the many other forms of workload data ingested on an ongoing basis, and searches can go back 180 days (audit standard) or 365 days (audit premium). It all sounds good.

But people build processes around PowerShell cmdlets, and when a cmdlet disappears, those processes must be redeveloped. In this instance, any script that uses the deprecated cmdlets must be altered, probably to use the Search-UnifiedAuditLog cmdlet. And let’s face it, even its biggest fans (and I’m probably in that category) wouldn’t consider Search-UnifiedAuditLog to be an easy cmdlet to use, and Microsoft has tinkered with the way the cmdlet functions over the years. Thankfully, they’ve retreated from the idea of making high completeness (very slow) searches the norm.

The parameters for audit log searches can be complex to construct, duplicate audit records can be retrieved, and there’s always the need to unpack the JSON structure contained in the AuditData property to find out what actually happened for the auditable event.

Those accustomed to interacting with the AuditData property know that every workload decides what information to include in audit events and how that data is formatted. Extracting properties from AuditData usually isn’t hard, but it’s tiresome to see how many variations Microsoft engineers can come up with when inserting data into audit events.

Apart from the issue of interpreting audit events, there’s also the simple fact that it’s easier to extract audit data for the actions of a single user from their mailbox. Finding the relevant information about mailbox events from the unified audit log is more complicated.

Find Exchange Mailbox Audit Data for a Single Mailbox

The easiest way to find audit records for a specific mailbox with the Search-UnifiedAuditLog cmdlet is to pass the user principal name for the mailbox owner (or, to search multiple mailboxes, a set of user principal names) in the UserIds parameter. Here’s an example that finds the audit records for a mailbox and reduces the set to those belonging to Exchange actions:

$RecordType = "ExchangeAdmin","ExchangeItem","ExchangeItemAggregated","ExchangeItemGroup","ExchangeSearch"
[array]$Records = Search-UnifiedAuditLog -Userids ‘kim.akers@office365itpros.com' -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -Formatted -ResultSize 5000 -SessionCommand ReturnLargeSet
$Records = $Records | Where-Object {$_.RecordType -in $RecordType} | Sort-Object Identity -Unique

Searching based on user principal names finds audit records for actions performed by that user. If you want to find audit records for actions performed by a mailbox delegate, use a free text search for the object identifier of the mailbox owner’s account. The free text search finds references to the mailbox owner in the AuditData property and includes those records in the set returned. Here’s an example of using an account identifier in a free text search. It’s important that the identifier is cast as a string as otherwise the search will fail because it will attempt to use a GUID where the cmdlet expects a string:

[array]$Records = Search-UnifiedAuditLog -Freetext ((Get-ExoMailbox -Identity Tony.Redmond).ExternalDirectoryObjectId -as [string]) -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) -Formatted -ResultSize 5000 -SessionCommand ReturnLargeSet
$Records = $Records | Where-Object {$_.RecordType -in $RecordType} | Sort-Object Identity -Unique

The Bottom Line

You might not have been aware of the change to the old cmdlets. They still work (for now), but mailbox audit data generated since March 1, 2025, cannot be retrieved using the cmdlets. In any case, it’s a good idea to check scripts to find any instances where the old cmdlets are used. The bad news is that those scripts must be redeveloped. Good luck!