Mailbox Auditing in Exchange Server 2010 (and 2013)

Microsoft added the ability to audit mailbox actions in Exchange Server 2010 SP1 as part of its initiative to make Exchange capable of satisfying the compliance requirements of large organizations. Other compliance features added in Exchange 2010 include multi-mailbox discovery searches and search mailboxes, administrator auditing, and retention policies, all of which are continued on in Exchange Server 2013. Mailbox auditing complements search mailboxes in some respects because these mailboxes usually hold a lot of confidential information that has been extracted from user mailboxes. It's good to have the ability to audit access to these mailboxes to control appropriate access and operations. Mailbox auditing also addresses the common requirements of tracking access to other sensitive mailboxes (e.g., those used by executives) and answering the age-old question, "Who sent a particular message from a shared mailbox?"

After I describe how mailbox auditing is implemented in Exchange 2010 and later, I'll show you how to:

All the mailbox auditing features and commands described here work with an on-premises deployment of Exchange 2010 and with Exchange Online in Microsoft Office 365. They also work with Exchange 2013, with the difference being that you use the Exchange Administration Center (EAC) instead of Exchange 2010's ECP.

Understanding How Mailbox Auditing Is Implemented

Mailbox auditing in Exchange 2010 and later has the following characteristics:

Exchange 2010 and later versions store mailbox audit items in a hidden Audits subfolder in the Recoverable Items folder in the user's mailbox. No client can see the items in the Audits subfolder because it's hidden by Exchange. However, if you really want to, you can use a program such as MFCMAPI to see what the items look like.

The Recoverable Items folder seems like a regular folder. However, clients have to perform special processing whenever its contents are accessed to ensure that users can't interact with dumpster data that might be required for compliance purposes. Microsoft Outlook and Outlook Web App (OWA) expose a certain amount of information in the Recoverable Items folder through the Recover Deleted Items feature, which lists all the items in the Deletions subfolder in the Recoverable Items folder. Utilities such as MFCMAPI are able to expose more data by opening other subfolders (e.g., Purges, Versions), but they can't open the Audits subfolder. I think this is logical because you don't want to enable auditing for a mailbox only to discover that an administrator has used MFCMAPI afterward to wipe out the records that reveal some suspicious behavior.

Because mailbox auditing is configured on a per-mailbox basis, it makes sense for Exchange to store the audit items relating to a mailbox in the mailbox itself. Audit items therefore accumulate in the Audits subfolder. They remain there for 90 days (by default), after which they're removed by the Managed Folder Assistant. You can configure the retention period to be anything up to 24,855 days, but I imagine that the default is probably sufficient to perform occasional monitoring of mailbox access. Situations in which mailboxes are placed under litigation hold might require you to enable auditing for those mailboxes as well as to increase the audit retention period.

Audit items aren't large—typically between 1.5KB and 3KB each—so accumulating audit items for 90 days shouldn't create too much of an overhead for the mailbox. The space taken by the audit items isn't charged against a mailbox's quota.

If you're curious, the presence of the Audits subfolder can be seen using the Exchange Management Shell (EMS). For example, the following command scans the mailbox named VP Mailbox to look for any folder named Audits and reports the number of items and their size. A filter suppresses the display of data for any user-created folder that's also called Audits. The command is:

Get-MailboxFolderStatistics -Identity "VP Mailbox" |  ? {$_.Name -eq "Audits" -and $_.FolderType -eq "Audits"} |  Format-Table Identity, ItemsInFolder, FolderSize -AutoSize

As Figure 1 shows, there aren't a lot of audit items in this mailbox, so you can conclude that either auditing has only recently been enabled or this isn't a busy mailbox.

Figure 1: Finding Out the Number of Audit Items in a Mailbox's Audits Subfolder

Background knowledge about how Exchange is used in your environment is invaluable when it comes to interpreting information extracted from the server. Depending on the events being audited, a busy mailbox that's managed by a delegate might generate hundreds of audit items daily.

Enabling and Configuring Mailbox Auditing

Mailbox auditing isn't enabled by default, so the first thing you need to do is enable auditing for the mailboxes for which you need to collect data. In Exchange 2010, there isn't a GUI to control mailbox auditing in either the Exchange Management Console (EMC) or ECP. (The lack of a GUI continues in Exchange 2013.) Therefore, you need to use the Set-Mailbox cmdlet. For example, this command enables auditing for the mailbox named CEO Mailbox:

