Export (0) Print
Expand All
8 out of 10 rated this helpful - Rate this topic

Understanding Mailbox Access Auditing with Exchange Server 2007 Service Pack 3

 

Applies to: Exchange Server 2007 SP2

Topic Last Modified: 2012-03-26

Access Auditing is implemented in the Microsoft Exchange Store.exe process, which is the access point for mail in mailbox databases. Access Auditing represents a set of Event log events that are designed to give administrators information about mailbox resources that have been opened by users. These events are new. They do not modify existing events, which may be used for other purposes.

Access Auditing is enabled by a set of Diagnostics Logging categories for the Microsoft Exchange IS resource, with each category corresponding to a different type of resource access. Each category can be enabled independently. This allows an administrator to choose the level of information (and the corresponding load from recording it) that is appropriate for the particular organization.

The Diagnostics Logging categories include the following:

  • Folder Access: lets you log events that correspond to opening folders, such as the Inbox, the Outbox, or the Sent Items folders
  • Message Access: lets you log events that correspond to explicitly opening messages
  • Extended Send As: lets you log events that correspond to sending a message as a mailbox-enabled user
  • Extended Send On Behalf Of: lets you log events that correspond to sending a message on behalf of a mailbox-enabled user

Each category supports logging levels from zero (not enabled) to five (maximum logging). Higher logging levels increase the amount and detail of logged data.

The Microsoft Exchange Information Store service supports Windows NT Audit events based on system policy. These events reflect each instance of an opened object, and are recorded in the Security event log. This kind of logging is the highest auditing level that is available, and offers extensive records of object access. The goal of Access Auditing is not to replace Windows auditing. Windows auditing focuses on object open and object close events. Access Auditing implicitly ignores certain object events in favor of events that represent real user data that is being accessed.

Consider the following example:

With Windows auditing, the primary focus is "Logons to Mailbox." In Exchange, a logon event is the act of binding to data that then lets the client try to open folders. The logon object itself does not grant access to specific data. There, it represents a false focal point for auditing.

Access Auditing focuses on events that reflect a client gaining access to actual messaging data, or exercising rights that affect messaging data. For example:

  • By opening a folder, the client gains access to actual data.
  • By opening a message, the client gains access to actual data.

Logging on to a mailbox is an implicit operation to gain access to the folder. Access Auditing lets you disregard operations that occur below the IPM subtree, such as free/busy cache lookup operations. Also, Access Auditing ignores access by Exchange system processes. Access Auditing can also log only a particular class or classes of access. The tradeoffs between Windows auditing and Access Auditing are in the configuration process. Windows Auditing can be set by policy. Access Auditing is controlled by diagnostic categories for the Microsoft Exchange information store.

importantImportant:
Access Auditing does not audit message deletions, only message access.

The volume of logged audit events is directly related to the load on a server together with the number of user operations of the audited type occurring at any time. Because the Application log is also a source of diagnostic and troubleshooting data, Access Auditing does not log events to the Application log. In Exchange 2007 Service Pack 3 (SP3), installing the Mailbox server role on a server creates a new event log. This is the Exchange Auditing event log. By default, the Exchange Auditing event log is located under \Exchange Server\Logs\AuditLogs. On a Windows Server 2008-based computer, this event log is located under Applications and Services Logs\Exchange Auditing. The default file location for this log file is %PROGRAMFILES%\Exchange Server\Logging\Auditlogs. The default access control list (ACL) on the Exchange Auditing log allows the following permissions:

  • Exchange Recipient Administrators: Read and Clear access
  • Exchange Organization Administrators: Read and Clear access
  • Exchange Servers: Read and Write access
  • Local Service All Access

To change the default ACL list, you have to update the CustomSD value in the registry. Update the CustomSD value to include the group or user that you want to access the Exchange Auditing Event Log. The CustomSD value is located under the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Exchange Auditing

noteNote:
The ACL that is stored in the CustomSD value is stored in SDDL format. For more information about how to change the permissions on Windows Event Logs and more information about SDDL formats, view the topic Event Log.

To obtain a user or group SID value, use the PsGetSid tool from Windows Sysinternals. For more information about this tool, see PsGetSid v1.43.

Or, you can use PowerShell to obtain the SID. For example, to obtain the SID for a user, use the following command:

