​To kick things off this year let’s take a look at mailbox audit logging, a very useful but under-utilized feature of Exchange Server 2010 SP1+ and Exchange Server 2013.

If you’re new to this topic you can see this overview:

Using Exchange Server 2013 Mailbox Audit Logging


In many organizations the Exchange Server administrator will encounter a situation where there is a need to determine who took action on an item in a mailbox. This will most often be about actions taken by delegates of a person’s mailbox, or people who use a shared mailbox.

For example:

  • An email message from a customer was never responded to, and the manager of the customer service team wants to know which person in the team move or deleted the message from the shared mailbox
  • Information sent to an executive via email has leaked, and there is an investigation into which of the executive’s delegates read the email message

Note that in these situations it is assumed that delegates or a team of people already have full access to the mailbox, or read-only access to the mailbox. Based on that assumption the focus is now on which of those people took action on specific mail items.

Exchange Server 2013 can log access to mailboxes by the owner, delegates, and administrators, using a feature called mailbox audit logging.

How Mailbox Audit Logging Works

When mailbox audit logging is enabled for a mailbox, audit log entries are stored in the Recoverable Items folder of the mailbox, which is not visible to the mailbox user via Outlook or other client interfaces.

Log entries are written for actions taken by the mailbox owner, delegates, or by administrators, depending on the audit logging configuration applied to the mailbox. The mailbox audit log entries are then retained for a configurable period of time.

Mailbox audit logging has the following default configuration in Exchange Server 2013:

  • Mailbox audit logging is disabled
  • Audit log entries are retained for 90 days
  • No owner actions are logged
  • Some delegate and administrator actions are logged

A default mailbox audit logging configuration for an Exchange 2013 mailbox looks like this:

[PS] C:>Get-Mailbox alan.reid | fl *audit*

AuditEnabled     : False
AuditLogAgeLimit : 90.00:00:00
AuditAdmin       : {Update, Move, MoveToDeletedItems, SoftDelete, HardDelete, FolderBind, SendAs, SendOnBehalf, Create}
AuditDelegate    : {Update, SoftDelete, HardDelete, SendAs, Create}
AuditOwner       : {}

Note: The AuditAdmin settings refer to access via mechanisms such as eDiscovery searches, mailbox import/export operations, or tools such as MFCMAPI. If an administrator is granted permission to a mailbox and accesses it then those actions will be logged according to the AuditDelegate settings.

Enabling/Disabling Mailbox Audit Logging

For mailboxes in your organization that you wish to enable audit logging on you can do so using the Set-Mailbox cmdlet.

[PS] C:>Set-Mailbox alan.reid -AuditEnabled $true

Typical candidates for mailbox audit logging are executives or VIPs who handle sensitive information, and who have delegates, or shared mailboxes used by teams of people.

In some organizations it may be preferable to enable mailbox audit logging for large numbers of mailbox users, or perhaps even all mailbox users. You can pipe the output of any Get-Mailbox query into Set-Mailbox to enable mailbox audit logging.

[PS] C:>Get-Mailbox -ResultSize Unlimited | Set-Mailbox -AuditEnabled:$true

If you need to ensure that mailbox audit logging is automatically enabled for all new mailboxes when they are created then you achieve that using the Scripting Agent.

For more information see:

Impact of Audit Logging on Mailbox Size

Mailbox audit log data is stored in a folder named Audits under the Recoverable Items folder of the mailbox, so it is hidden from the user. The default retention is 90 days, and some administrators may be concerned about the storage overhead for all of that audit logging data.

For more information on this see How Much Database Storage Does Mailbox Audit Logging Consume?

Searching Mailbox Audit Logs


Included are instructions on how to enable mailbox audit logging, and you can even automate this for newly created mailboxes using the Scripting Agent.

How to Automatically Enable Mailbox Audit Logging in Exchange Server

If your organization uses mailbox audit logging you will probably find it useful to automatically enable it when new mailboxes are created. This avoids the potential problem of mailboxes not being enabled manually when they are created by your help desk, and avoids you having to run regular scheduled scripts to enable auditing for new mailboxes.

This is achieved using the Scripting Agent, one of the cmdlet extension agents in Exchange Server 2013 and 2010.

If you have not already enabled the Scripting Agent you can find steps here. Don’t forget to distribute a ScriptingAgentConfig.xml file to all Exchange servers first.

To enable audit logging for new mailboxes create and distribute a ScriptingAgentConfig.xml file containing the following:


The important part is these lines, that will fire if the New-Mailbox or Enable-Mailbox cmdlet completes successfully. You can see that all it is really doing is running Set-Mailbox to enable auditing, just as you would manually in the Exchange management shell.

  If ($succeeded)
  	$Alias= $provisioningHandler.UserSpecifiedParameters["Alias"]
	$mailbox = Get-Mailbox $Alias
	Set-Mailbox $mailbox -AuditEnabled:$true

This config uses the Alias attribute of the mailbox, which is populated when a new mailbox is created.


When the mailbox creation process has completed you can verify that auditing has been enabled.

[PS] C:>Get-Mailbox Alannah.Shaw | fl auditenabled

AuditEnabled : True

And that is basically it. As you can see using the Scripting Agent to automate this task is quite simple, yet powerful, and saves you a lot of administrative burden.

