The Saga of the Elusive MailItemsAccessed Event
In January 2019, Microsoft announced that they were adding an event called MailItemsAccessed to the set of audited operations captured in the Office 365 audit log. Microsoft claimed that the new event would “capture details of when a message in a mailbox is opened by the mailbox owner, delegate (someone with read access to the mailbox) or using administrative access” leading to audit information delivering “comprehensive forensic coverage of mailbox accesses.”
Time moved on and in March 2019, Microsoft said that they had halted the deployment of MailItemsAccessed to Office 365 tenants. Software has a habit of hitting delays and it was speculated that the overhead involved in gathering a massive number of message access events would place a strain on Exchange Online.
All went quiet for a while, which prompted me to ask Microsoft in June what was happening. They provided an odd statement that faintly indicated that the MailItemsAccessed event might appear in Q3 (July to September).
Crucial Security or Compliance Audit Events
Q3 came and went without a trace of any message access being captured in the Office 365 audit log. But last month Microsoft released documentation for Advanced Audit in Microsoft 365 which makes it clear that MailItemsAccessed is now regarded as the first example of a “crucial” security or compliance-related audit event included in their advanced audit offering. Previously, Microsoft called these events “high-value.” In either case, Microsoft defines the event as “one that can help you investigate possible breaches or other forensic-related investigations.”
In a nutshell, if you want to see information about who accessed an item in a mailbox, you need to buy some Office 365 E5, Microsoft 365 E5 or Microsoft 365 E3 with Compliance licenses.
Some MailItemsAccessed records can be found in the Office 365 audit log for my tenant audit and viewed using the Search-UnifiedAuditLog cmdlet or the Audit log search (Figure 1). But all the records that have turned up so far (in about a month) are for “sync” activities for various folders like the Inbox. Sync records aren’t very exciting because all they record is the synchronization of a complete folder using a client like Outlook desktop. The really interesting data lie in bind records, which record access to individual messages.
It’s also interesting to learn that Exchange Online applies throttling for MailItemsAccessed events. If a mailbox generates more than 1,000 bind events in a 24-hour period, Exchange Online stops recording MailItemsAccessed events for bind operations for another 24 hours before resuming capture of these events. Microsoft says that less than 1% of mailboxes are subject to throttling.
Audit Log Retention Policies
Apart from capturing crucial audit events, the advanced audit feature also allows tenants to configure audit log retention policies. These policies work much like mailbox retention policies. You define a retention policy for selected audit events with a set retention period and Office 365 removes those items after that period. A tenant supports up to 50 audit log retention policies.
This example runs the New-UnifiedAuditLogRetentionPolicy cmdlet to create an audit retention policy to remove any SearchQueryPerformed event executed by the background app@sharepoint process after three months instead of the twelve-month retention of audit events if the tenant has E5 licenses.
New-UnifiedAuditLogRetentionPolicy -Name "90-day Retention SearchQueryPerformed by app@sharepoint" -Description "Remove SearchQueryPerformed events from the app@sharepoint process after 90 days" -RecordTypes SharePoint -Operations SearchQueryPerformed -UserIds "app@sharepoint" -RetentionDuration ThreeMonths -Priority 8
You can only manage audit log retention policies with PowerShell using cmdlets accessible by connecting to the Compliance Center endpoint.
Purging the Office 365 Audit Log
You can choose to apply retention for any of the events captured in the Office 365 audit log and keep them for three, six, nine, or twelve months. That is, you can keep audit events for longer than 90 days for accounts with E5 licenses. Office 365 restricts E3 accounts to a 90-day retention period, which is also the period for which you can search audit events in the Compliance Center. Searches earlier than this point must be done with the Search-UnifiedAuditLog PowerShell cmdlet.
It’s a good idea for tenants who either want precise control over how long audit data is retained or want to clean up events that don’t add much value in terms of investigations. SharePoint is a notoriously “chatty” application when it comes to the capture of audit events, so I can see why tenants might decide to keep important events like FileUploaded or FileAccessed for as long as possible while removing some of the chatter after 90 days.
I don’t have any issue with Microsoft classifying the MailItemsAccessed event as crucial and demanding a premium for its capture into the audit log. Only some tenants will be interested in these events and they might well have E5 licenses already. I can also see the sense of not imposing a huge overhead on Office 365 to capture these events for E3 tenants. It’s just a pity that the communication around the introduction of MailItemsAccessed and its evolution to become a crucial audit event has been so fractured and incoherent. Microsoft can do better.
We track developments in Office 365 auditing, including the kind of events you can extract from the audit log, in a chapter in the Office 365 for IT Pros eBook. Knowing what goes on in a tenant is important and the audit log holds the answers to many mysteries.