$objUser = New-Object System.Security.Principal.NTAccount("Exchange Organization Administrators")

$strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])

$strSID.Value

For events that represent access by one user to another user's mailbox, the following general guidelines describe which events are logged at each diagnostic logging level:

  • At logging level zero (0), nothing is logged.
  • At logging level one (1), only actions for which the acting user invoked administrative privileges are logged.
  • At logging level two (2) and four (4) only access from one mailbox-enabled user to another mailbox is logged.
  • At logging level three (3) and five (5) access from any user to any mailbox is logged.

Auditing events that reflect actions that are based on a user's logon expose a common set of information. Extended client data is only available when the program supports sending extended client data. Outlook 2003 and later versions of Outlook send extended client data.

Folder Access events indicate the successful opening of a folder in a mailbox. Folder Access auditing provides different events at different auditing levels. This lets an administrator select the appropriate logging level for his or her auditing requirements. The following list describes the events that are logged at each logging level:

  • At level zero (0) nothing is logged. At this logging level, no events are logged in response to folder access.
  • At level one (1) only access using Administrative rights is logged.
  • At logging level two (2) and four (4) only access by one mailbox-enabled user to another mailbox-enabled user is logged.
  • At logging level three (3) and five (5) access to folders by any user is logged.

The mailbox folder hierarchy consists of a non-IPM subtree, which houses folders for application use, such as search folders, together with an IPM subtree which houses folders that are viewed and used by users, such as the Inbox or Sent Items folders. Basic events represent typical access to the folders that the user sees. These folders are generally defined as "mail folders." Access to a folder is logged at the basic level if the folder is a child folder of the IPM subtree. All Events logging includes the folders that are not visible to the user, such as the mailbox root folder and non-IPM subtree folders. Administrators who want to audit access to "mail folders" such as the Inbox folder, Sent Items folder, or Drafts folder do not have to enable higher level event logging. The following table illustrates the events that are logged at each logging level for the Folder Access category.

Category: Folder Access

 

Logging level Administrator rights required Acting user Mailbox Result

0

Not applicable

Not applicable

Not applicable

Nothing

1

No

Not applicable

Not applicable

Nothing

1

Yes

Not applicable

Not applicable

Basic events

2

Not applicable

UserA

UserA

Nothing

2

Not applicable

UserA

UserB

Basic events

3

Not applicable

UserA

UserA

Basic events

3

Not applicable

UserA

UserB

Basic events

4

Not applicable

UserA

UserA

Nothing

4

Not applicable

UserA

UserB

All events

5

Not applicable

UserA

UserA

All events

5

Not applicable

UserA

UserB

All events

When Folder Access auditing is enabled, events that resemble the following are logged:

 

Event Id:10100

Severity: Informational

Facility: AccessAuditing

The folder %1 in Mailbox '%3' was opened by user %4

Display Name:%2

Accessing User: %5

Mailbox: %6

Administrative Rights:%7

Identifier:%8

Client Information (if Available):

Machine Name: %9

Address: %10

Process Name: %11

Process Id: %12

Application Id: %13

The parameters in this event message represent the following items:

  • %1 represents the URL name of the folder. This provides you with the full path of the folder.
  • %2 represents the display name of the folder. You can use the display name together with the folder path to differentiate between multiple folders that have the same name.

Common Audit Event Information:

  • %3 represents the legacyDN of the opened mailbox.
  • %4 represents the user name of the user who authenticated to the information store.
  • %5 represents the legacyDN of the user who opened the object.
  • %6 represents the legacyDN of the mailbox.
  • %7 is a flag that indicates whether administrator rights were used to open the folder.
  • %8 is a relatively unique identifier. You can use this parameter to correlate a series of actions over a short period.

Client Information:

  • %9 represents the computer name.
  • %10 represents the address as composed by the client. This value is dependent on the protocol that was used to connect to the server. Local connections (connections from the same computer) use the computer name. Exchange binary files send the IPV6 address, if possible and the IPV4 address if they cannot send the IPV6 address. If an IP address is sent, it represents the IP address as the client identifies it. For clients behind a NAT gateway, the IP address may not provide a distinguishing address.
  • %11 represents the process name. This is the application binary file that made the call to access the object.
  • %12 represents the process ID (PID). This is a numeric identifier for the particular process.
  • %13 represents the application ID. This is a value that the client sets to allow differentiation between instances of Powershell.exe. Or, an event to allow an add-in in a process to be labeled as an add-in during operations to access the server.