Using Exchange Server Mailbox Audit Logs to Find the Sender of an Email from a Shared Mailbox

Consider a scenario where a shared “Help Desk” mailbox is used by a reasonably large team of IT staff, and they all have Send As permissions for the mailbox (for legitimate purposes such as sending out system outage and maintenance notifications).

One day a help desk operator has a brain fart and sends an email to the whole organization that causes some bad feedback.


Youve been tasked with finding the culprit and there are a few angles of investigation that you’re considering, such as finding the IP address that submitted the message and tracing that back to a workstation, trawling through sent items of help desk staff, or even just flat out asking people (this one works sometimes, don’t rule it out).

It would be a lot easier if Exchange could just tell you who sent the message.

The good news is that Exchange Server can tell you this (in Exchange 2010 SP1 or later, and Exchange 2013), using a feature called mailbox audit logging. The bad news (if you can call it that) is that the feature is not enabled by default, and needs to be turned on *before* the email is sent to capture the action in the audit log.

So, assuming mailbox audit logging is already enabled for the Help Desk mailbox, we can perform an audit log search to find out who took the Send As action at that time.

Performing Mailbox Audit Log Searches Using the Exchange Admin Center

In the Exchange admin center navigate to Compliance Management and choose Auditing. There are several items in that section but we’re interested in “Run a non-owner mailbox access report” in this case.


Set the date range you’re interested in, and then click on Select Mailboxes to add the specific mailbox you want to search. Finally, set the search type to “All non-owners”, and then click Search to begin.


After a few moments your search results should appear. If you’ve picked a large date range, or a mailbox with a lot of non-owner activity, then you may have quite a lot of results to scroll through.

But for this example we can see that someone has in fact performed a “Send As” on the date in question, with the matching subject line of the email that causes all the fuss to begin with. So it seems we have our culprit, caught red handed, thanks to mailbox audit logging.

Performing Mailbox Audit Log Searches Using the Exchange Management Shell

Naturally we can also perform this search using PowerShell and the Search-MailboxAuditLog cmdlet.

For example, to search the “Help Desk” mailbox audit logs between the 13th and 15th of January 2014, the following command is used.

[PS] C:>Search-MailboxAuditLog -Identity "Help Desk" -LogonTypes Delegate -StartDate 1/14/2014 -EndDate 1/15/2014

RunspaceId               : d8142847-166a-488a-b668-f7b84c3f3ceb
MailboxGuid              : a0f10db1-5268-47a5-8f71-d1e65f55c653
MailboxResolvedOwnerName : Help Desk
LastAccessed             : 14/01/2014 9:31:08 PM
Identity                 : Desk
IsValid                  : True
ObjectState              : New

We can see a result, and the time stamp matches the email message that was sent, but little else is shown about the event. To see more we need to use the -ShowDetails parameter.

[PS] C:>Search-MailboxAuditLog -Identity "Help Desk" -LogonTypes Delegate -StartDate 1/14/2014 -EndDate 1/15/2014 -Sho

RunspaceId                    : d8142847-166a-488a-b668-f7b84c3f3ceb
Operation                     : SendAs
OperationResult               : Succeeded
LogonType                     : Delegate
ExternalAccess                : False
DestFolderId                  :
DestFolderPathName            :
FolderId                      :
FolderPathName                :
ClientInfoString              : Client=MSExchangeRPC
ClientIPAddress               :
ClientMachineName             :
ClientProcessName             : OUTLOOK.EXE
ClientVersion                 : 15.0.4551.1004
InternalLogonType             : Owner
MailboxOwnerUPN               :
MailboxOwnerSid               : S-1-5-21-2175008225-1847283934-4039955522-1471
DestMailboxOwnerUPN           :
DestMailboxOwnerSid           :
DestMailboxGuid               :
CrossMailboxOperation         :
LogonUserDisplayName          : Sarah Jones
LogonUserSid                  : S-1-5-21-2175008225-1847283934-4039955522-1471
SourceItems                   : {}
SourceFolders                 : {}
SourceItemIdsList             :
SourceItemSubjectsList        :
SourceItemFolderPathNamesList :
SourceFolderIdsList           :
SourceFolderPathNamesList     :
ItemId                        :
ItemSubject                   : Wheeee!
DirtyProperties               :
OriginatingServer             : E15MB1 (15.00.0775.022)
MailboxGuid                   : a0f10db1-5268-47a5-8f71-d1e65f55c653
MailboxResolvedOwnerName      : Help Desk
LastAccessed                  : 14/01/2014 9:31:07 PM
Identity                      : RgAAAAD2fF/dZobvQoWbbV7P6N7eBwD7Y5OF+DDRQZRz1a4+yUyzAABaldDBAAD7Y5OF+DDRQZRz1a4+yUyzAAB
IsValid                       : True
ObjectState                   : New

As you can see we get the same information that reveals the sender of the email message, as well as some extra info that may be useful as well.


In this article I’ve used a common scenario to demonstrate the value of mailbox audit logging, as well as demonstrating how to perform simple mailbox audit log searches. Hopefully by now you can see the value of mailbox audit logging and are considering enabling it in your organization, even if only for your most important/shared mailboxes.



Category: Servers; How to do
Published: 1/17/2014 10:39