Table of Contents
If You Have Office 365 E3 Licenses, Check the Flow of Mailbox Audit Events
A reader contacted me to report some problems that a compliance exercise had thrown up when it was discovered that the Office 365 audit log did not contain mailbox audit records for some Exchange Online mailboxes. As it turned out, all the affected mailboxes belonged to Azure AD accounts with Office 365 E3 licenses. Not having some expected mailbox audit events available in the audit log is not a great situation for any compliance officer or tenant administrator to find themselves in.
When the customer organization contacted Microsoft support, they were told that a bug existed in Exchange Online that stops the AuditEnabled setting being accurately reported for mailboxes with Office 365 E3 licenses. When administrators examined the setting with the Get-Mailbox or Get-ExoMailbox cmdlets, Exchange Online reported $True, meaning that auditing is enabled for the mailbox:
Get-ExoMailbox -Identity Brian.Weakliam -Properties AuditEnabled | Format-Table DisplayName, AuditEnabled DisplayName AuditEnabled ----------- ------------ Brian Weakliam (Operations) True
However, the mailbox audit events remain in Exchange Online and never make it into the Office 365 audit log. Everything works perfectly for mailboxes assigned Office 365 E5 licenses.
What Microsoft Says
Microsoft’s documentation says:
Although mailbox audit logging on by default is enabled for all organizations, only users with E5 licenses will return mailbox audit log events in audit log searches in the Microsoft Purview compliance portal (Figure 1) or via the Office 365 Management Activity API by default.
The page also says:
Even when mailbox auditing on by default is turned on for your organization, you might notice that mailbox audit events for some users aren’t found in audit log searches by using the compliance center, the Search-UnifiedAuditLog cmdlet, or the Office 365 Management Activity API. The reason for this is that mailbox audit events will be returned only for users with E5 licenses when you [use] one of the previous methods to search the unified audit log.
Apparently, Microsoft doesn’t consider it a bug when audit data from mailboxes with Office 365 E3 licenses doesn’t reach the Office 365 audit log. The justification is that:
- The audit events are available in Exchange Online (in the Audits folder in the Recoverable Items part of each mailbox) and can be found there.
- If the organization wishes to ingest the audit events into the Office 365 audit log, all they need to do is run the Set-Mailbox cmdlet to update the AuditEnabled setting to $True. In other words, the $True value reported by Exchange Online is accurate because it reports that mailbox events are available. Running Set-Mailbox to update the setting to $True (again) doesn’t change anything (the setting is still $True) but Exchange Online takes the hint and will ingest mailbox events into the Office 365 audit log thereafter.
Clearly, this is a non-optimal situation. I wrote about the same issue in March 2020 when Microsoft rolled out mailbox auditing by default across Exchange Online. It seems like the same documentation is online and people are still running into problems. And that this Exchange Online functionality hasn’t progressed much since.
Audit Events Appear to Flow for New Mailboxes
Or has it? I created a couple of new Azure AD accounts and assigned them Office 365 E3 licenses and then signed into each mailbox to perform several actions that I knew should generate audit records. After waiting 30 minutes to allow ingestion to occur, I ran the Search-UnifiedAuditLog cmdlet to see if any events existed in the Office 365 audit log. They were!
[array]$records = Search-UnifiedAuditLog -StartDate 18-Aug-2022 -EndDate 19-Aug-2022 -Formatted -userids michael.king@office365itpros.com $records | ft creationdate, operations CreationDate Operations ------------ ---------- 18/08/2022 12:54:31 SoftDelete 18/08/2022 12:54:23 MoveToDeletedItems 18/08/2022 12:54:19 SoftDelete 18/08/2022 12:53:19 SoftDelete 18/08/2022 12:53:14 MoveToDeletedItems
This result is exactly what you’d hope to see. No administrator intervention was necessary to have events flow from Exchange Online to the Office 365 audit log. I obtained the same results with mailboxes in another tenant. I asked Microsoft about the issue and learned that mailbox auditing was enabled by default because of the configuration of the Exchange Online forest that hosts the mailboxes. For performance reasons (to reduce the number of audit events processed by Office 365), this is not the situation for every Exchange Online forest. This is why Microsoft’s documentation recommends that you should re-enable auditing for the E3 mailboxes to force ingestion of audit events for these mailboxes into the Office 365 audit log.
The conclusion is there might be many mailboxes with Office 365 E3 licenses running in tenants around the world that don’t feed data into the Office 365 audit log. The only solution is to run Set-Mailbox. And you might as well run the cmdlet for all mailboxes with Office 365 E3 licenses just to be sure.
The script included in my previous post will do the job of finding mailboxes with Office 365 E3 licenses and updating their audit settings. The script uses the Get-AzureADUser cmdlet to find the relevant accounts. If you’ve switched to the Microsoft Graph PowerShell SDK, the updated code is:
[array]$Mbx = Get-MgUser -filter "assignedLicenses/any(s:s/skuId eq $Office365E3)" -All
Good for the Future?
If you use Office 365 E3 licenses, be sure to check that mailbox auditing works as you expect. It’s odd that Microsoft forces customers to go through the additional step to enable auditing for mailboxes that appear to be already enabled for auditing, but that’s the way the system works.
Make sure that you’re not surprised about changes that appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.