Example folder access event log entry

 

Log name: Exchange Auditing

Source: MSExchangeIS Auditing

Event ID: 10100

Task Category: Mailbox Access Auditing

Level: Information

Keywords: Classic

Description: The folder /Inbox in Mailbox 'UserA' was opened by user CONTOSO\UserB

Display Name: Inbox

Accessing User: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB

Administrative Rights: false

Identifier: 00000000318A00E0

Client Information (if Available)

Machine Name: <ClientName>

Address: <IP Address>

Process Name: OUTLOOK.EXE

Process Id: 0

Application Id: N/A

Message Access events indicate the successful opening of a message in the Exchange information store. Messages do not support Basic Events. All message access is audited based on the logging level that is set by the administrator. The following table illustrates the events that are logged at each logging level for the Message Access category.

Category: Message Access

 

Logging level Administrator rights required Acting user Mailbox Result

0

Not applicable

Not applicable

Not applicable

Nothing

1

No

Not applicable

Not applicable

Nothing

1

Yes

Not applicable

Not applicable

Basic events

2

Not applicable

Not applicable

Not applicable

Not applicable

2

Not applicable

Not applicable

Not applicable

Not applicable

3

Not applicable

Not applicable

Not applicable

Not applicable

3

Not applicable

Not applicable

Not applicable

Not applicable

4

Not applicable

UserA

UserA

Nothing

4

Not applicable

UserA

UserB

All events

5

Not applicable

UserA

UserA

All events

5

Not applicable

UserA

UserB

All events

When Message Access auditing is enabled, events that resemble the following are logged:

 

Event ID:10102

Severity: Informational

Facility: AccessAuditing

The message %1 in Mailbox %3 was opened by user %4

Folder: %2

Accessing User: %5

Mailbox: %6

Administrative Rights:%7

Identifier:%8

Client Information (if Available):

Machine Name: %9

Address: %10

Process Name: %11

Process Id: %12

Application Id: %13

The parameters in this event message represent the following items:

  • %1 represents the Internet Message ID of the message being opened.
  • %3 represents the mailbox where the message is saved.
  • %4 represents the user who authenticated to the information store.
  • %5 represents the legacyDN of the user who opened the message.
  • %6 represents the legacyDN of the mailbox.
  • %7 is a flag that indicates whether administrator rights were used to open the message.
  • %8 is a relatively unique identifier which can be used to correlate a set of actions over a short period.

Client Information

  • %9 represents the computer name.
  • %10 represents the address as composed by the client. This value is dependent on the protocol that was used to connect to the server. Local connections (connections from the same computer) use the computer name. Exchange binary files send the IPV6 address, if possible and the IPV4 address if they cannot send the IPV6 address. If an IP address is sent, it represents the IP address as the client identifies it. For clients behind a NAT gateway, the IP address may not provide a distinguishing address.
  • %11 represents the process name. This is the application binary file that made the call to access the object.
  • %12 represents the process ID (PID). This is a numeric identifier for the particular process.
  • %13 represents the application ID. This is a value that the client sets to allow differentiation between instances of Powershell.exe. Or, an event to allow an add-in in a process to be labeled as an add-in during operations to access the server.

Example message access event log entry

 

Log name: Exchange Auditing

Source: MSExchangeIS Auditing

Date: <date>

Event ID: 10102

Task Category: Mailbox Access Auditing

Level: Information

Keywords: Classic

Description: The message <BA15978123F9C848B820A8C5C1DC29B5F06B6F@Server.Contoso.com> in Mailbox UserA was opened by user CONTOSO\UserB

Folder: /Inbox

Accessing User: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB

Administrative Rights: false

Identifier: 00000000318A00E0

Client Information (if Available)

Machine Name: <ClientName>

Address: <IP Address>

Process Name: OUTLOOK.EXE

Process Id: 0

Application Id: N/A

Extended Send As events indicate that one user sent a message as another user. Extended Send As events do not support Basic events and only apply when one user sends a message as another user. At logging level one (1), an event is only recorded if the user used administrator privileges to open the mailbox, and then sent a message as another user. At logging level five (5), an event is recorded if one user sends a message as another user. The following table illustrates the events that are logged at each logging level for the Extended Send As category.