Set-Mailbox -Identity 'CEO Mailbox' -AuditEnabled $True

As soon as auditing is enabled on a mailbox, Exchange starts to generate audit items based on the mailbox's audit configuration. You can see the configuration by running the command:

Get-Mailbox -Identity 'CEO Mailbox' | Format-List Audit*

Figure 2 shows the output from this command. It tells you that auditing is enabled (AuditEnabled property) and Exchange will keep audit items for 90 days (AuditLogAgeLimit property).

Figure 2: Reviewing a Mailbox's Audit Configuration

The output also reveals the different actions that are being audited for the three levels of access that you can manipulate. (The actions in the output are truncated by PowerShell.) Exchange enables a default set of audit actions, which you can amend if needed.

The AuditAdmin property defines the administrative audit actions. These aren't actions such as an administrator logging on to a mailbox but rather actions such as importing messages into a mailbox from a PST.

AuditDelegate is the most interesting of the five properties because it controls auditing for delegates. A delegate is a user who isn't the primary owner of a mailbox but who has some level of access to open the mailbox and access its contents. For example, an administrative assistant might be given the rights to access a manager's calendar and send mail on behalf of the manager. A legal executive might be assigned full access to a discovery search mailbox so that he or she can review the items retrieved by a multi-mailbox search.

As you can see in Figure 2, the AuditDelegate property's default audit actions include SendAs. It's important to note that Exchange distinguishes between situations in which a delegate uses SendAs (send as if the delegate were the user) and SendOnBehalf (include an indication that someone else sent the message). These are two very different ways that a delegate can send a message for another user. Although the SendAs action is one of the default actions for AuditDelegate, the SendOnBehalf action isn't. So, if you want to audit both actions, you need to add SendOnBehalf to the list of actions. To do so, you can use the Set-Mailbox cmdlet to change the audit actions for the AuditDelegate property, like this:

Set-Mailbox -Identity 'CEO Mailbox' -AuditDelegate `  "Update, SoftDelete, HardDelete, SendAs, SendOnBehalf, `  MoveToDeletedItems, Copy"

The last property shown in Figure 2 is AuditOwner. Unsurprisingly, the default set of audit actions specified for the AuditOwner property is empty. This property controls the actions that are audited when the mailbox user accesses items. Auditing every user action will quickly generate a lot of items, so this level of auditing is best reserved for only when it's absolutely necessary.

Suppressing Audits for Specific Mailboxes

You might have situations in which you don't want to generate mailbox audit entries. The most common scenario is when you have a service account that has delegated access to many user mailboxes. For example, Research in Motion's BlackBerry Enterprise Server (BES) for Microsoft Exchange needs to access mailboxes to retrieve new mail to deliver to BlackBerry devices. It uses the same access to replicate operations executed on mobile devices back to mailboxes. The BES service account might generate many audit records daily, which could create a situation in which audit records that require further investigation are hidden by records belonging to a mass of totally innocent and mundane operations. To avoid this from happening, you can identify accounts that Exchange should ignore when auditing mailboxes by running the Set-MailboxAuditBypassAssociation cmdlet. For example, this command instructs Exchange to ignore any access by a service account named BESService:

Set-MailboxAuditBypassAssociation -Identity 'BESService' `  -AuditBypassEnabled $True

Obviously, it's not a good idea to have administrators run this cmdlet so that their own accounts are excluded from mailbox auditing. Exchange doesn't currently provide any method to block administrators from taking such an action, so all you can do is ensure that administrative auditing is enabled for the organization and that the Set-MailboxAuditBypassAssociation cmdlet is included in the audit configuration. For example, to include the cmdlet in the set audited by Exchange, you'd run a command similar to this:

Set-AdminAuditLogConfig -AdminAuditLogCmdlets `  "Set-MailboxAuditBypassAssociation, Set-Mailbox, `  New-Mailbox, *Transport*"

(Note that I chose an arbitrary set of cmdlets to audit here.)

Searching Mailbox Audit Data with PowerShell

Exchange 2010 and Exchange 2013 provide two EMS cmdlets to search mailbox audit data:

To use the Search-MailboxAuditLog cmdlet, you'd use a command like this:

Search-MailboxAuditLog -Identity Billing `  -LogonTypes Delegate -ShowDetails -StartDate "1/1/2012" `  -EndDate "1/31/2012" | ft Operation, OperationResult, `  LogonUserDisplayName, ItemSubject, LastAccessed, -AutoSize

In this instance, you're searching one mailbox, so you pass its name as a value to the -Identity parameter. If you want to search several mailboxes, you can replace the -Identity parameter with a comma-separated list of mailbox names passed to the -Mailboxes parameter.

There are a couple of interesting things that you can observe from the sample results in Figure 3.

Figure 3: Searching Audit Data

First, an attempt was made to delete an item, but that attempt failed. The item's subject isn't captured so you don't know exactly what happened here. However, this item serves to illustrate that all operations are logged when auditing is enabled, including those that fail.

Second, the bottom item reports that a message was sent from the mailbox using the SendAs permission. There's no problem with this. However, you can also see that the item was subsequently updated 17 days later. Those who have suspicious minds might wonder why this happened and contemplate whether it was an attempt to cover something up.

To investigate further, you could do another search to focus in on the suspect audit item. This time, you'd want to search for specific operations within a narrow date range by using a variant of the original EMS command:

Search-MailboxAuditLog -Identity Billing `  -LogonTypes Delegate -ShowDetails `  -StartDate "1/28/2012 11:59" -EndDate "1/28/2012 12:15" |  ? {$_.Operation -eq "Update"} | Format-Table

An edited version of the output is shown in Figure 4.

Figure 4: Investigating Why an Item Was Updated 17 Days After It Was Sent

You can now see that the item was updated in the Sent Items folder and that the TextBody property (i.e., the email message's body) was updated. You can also see that Outlook (or a program that calls Outlook's libraries, such as MFCMAPI) was used, along with the IP address of the computer that was used to make the update. This information should be sufficient to have a conversation with the user to clear up exactly what happened and why.

Administrative operations (e.g., deletion of items from a mailbox with the Search-Mailbox cmdlet) can be recognized because LogonType will be set to Admin in the audit items. For example, here's a command that searches the audit log entries for the CEO's mailbox to locate hard delete operations (i.e., those that permanently delete items):

Search-MailboxAuditLog -Identity 'CEO Mailbox' `-ShowDetails | ? {$_.Operation -eq "HardDelete"} |  Format-Table Operation, LastAccessed, LogonType, `  LogonUserDisplayName, FolderPathName, `  ItemSubject - AutoSize

As you can see in Figure 5, the results show that an administrator permanently removed one item from the Budgets folder.

Figure 5: Finding Hard Delete Operations

Unfortunately, through what can only be an oversight in the Exchange code, you're left hanging as to what that item was, because no information is provided about the subject to help you identify it. This omission wasn't addressed in Exchange 2013, but let's hope it'll be addressed in a future update.

One thing to be aware of is that audit items do not show up in searches straightaway. For some reason, possibly because of caching to ensure that server performance is not impacted or a bug in the search cmdlet, it takes some time before audit items are available to searches. I suspect a bug because the Get-MailboxFolderStatistics cmdlet reports that audit items exist once a client has had a chance to synchronize operations with the server. In any case, the exact delay varies. Sometimes items appear in a few minutes, sometimes it seems to take an hour or so. For this reason, don't depend on audit searches to report recent operations. Everything eventually settles down and searches for audit items older than six hours appear to be reliable. 

Reporting Audit Data with ECP

For those people who don't want to use PowerShell to retrieve audit data, Microsoft has provided some out-of-the-box reporting capability for mailbox audit data in the ECP. It's under the Roles and Auditing node of Manage My Organization, as Figure 6 shows. This reporting capability isn't perfect by any means, but it's all mouse-and-click driven.

Figure 6: Using ECP's Out-of-the-Box Reporting Capability for Mailbox Audit Data

By its very nature, a GUI is constrained by the imagination of its designers and the ability of the programmers who write the code. I don't think that the Exchange 2010 developers had an imagination deficit, but the allotted time and resources likely restricted their ability to deliver a fully developed reporting capability. The auditing reports are neither flexible enough nor detailed enough to satisfy true auditing requirements. Unfortunately, nothing changed in Exchange 2013, because the same reporting capability is provided in this version.

One of the available reports, the Non-Owner Mailbox Access Report, lets you search for operations performed in mailboxes by delegates and administrators. ECP displays the screen shown in Figure 7 to obtain the search criteria, such as the date range, the mailboxes to be searched, and the type of access.

Figure 7: Specifying the Search Criteria for the Non-Owner Mailbox Access Report