Category: Extended Send As

 

Logging level Administrator rights required Acting user Mailbox Result

0

Not applicable

Not applicable

Not applicable

Nothing

1

No

UserA

UserA

Not applicable

1

Yes

UserA

UserB

All events

2

Not applicable

Not applicable

Not applicable

Not applicable

2

Not applicable

Not applicable

Not applicable

Not applicable

3

Not applicable

Not applicable

Not applicable

Not applicable

3

Not applicable

Not applicable

Not applicable

Not applicable

4

Not applicable

Not applicable

Not applicable

Not applicable

4

Not applicable

Not applicable

Not applicable

Not applicable

5

Not applicable

UserA

UserA

Not applicable

5

Not applicable

UserA

UserB

All events

When Extended Send As auditing is enabled, events that resemble the following are logged:

 

Event Id:10106

Severity: Informational

Facility: SendAs

%1 sent a message as %2

Message Id:%3

Account Name: %4

Accessing User: %5

Mailbox: %6

Administrative Rights:%7

Identifier:%8

Client Information (if Available):

Machine Name: %9

Address: %10

Process Name: %11

Process Id: %12

Application Id: %13

The parameters in this event message represent the following items:

  • %1 represents the legacyDN of the sending user.
  • %2 represents the legacyDN of the user who was Sent As.
  • %3 represents the Internet message ID of the message.
  • %4 represents the user who authenticated to the information store.
  • %5 represents the legacyDN of the accessing user.
  • %6 represents the legacyDN of the mailbox.
  • %7 is a flag that indicates whether administrative rights were used to send the message.
  • %8 is a relatively unique identifier that can be used to correlate events over a short period.

Client Information

  • %9 represents the computer name.
  • %10 represents the address as composed by the client. This value is dependent on the protocol that was used to connect to the server. Local connections (connections from the same computer) use the computer name. Exchange binary files send the IPV6 address, if possible and the IPV4 address if they cannot send the IPV6 address. If an IP address is sent, it represents the IP address as the client identifies it. For clients behind a NAT gateway, the IP address may not provide a distinguishing address.
  • %11 represents the process name. This is the application binary file that made the call to access the object.
  • %12 represents the process ID (PID). This is a numeric identifier for the particular process.
  • %13 represents the application ID. This is a value that the client sets to allow differentiation between instances of Powershell.exe. Or, an event to allow an add-in in a process to be labeled as an add-in during operations to access the server.

For more information about how to grant the Send As permission, see How to Grant the Send As Permission for a Mailbox.

Example Send As event log entry

 

Log name: Exchange Auditing

Source: MSExchangeIS Auditing

Date: <date>

Event ID: 10106

Task Category: Send As

Level: Information

Keywords: Classic

Description: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB sent a message as /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserA

Message Id: <BA15978123F9C848B820A8C5C1DC29B5038E9D50@Server.Contoso.com>

Mailbox: UserB

Account Name: CONTOSO\UserB

Accessing User: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB

Mailbox:<NULL>

Administrative Rights: false

Identifier: 00000000317A7130

Client Information (if Available)

Machine Name: <ClientName>

Address: <IP Address>

Process Name: OUTLOOK.EXE

Process Id: 0

Application Id: N/A

Extended Send On Behalf Of events indicate that one user sent a message on behalf of another user. Extended Send On Behalf Of events do not support Basic events and are only applicable when one user sends a message on behalf of another user. At level one (1), an event is recorded only if the user used administrator privileges to open a mailbox and then send a message on behalf of another user. At logging level five (5), an event is logged if one user sends a message on behalf of another user. The following table illustrates the events that are logged at each logging level for the Extended Send On Behalf Of category.

Category: Extended Send On Behalf Of

 

Logging level Administrator rights required Acting user Mailbox Result

0

Not applicable

Not applicable

Not applicable

Nothing

1

No

UserA

UserA

Not applicable

1

Yes

UserA

UserB

All events

2

Not applicable

Not applicable

Not applicable

Not applicable

2

Not applicable

Not applicable

Not applicable

Not applicable

3

Not applicable

Not applicable

Not applicable

Not applicable

3

Not applicable

Not applicable

Not applicable

Not applicable

4