Interestingly, Office 365 tenants see an access type called External users, which refers to access performed by Microsoft data center administrators. The most popular search will likely be for Administrators and delegated users because it includes actions such as messages sent by delegates and items deleted in mailboxes. The screen is easy to navigate, and you can experiment with settings to see what output is produced by ECP. Remember to click the Search button after you change a setting to force ECP to perform a new search.

Behind the scenes, ECP invokes the Search-MailboxAuditLog cmdlet to retrieve the audit data. It displays the results in the lower right pane, as shown in Figure 8.

Figure 8: Reviewing the Retrieved Mailbox Audit Data

It'll probably take you a little time to become acquainted with the different kinds of audit data. I recommend that you enable auditing for a mailbox and perform a variety of searches in the mailbox to see what audit information is captured. This will help you interpret audit data more accurately.

For example, take a look at the two audit entries displayed in Figure 8. Both come from the Billing mailbox highlighted in the Mailbox selection pane on the left. The first audit entry reports that a user with delegate access performed a soft delete for an item in the Test folder. This entry is typical of what you'll see when a delegate user accesses a mailbox with Outlook or OWA and deletes a message (i.e., moves it to the Deleted Items folder). The second audit entry is for the same user, but this time the user has signed in without delegate access to perform an update. You'll see this kind of entry generated by administrative operations run through EMS. In this case, the user ran the Search-MailboxAuditLog cmdlet to perform a search and directed the output to a folder that didn't exist. Exchange created the folder and dutifully recorded that action because the folder was in a mailbox subject to auditing.

Getting Auditing Data for Heavily Loaded Servers

It's easy to retrieve auditing data for lightly loaded servers, but it can be quite a different matter for heavily loaded servers, where auditing is enabled on many mailboxes. Exchange provides the New-MailboxAuditLogSearch cmdlet for this purpose. (ECP also uses the New-MailboxAuditLogSearch cmdlet for its Export mailbox audit logs option.) Running New-MailboxAuditLogSearch forces Exchange to execute a background search and return the results in the form of an XML-formatted attachment that's emailed to the specified recipients. Take, for example, the following command:

New-Mailbox-AuditLogSearch `  -Name "Check for Delegated Sends" `  -LogonTypes Delegate `  -StartDate '1/1/2012' -EndDate '2/1/2012' `  -StatusMailRecipients "[email protected]"

In this case, no mailbox names are specified, so Exchange will search all mailboxes that have been enabled for auditing. (For an Office 365 search, you'd need to add -ExternalAccess $False or ExternalAccess $True to indicate whether you want to include audits for data center administrators.) The -StatusMailRecipients parameter specifies the email addresses of the recipients of the report in SMTP format. They can be internal recipients or external recipients to accommodate the situation where you might have to generate an audit report as part of a compliance action that's overseen by external legal advisors.

A mailbox assistant executes the command in the background, and the report eventually turns up in the inbox of the specified recipients. The delay is about 30 minutes in an on-premises deployment but much longer for Office 365. A test that I ran took nearly 12 hours to generate a report that arrived at 1:30 A.M., so Microsoft has probably tuned Office 365 to execute this kind of background processing at times of low system demand. Figure 9 shows a sample XML attachment.

Figure 9: Retrieving Mailbox Audit Data in XML Format

Although I have a high regard for the amazing things you can do with XML, I think the decision to provide mailbox audit reports in XML format is flawed. Most recipients won't be fluent in XML, so their first reaction on opening an XML attachment like the one in Figure 9 is likely to be terror rather than pleasure—if they're even able to open the XML attachment. Many clients block this format because of the havoc that can be wreaked by a malicious attachment.

Fortunately, there are better alternatives, but you'll need to use EMS. You can either:

No matter which approach you take, it'll take work to set up the solution. The solution will also require maintenance as Exchange service packs and new versions appear. At a minimum, you'll need to make sure that the code continues to run properly.

A Good Foundation for Mailbox Auditing

Microsoft has built a good foundation for mailbox auditing in Exchange 2010. Audit items are collected as you'd expect, and you have good control over audit configurations. The choice to store audit items in a mailbox is logical, and it's good to see that the items are automatically cleared out after a set period. All that's really limited is the reporting and, to some degree, the search functionality. It would be nice if these aspects of mailbox audit logging are addressed in a future version of Exchange. It's not in Exchange 2013, but perhaps something will come in "Exchange 16."