Not applicable

Not applicable

Not applicable

Not applicable

4

Not applicable

Not applicable

Not applicable

Not applicable

5

Not applicable

UserA

UserA

Not applicable

5

Not applicable

UserA

UserB

All events

When Extended Send On Behalf Of auditing is enabled, events that resemble the following are logged:

 

Event Id:10104

Severity: Informational

Facility: SendOnBehalfOf

%1 sent a message on behalf of %2

Message Id:%3

Account Name: %4

Accessing User: %5

Mailbox: %6

Administrative Rights:%7

Identifier:%8

Client Information (if Available):

Machine Name: %9

Address: %10

Process Name: %11

Process Id: %12

Application Id: %13

The parameters in this event message represent the following items:

  • %1 represents the legacyDN of the sending user.
  • %2 represents the legacyDN of the user who was Sent On Behalf Of.
  • %3 represents the Internet message ID of the message.
  • %4 represents the user who authenticated to the information store.
  • %5 represents the legacyDN of the accessing user.
  • %6 represents the legacyDN of the mailbox.
  • %7 is a flag that indicates whether administrative rights were used to send the message.
  • %8 is a relatively unique identifier that can be used to correlate events over a short period.

Client Information

  • %9 represents the computer name.
  • %10 represents the address as composed by the client. This value is dependent on the protocol that was used to connect to the server. Local connections (connections from the same computer) use the computer name. Exchange binary files send the IPV6 address, if possible and the IPV4 address if they cannot send the IPV6 address. If an IP address is sent, it represents the IP address as the client identifies it. For clients behind a NAT gateway, the IP address may not provide a distinguishing address.
  • %11 represents the process name. This is the application binary file that made the call to access the object.
  • %12 represents the process ID (PID). This is a numeric identifier for the particular process.
  • %13 represents the application ID. This is a value that the client sets to allow differentiation between instances of Powershell.exe. Or, an event to allow an add-in in a process to be labeled as an add-in during operations to access the server.

Example Send on Behalf Of event log entry

 

Log name: Exchange Auditing

Source: MSExchangeIS Auditing

Date: <date>

Event ID: 10104

Task Category: Send On Behalf Of

Level: Information

Keywords: Classic

Description: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB sent a message on behalf of /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserA

Message Id: <BA15978123F9C848B820A8C5C1DC29B50406C46E@Server.Contoso.com>

Mailbox: UserB

Account Name: CONTOSO\UserB

Accessing User: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB

Mailbox:<NULL>

Administrative Rights: false

Identifier: 0000000031718B30

Client Information (if Available)

Machine Name: <ClientName>

Address: <IP Address>

Process Name: OUTLOOK.EXE

Process Id: 0

Application Id: N/A

Applications that log on to multiple user mailboxes as a trusted service account generate a higher load for auditing. This is because each mailbox access operation by the service account may be logged.

In Exchange 2007 SP2, a new extended right is added to the schema. This is the Bypass Auditing right. The Bypass Auditing right prevents logging of actions by the user account to which the right is granted. Therefore, you should not grant the Bypass Auditing right to users who you want to audit.

noteNote:
By default, Windows grants the Domain Administrators group all extended rights. A domain administrator should not be mail-enabled if you have to audit all mailbox access. To allow the audit of domain administrators, you can deny the Bypass Auditing right at the Exchange Organization level. This allows the audit of Domain Administrator accounts that are mail-enabled. For example, to deny the bypass auditing right for the Domain Admins Group, run the following command from the Exchange Management Shell:
Add-ADPermission -Identity "CN=Contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com" -User "Domain\Domain Admins" -AccessRights ExtendedRight -ExtendedRights Ms-Exch-Store-Bypass-Access-Auditing -Deny:$true

You can use the Add-ADPermission cmdlet to grant the appropriate right for eachmailbox database th bypass auditing for specific service accounts. For example, to grant the Example\ServiceAccount the Bypass Access Auditing right, run the following command from the Exchange Management Shell:

get-mailboxdatabase -Identity "Server01\StorageGroup01\MailboxDatabase01" | Add-ADPermission -User example\ServiceAccount -ExtendedRights ms-Exch-Store-Bypass-Access-Auditing -InheritanceType All

Auditing mailbox access in Exchange is a complex process that is dependent on the intended use of the information, the organization's particular auditing requirements, the applications that are in use, and the level of administrator trust.

Windows NT Security Auditing is the best solution for organizations that have the highest level of auditing requirements. This form of auditing logs access to all objects by all users and stores the logged information in the Security log.

Exchange Access Auditing is appropriate for organizations that do not require Windows Auditing security. Exchange Access Auditing is appropriate for organizations that want to audit the following:

  • Only administrators who exercise Administrator rights to open mailboxes.
  • Only cases where one user opens another user's mailbox.
  • Only cases where the accessed resource is located in the IPM subtree.

At diagnostic logging level one (1), all categories log only events in which the acting users exercise administrative rights to access a mailbox. Organizations that use Exchange Access Auditing must keep in mind that by default, Exchange administrators can modify the diagnostic logging levels or clear the Exchange Access Auditing event log. Also, Exchange administrators may grant the Bypass Auditing right. Organizations that want to audit only Exchange administrators must implement a split permissions model to prevent the Exchange administrators from modifying logging levels, security descriptors or from clearing the event log.

At logging levels two (2) and four (4), folder and message access auditing log events when one mail-enabled user opens another mailbox-enabled user's folder or message. This logging level does not detect all types of shared mailbox access. A shared mailbox or a resource mailbox is associated with a disabled user account, and then additional users are granted access to the mailbox. If the additional users are not mailbox-enabled, access to the shared mailbox or resource mailbox is not logged at diagnostic level two (2) or four (4).

At diagnostic levels two (2) and three (3), Folder Access auditing logs Basic events or All events. Basic events only include folders that are subfolders of the IPM subtree. Or folders that are second rank or higher subfolders of the non-IPM subtree (for applications that cache data in these locations). Enabling higher diagnostic levels means that more events will be logged. This additional logging increases the load on the server. Also, the increased logging level could log false positive events such as free/busy cache lookup operations. Free/busy cache lookup operations access the root of the mailbox. These are non-malicious lookup operations.

To decide whether an organization needs to audit Basic or extended events requires knowing what applications the organization has deployed and where sensitive user data is stored. If an application stores sensitive user data in an immediate child folder of the non-IPM subtree, only All events (diagnostic level four or five) logging will log access to the particular folders.

Client programs that do not send the extended client information block generate auditing events that do not populate the client information. These are versions of Outlook that are earlier than Outlook 2003.

Message Access Auditing cannot detect all the information that is retrieved from a mailbox. This is because access to the folder contents table which is a summary table of commonly used message properties, does not require the user to open a message. The message subject, recipient information, and many basic message properties are part of the message folder table. This information may be read without opening a message and therefore, without generating a message access event.

When an organization selects Access Auditing for its auditing requirements, a number of security scenarios must be considered to evaluate the final cost of fully securing access to the audit logs and of protecting the log content.

If a user is granted the Bypass Auditing extended right, the user is not audited. We recommend that you monitor Active Directory ACLs to verify that a user who has Write Security Descriptor access does not grant themselves the Bypass Auditing right.

Windows grants Domain Administrators all extended rights. A domain administrator account should not be mail-enabled if all mailbox access must be audited.

Because the diagnostic logging levels control the events that are logged to the Exchange Auditing event log, changing the diagnostic logging level for particular categories may give you unexpected results. For example, certain expected events may no longer be logged. Also, because the Store.exe process cannot identify which user changed the logging levels or even whether the logging levels were changed from an earlier session, the Store.exe process is unable to identify changes to the auditing configuration.

The Exchange Auditing log contains a record of audited events and the Event Viewer has an ACL that prevents typical users from clearing the event log. If a local administrator took ownership of the appropriate registry key, reset the CustomSD value, and then restarted the server, the administrator could clear the Exchange Auditing log.

The Exchange Auditing event log may be a high traffic event log, depending on the server configuration and user actions. Therefore, we recommend that the Exchange Auditing event log be located on a dedicated hard disk drive that has sufficient space and that can support fast write operations.

For more information about how to configure Exchange Auditing event logs, see the following topics:

For more information about how to modify diagnostics logging levels in Exchange, see How to Change Logging Levels for Exchange Processes.

To ensure that you are reading the most up-to-date information and to find additional Exchange Server 2007 documentation, visit the Exchange Server TechCenter.
Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.