White Paper: Configuration and Mailbox Access Auditing for Exchange 2007 Organizations

 

Mike Lagase, Escalation Engineer, Microsoft CSS Enterprise Messaging Support

July 2009

This white paper describes the steps that you must take to enable auditing in an Exchange Server 2007 environment. This paper also describes the Mailbox Access Auditing feature, which was introduced in Exchange Server 2007 Service Pack 2 (SP2). This feature is used together with object auditing in Active Directory Domain services (AD DS) or Active Directory to audit the Exchange environment.

Microsoft Exchange Server 2007

Table of Contents

• Introduction

• Overview of the Exchange 2007 Auditing Process

• Comparing Auditing on Windows Server 2003 and Windows Server 2008

• Mailbox Access Auditing in Exchange Server 2007 Service Pack 2

  • Comparing Mailbox Access Auditing to Windows Auditing

• How to Configure Directory Service Access Auditing and Policy Change Auditing on Windows Server 2008

• How to Configure Directory Service Access Auditing and Policy Change Auditing on Windows Server 2003

• How to Enable Baseline Auditing for Exchange Configuration Objects

• How to Configure Auditing of Active Directory Objects

• How to Create an Exchange Group Policy Object to Store Audit Settings for the Exchange Servers OU

• How to Use a Security Template to Implement Auditing of Exchange Server Registry Keys

• How to Manually Implement Auditing of Exchange Server Registry Keys

• How to Enable Object Access Auditing

• How to Link the New Group Policy Object for Exchange Auditing to the Exchange Servers OU

• How to Use Sample Code to Search the Security Log

• How to Use a Windows PowerShell Script to View Events in the Security Log

• How to Use the Wevtutil Tool to Query Logs on Windows Server 2008

• How to Audit Administrative Access to Mailbox Permissions

• Exchange Server Mailbox Auditing

  • Access Auditing by Event Log Level

  • Common Audit Event Information

  • Folder Access Auditing

  • Basic Events Logging and All Events Logging

  • Message Access Auditing

  • Extended Send As Auditing

  • Extended Send On Behalf Of Auditing

  • Bypass Auditing Rights

  • Choosing an Auditing Strategy

  • Limitations of Access Auditing

  • Security Considerations

• How to Configure Automatic Archiving of Exchange Auditing Events

• How to Configure the Size and Location of Exchange Auditing Event Logs

  • View Current Auditing Log Size and Location

  • Change Auditing Log File Size or Path

• How to View Current Exchange Auditing Logging Levels

  • View Logging Levels 0, 1, 3, and 5

  • View Logging Levels 2 and 4

• How to Change Exchange Auditing Logging Levels

• Auditing Changes Throughout the Organization

• Things to Consider

• Third-Party Auditing Tools

• Conclusion

• Additional Information

  • Appendix A: INF File for a Security Template

  • Appendix B: Exchange Registry Keys

Auditing gives you insight into the Exchange topology and can help you troubleshoot issues and document changes in the Exchange environment. This document describes how to configure object auditing in Active Directory Domain Services (AD DS) and Active Directory to log events when a user or administrator creates, deletes, or changes an Exchange system object. Use Active Directory object auditing together with the Mailbox Access Auditing feature in Exchange 2007 Service Pack 2 (SP2) to audit the Exchange environment.

Auditing of Exchange Server 2007 can be implemented on both Windows Server 2008 and Windows Server 2003. However, we do not recommend that you implement auditing on Windows Server 2003. Windows Server 2008 provides a much more robust platform for auditing and is the preferred platform on which to deploy auditing features.

To audit the Exchange environment, you use the audit features that are included in AD DS or Active Directory. Most configuration data for Exchange is stored in AD DS or Active Directory, and the auditing information is stored in the System Access-Control List (SACL) for each object. After you enable auditing in AD DS or Active Directory, you can configure the audit of specific Active Directory objects for Exchange Server.

Mailbox Access Auditing is a new feature in Exchange 2007 SP2 for the Microsoft Exchange Information Store process. When this feature is enabled, events can be logged to a new Exchange Auditing event log whenever users or processes access information in mailboxes.

To audit Exchange, you must audit the following items:

• Active Directory objects in the Configuration and Domain Naming contexts

• Access to mailboxes in each mailbox store

• The local Exchange server

Auditing for each of these items is enabled in a unique location, and each location includes a selection of Exchange-related tasks that you can audit.

Return to top

Enabling auditing in an Exchange environment is an important step to help document configuration changes and help you troubleshoot complex problems in an environment.

Proactively enabling auditing before a major incident occurs in the Exchange environment can help save time and money and can help maintain business continuity while an investigation is conducted. Active Directory object auditing for Exchange lets you track what occurs with Exchange Server. It can be used to track deletions, creations, or modifications of any object in the Exchange organization. Active Directory object auditing can also collect information about logons and logoffs, permission use, and much more. Any time that an action that you have configured for auditing occurs, the action is written to the system’s Security log, which can be accessed by using Event Viewer.

AD DS and Active Directory contain most of the configuration data that is used by Exchange in its typical runtime operations. Depending on the services that the company provides, a specific level of certification may have to be met. Changes to Active Directory installations may have to be monitored to meet certain regulatory requirements, such as Sarbanes-Oxley, SAS 70 Type II, HIPAA, eDiscovery, FISMA, or FIPS. This white paper does not provide guidance to meet the requirements of such regulations. Follow the applicable regulations that require a level of auditing to detect changes or access to specific objects in the environment.

Developing and implementing an auditing plan for Exchange 2007 requires an analysis of your auditing requirements and an evaluation of the available features of your infrastructure. This information is necessary to accurately estimate the total cost of implementing your plan. To build a comprehensive audit of the Exchange environment, you must enable and configure many parts of the auditing solution. Used together, these parts provide a complete audit of Exchange. To implement auditing for Exchange Server 2007, you must configure the following:

• Policy Change auditing. Policy Change auditing is configured by using the Audit Policy Change security setting. Use this security setting to determine whether an incident is audited when user rights assignment policies, audit policies, or trust policies are changed.

• Directory Service auditing. Directory Service auditing is controlled by one of the following policy settings:

  • Directory Service Access for Windows Server 2003

  • Directory Service Changes for Windows Server 2008

  Directory Service Changes is a new audit policy subcategory in Windows Server 2008 AD DS that provides more detail about what objects were changed. If this security setting is enabled, and changes are made to the directory objects that are set for auditing, the changes are logged in the Security log.

• Baseline Auditing for Exchange Configuration Objects. The Baseline Auditing for Exchange Configuration Objects settings on Windows Server 2008 generate most of the events for changed and deleted objects in the Exchange Configuration Container in AD DS. After this configuration is completed, access to the selected objects is logged in the Security log.

• Auditing for specific Active Directory objects. After you enable auditing for the Exchange configuration changes in AD DS or Active Directory, you can apply similar auditing for specific objects, such as users, organizational units, or groups. For example, user auditing enables administrators to capture permission changes that are made at a mailbox level.

• The Exchange Group Policy object. You must create an Exchange Group Policy object to store the audit settings. In an Active Directory environment, you assign Group Policy settings by linking Group Policy objects (GPOs) to sites, domains, or organizational units (OUs). To help deploy Group Policy auditing of Exchange servers, create an OU to house the Exchange servers. You can then create a GPO and link this object to the Exchange Server OU. This helps ensure that only Exchange servers in the domain are affected by the Group Policy settings.

• Auditing of Exchange Server registry keys. These settings log when local changes occur that may affect how Exchange operates.

• Mailbox Access Auditing. These settings help administrators track access to messages and folders in a user's mailbox.

Return to top

On Windows Server 2003, Directory Service Access auditing is the only mechanism by which to track modifications to Active Directory objects. This logging mechanism is not very robust because Windows Server 2003 logs only the attribute that changed. Windows does not tell you what the attribute value was set to before and after the change.

Beginning with Windows Server 2008, audit policies changed so that you can now configure Granular Audit Policies. The Granular Audit Policies feature lets you audit object changes at a more detailed level; it can tell you the specific attribute values that were changed and what the values were before and after the change. For more information about how to use Group Policy settings to deploy Granular Audit Policies, see Microsoft Knowledge Base article 921469, How to use Group Policy to configure detailed security auditing settings for Windows Vista-based and Windows Server 2008-based computers in a Windows Server 2008 domain, in a Windows Server 2003 domain, or in a Windows 2000 domain.

Windows Server 2003 contains the following audit policy categories:

• Audit account logon events

• Audit account management

• Audit directory service access

• Audit logon events

• Audit object access

• Audit policy change

• Audit privilege use

• Audit process tracking

• Audit system events

Windows Server 2008 introduces subcategories that increase the number of audit policies to a total of 50. These new subcategories cannot be configured directly by using the Local Group Policy Editor; the subcategories have to be changed by using the Auditpol.exe command, which is included with the operating system. For more information, see Security Auditing.

Windows Server 2008 has the following Directory Service Access Granular Audit Policy subcategories:

• Directory Service Changes

• Directory Service Replication

• Detailed Directory Service Replication

• Directory Service Access

By default, any policy change that is made for a Directory Service Access policy on Windows Server 2003-based domain controllers will automatically overwrite all subcategory policies on Windows 2008-based domain controllers. To prevent this behavior, you must set the Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings policy to prevent the legacy domain policy from overwriting the subcategory audit policies. For example, if Windows Server 2003 Directory Service Access auditing is already enabled, and you introduce new Windows Server 2008-based domain controllers in the environment, any of the Windows Server 2003 higher-level categories that are configured will automatically overwrite all Granular Audit Policy subcategories. This may add auditing that may not be desired in your environment. For more information about how to change this setting, see Knowledge Base article 921469, How to use Group Policy to configure detailed security auditing settings for Windows Vista-based and Windows Server 2008-based computers in a Windows Server 2008 domain, in a Windows Server 2003 domain, or in a Windows 2000 domain.

To improve secure event management and provide a new user interface to help manage event log information, Windows Server 2008 uses the Windows Eventing 6.0 subsystem. Windows Eventing 6.0 also lets you create tasks and associate them with specific events that may occur. This new architecture helps resolve some performance and scalability issues that might occur on Windows Server 2003. Windows Eventing 6.0 also provides a new structured XML representation of the data, which can be used by other technologies. There is also a feature in Windows Eventing 6.0 that lets you set up a collector in which you can forward events to a single computer for ease of viewing.

To correctly deploy auditing in an Exchange environment, you must understand the relationship between audit policy and SACLs so that the correct events are captured for your tracking needs. An audit policy is defined either locally or by using a Group Policy object (GPO). The SACL is updated on specific objects that you have to audit. If an audit policy is deployed and if an associated SACL is not present on the object or objects, no events will be logged. Therefore, you must make sure that both the audit policy and the SACL are deployed successfully by following the procedures in this white paper.

Return to top

Exchange Server 2007 Service Pack 2 (SP2) includes the new Mailbox Access Auditing feature. Mailbox Access Auditing is enabled by a set of Diagnostics Logging categories for the Microsoft Exchange IS resource. Each category corresponds to a different type of resource access. Each category can be enabled independently. This lets an administrator choose the level of information (and the corresponding load from recording it) that is appropriate for the particular organization.

• The Folder Access category lets you log events that correspond to opening folders, such as the Inbox, Outbox, or Sent Items folders.

• The Message Access category lets you log events that correspond to opening messages.

• The Extended Send As category lets you log events that correspond to sending a message as a mailbox-enabled user.

• The Extended Send On Behalf Of category 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.

Return to top

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 log. This type of logging is the highest auditing level that is available in Windows and offers extensive records of object access. The goal of Mailbox Access Auditing is not to replace Windows auditing. Windows auditing focuses on "object open" and "object close" events. Mailbox Access Auditing ignores certain object events in favor of events that represent real user data that is being accessed.

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

Mailbox Access Auditing focuses on events that indicate that a client has accessed messaging data or exercised rights that affect messaging data. For example, Mailbox Access Auditing focuses on events that indicate the following:

• 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 mailbox folder. Mailbox Access Auditing lets you ignore operations that occur below the Interpersonal Message (IPM) subtree, such as free/busy cache lookup operations. Also, Mailbox Access Auditing ignores access by Exchange system processes. Mailbox Access Auditing can also log only a particular class or classes of access. The tradeoffs between Windows auditing and Mailbox Access Auditing are in the configuration process. Windows auditing can be set by policy. Mailbox Access Auditing is controlled by diagnostic categories for the Microsoft Exchange Information Store service.

Return to top

On Windows Server 2008, the Audit Policy Change security setting determines whether event types such as every change to user rights assignment policies, audit policies, or trust policies is audited. When this policy setting is defined, you can specify whether to audit successes or failures of an event type. If you make no selection, the event type is not audited at all. Success audits generate an audit entry when a change to user rights assignment policies, audit policies, or trust policies is successful. Failure audits generate an audit entry when a change to user rights assignment policies, audit policies, or trust policies fails. Before you change these settings, determine what the current settings are by using the Auditpol command to view the Audit Policy Change and Directory Service Changes security settings. If the Audit Policy Change security setting is not enabled, use the Auditpol command to enable the security setting. After the Audit Policy Change security setting is set, an event that resembles the following is logged in the Security log on the domain controller where the change was made:

Directory Service Changes is a new audit policy subcategory on Windows Server 2008. If this security setting is enabled, and changes are made to objects that an administrator has set up for auditing, the changes to the directory are logged in the Security log. Only successful changes are logged; failures to change the directory are not logged. The event includes the previous and current values for the changed objects. Events are logged when an object is created, deleted, modified, or moved.

When you enable Directory Service Changes auditing, Directory Service changes are categorized according to the type of change that occurs. The following table describes how the changes are categorized.

With these new auditing events, you can perform granular searches of the Security log and find relevant audit events more easily.

When a policy change occurs, the following event is logged in the Security log on a Windows 2008-based domain controller:

By default, the Directory Service Access audit policy is enabled on Windows Server 2008. However, this audit policy does not provide the granularity that is needed to implement successful and meaningful auditing of objects in AD DS. The Directory Service Changes audit policy provides the granularity that Directory Service Access auditing cannot provide.

For more information about audit policy settings, see Knowledge Base article 921469, How to use Group Policy to configure detailed security auditing settings for Windows Vista-based and Windows Server 2008-based computers in a Windows Server 2008 domain, in a Windows Server 2003 domain, or in a Windows 2000 domain.

If you have Windows Server 2003-based domain controllers in the organization, see "How to Configure Directory Service Access Auditing and Policy Change Auditing on Windows Server 2003" in this document.

To perform this procedure, the account that you use must be delegated membership in the Domain Administrators group.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To view the current auditing settings on Windows Server 2008

1. Run the following command at a command prompt:

   auditpol /get /category:*
   

2. Locate Audit Policy Change and Directory Service Changes in the returned data to determine whether the setting is enabled. The output will indicate whether the setting is enabled.

To enable Audit Policy Change auditing in AD DS on Windows Server 2008

• Run the following command at a command prompt:

  auditpol /set /subcategory:"Audit Policy Change" /success:enable
  

To enable Directory Service Changes auditing on Windows Server 2008

• Run the following command at a command prompt:

  auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable
  

For detailed syntax and parameter information, see Auditpol.

Return to top

On Windows Server 2003, Directory Service Access auditing is the only mechanism by which to track modifications to Active Directory objects.

In an environment that is running Windows Server 2003-based domain controllers, you must install the Group Policy Management Console (GPMC) before you can complete these procedures. To obtain the GPMC, see Group Policy Management Console with Service Pack 1. By default, the GPMC is installed when you install Windows Server 2008.

To perform this procedure, the account that you use must be delegated membership in the Domain Administrators group.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To configure Directory Service Access auditing and Policy Change auditing on Windows Server 2003

1. Start Group Policy Management.

2. In the GPMC tree, expand the forest and domain in which you want to enable policy change auditing, and then click the Domain Controllers OU.

3. Right-click Default Domain Controllers Policy, and then click Edit.

4. In the navigation tree, expand Computer Configuration, Windows Settings, Security Settings, and Local Policies, and then click Audit Policy.

5. In the right pane, double-click Audit directory services access.

6. In the Audit these attempts area, click to select the Success and the Failure check boxes.

7. Click Apply, and then click OK.

8. In the right pane, double-click Audit policy change.

9. In the Audit these attempts area, click to select the Success and the Failure check boxes.

10. Click Apply, and then click OK.

11. Close Group Policy Management.

Return to top

The Baseline Auditing for Exchange Configuration Objects audit settings generate most of the events for changed and deleted objects in the Exchange Configuration Container in AD DS. These audit settings require that inheritance is set correctly for every configuration object under the Services/Microsoft Exchange container. To verify that permissions inheritance is set for all Exchange Configuration objects, run the Exchange Best Practices Analyzer tool, and then select the Permissions check option. If the inherited permissions option is unchecked for any configuration object, an error message is logged to notify you, and the setting can then be corrected.

If Baseline Auditing for Exchange Configuration Objects is enabled, and a change is made to objects under the Exchange Configuration container, an event is logged in the Security log on a domain controller. Note that the auditing events are only logged on the domain controller for the domain where the change is made. For example, if a modification is made on a Client Access server to the ExternalURL on an Exchange Web Services (EWS) virtual directory, you will see an entry that resembles the following in a domain controller's Security log:

By comparison, if you use only Directory Service Access auditing, the data that is logged is not very descriptive. Instead of showing the property names and values that were changed, the data shows the GUIDs for changed properties in Active Directory installations, as shown in the following Security log entry. (To determine the property name of a GUID, see the Exchange 2007 GUID Reference topic.)

To perform this procedure, the account you use must be delegated membership in the Domain Administrators group.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To enable baseline auditing for Exchange Configuration Objects

1. Start ADSI Edit, and then connect to the domain controller that you want to view.

2. Expand the Configuration container, and then click CN=Services.

3. In the right pane, right-click CN=Microsoft Exchange, and then click Properties.

4. On the Security tab, click Advanced.

5. On the Auditing tab, click Add, type Everyone in the Enter the object name to select box, and then click OK.

6. In the Successful column and the Failed column, click to select the check boxes for the following object access auditing:

   • Write All Properties

   • Delete

   • Delete subtree

   • Modify permissions

   • Modify owner

   • All validated writes

   • All extended rights

   • Create all child objects

   • Delete all child objects

7. Click OK three times, and then close ADSI Edit.

Return to top

After you enable auditing for the Exchange configuration changes in AD DS or Active Directory, you can apply similar auditing for specific objects, such as users, organizational units, or groups. For example, the audit of user objects lets you capture permission changes that are made at a mailbox level. To do this, you must specify the types of access and the users whose access you want to audit.

To perform this procedure, the account you use must be delegated membership in the Domain Administrators group.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To configure auditing of Active Directory user objects

1. Start Active Directory Users and Computers.

2. On the View menu, click to select Advanced Features. When the Advanced Features option is selected, Advanced Features has a check mark next to it.

3. Right-click the domain name or organizational unit for which you want to configure auditing, and then click Properties.

4. On the Security tab, click Advanced.

5. On the Auditing tab, click Add.

6. In the Enter the object name to select box, type Everyone, and then click OK.

7. On a Windows Server 2008-based domain controller, click Descendant User Objects in the Apply onto list. On a Windows Server 2003-based domain controller, click User Objects in the Apply onto list.

8. In the Access box, click to select the check box under the Successful column for the following object access auditing:

   • Write All Properties

   • Delete

   • Delete Subtree

   • Modify Permissions

   • Modify Owner

   • All Validated Writes

   • All Extended Writes

   • Create All Child Objects

   • Delete All Child Objects

9. Click OK.

To configure auditing of Active Directory group objects

1. Start Active Directory Users and Computers.

2. Right-click the domain name or organizational unit for which you want to configure auditing, and then click Properties.

3. On the Security tab, click Advanced.

4. Click Add, type Everyone in the Enter the object name to select box, and then click OK.

5. On a Windows Server 2008-based domain controller, click Descendant Group Objects in the Apply onto list. On a Windows Server 2003-based domain controller, click Group Objects in the Apply onto list.

6. In the Access box, click to select the check box under the Successful column for the following object access auditing:

   • Write all properties

   • Delete

   • Delete subtree

   • Modify permissions

   • Modify owner

   • All validated writes

   • All Extended rights

   • Create all child objects

   • Delete all child objects

7. Click OK.

To configure auditing of Active Directory msExchDynamicDistributionList objects

1. Start Active Directory Users and Computers.

2. Right-click the domain name or organizational unit for which you want to configure auditing, and then click Properties.

3. On the Security tab, click Advanced.

4. Click Add, type Everyone in the Enter the object name to select box, and then click OK.

5. On a Windows Server 2008-based domain controller, click Descendant msExchDynamicDistributionList objects in the Apply onto list. On a Windows Server 2003-based domain controller, click msExchDynamicDistributionList objects in the Apply onto list.

6. In the Access box, click to select the check box under the Successful column for the following object access auditing:

   • Write all properties

   • Delete

   • Modify permissions

   • Modify owner

   • All validated writes

7. Click OK.

To configure auditing of Active Directory contact objects

1. Start Active Directory Users and Computers.

2. Right-click the domain name or organizational unit for which you want to configure auditing, and then click Properties.

3. On the Security tab, click Advanced.

4. Click Add, type Everyone in the Enter the object name to select box, and then click OK.

5. On a Windows Server 2008-based domain controller, click Descendant Contact objects in the Apply onto list. On a Windows Server 2003-based domain controller, click Contact Objects in the Apply onto list.

6. In the Access box, click to select the check box under the Successful column for the following object access auditing:

   • Write all properties

   • Delete

   • Modify permissions

   • Modify owner

   • All validated writes

   • All extended rights

7. Click OK three times, and then close Active Directory Users and Computers.

Return to top

In an Active Directory environment, you assign Group Policy settings by linking Group Policy objects (GPOs) to sites, domains, or organizational units (OUs). To help deploy Group Policy Auditing of Exchange servers, create an OU to house the Exchange servers. You can then create a GPO and link this object to the Exchange Server OU. This helps make sure that only Exchange servers in the domain are affected by the Group Policy settings.

To perform this procedure, the account you use must be delegated membership in the Domain Administrators group.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To create an OU to house the Exchange servers

1. Start Active Directory Users and Computers.

2. Right-click <Domain>.com, point to New, and then click Organizational Unit.

3. In New Object - Organizational Unit, type Exchange Servers, and then click OK.

4. Move each of the Exchange Server computer objects into the new Exchange Servers OU.

To create a GPO for Exchange auditing

1. Start Group Policy Management.

2. In the GPMC tree, expand the forest and domain in which you want to create a Group Policy object.

3. Right-click Group Policy Objects, and then click New.

4. In the New GPO dialog box, type Exchange Server Audit Policy to name the new GPO, and then click OK.

To import policy settings for the GPO

1. Right-Click Exchange Server Audit Policy, and then click Import Settings.

2. Follow the instructions in the Import Settings Wizard.

Return to top

To log events for any changes to Exchange configuration registry keys, enable auditing of Exchange-related registry keys. To make this easier to deploy across multiple Exchange servers, create a security template by using the code that is provided in "Appendix A: INF File for a Security Template" later in this white paper.

Use Group Policy settings to apply the security template to the Exchange server OU that you created in the "How to Create an Exchange Group Policy Object to Store Audit Settings for the Exchange Servers OU" section of this white paper. Follow the steps that apply to the specific operating system that is running Exchange 2007.

To perform this procedure, the account you use must be delegated membership in the Domain Administrators group.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To complete this procedure, create a security template file by using the text that is provided in "Appendix A: INF File for a Security Template." Copy the text to a file in Notepad, and then save the file as an .inf file. For example, name the file Exchange 2007 – E2K7_Reg_Audit.inf.

To create the security template file

1. Start Notepad.

2. Copy the text from Appendix A into the Notepad file.

3. On the File menu, click Save As.

4. Name the file Exchange 2007 – E2K7_Reg_Audit.inf, and then save it.

To import the policy settings into the previously created GPO on Windows Server 2008

1. In the GPMC tree, select Group Policy Objects in the forest and domain in which you created the Exchange Auditing GPO, right-click Exchange Server Audit Policy, and then click Edit

2. Under Computer Configuration, expand Policies, expand Windows Settings, right-click Security Settings, and then click Import Policy.

3. In the Look in list, click the security template that you created for your Exchange installation, click to select the Clear this database before importing check box, and then click Open. When the Clear this database before importing check box is selected, all the security settings in the GPO are replaced with those of the security template that you imported.

4. Close the Group Policy Object Editor snap-in, and then close Group Policy Management.

To import the policy settings into the previously created GPO on Windows Server 2003

1. In the GPMC tree, select Group Policy Objects in the forest and domain in which you created the Exchange Auditing GPO, right-click Exchange Auditing, and then click Edit

2. Under Computer Configuration, expand Windows Settings, right-click Security Settings, and then click Import Policy.

3. Click the security template that you downloaded for your Exchange installation, click to select the Clear this database before importing check box, and then click Open. When the Clear this database before importing check box is selected, all of the security settings in the GPO are replaced wth those of the security template that you import.

4. Close the Group Policy Object Editor snap-in, and then close Group Policy Management.

Return to top

If you do not want to use a security template to implement auditing of Exchange Server registry keys, you can implement registry key auditing manually. To do this, you must follow the steps for each registry entry that is listed in the table in "Appendix B: Exchange Registry Keys" section of this white paper. Follow the steps that apply to the specific operating system that is running Exchange 2007.

To perform this procedure, the account you use must be delegated membership in the Domain Administrators group.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To manually implement Exchange registry auditing on Windows Server 2008

1. On the computer that is running Exchange Server, run regedt32.

2. In Registry Editor, locate the first registry subkey that is listed in the "Exchange Registry Keys for Auditing Exchange Server 2008" table in Appendix B.

3. Right-click the key, and then click Permissions.

4. Click Advanced, and then click Add on the Auditing tab.

5. In the Enter the object name to select box, type everyone, click Check Names, and then click OK.

6. In the Apply onto list, click This key and subkeys.

7. In the Access area, click to select the Successful check box and the Failed check box for Set Value, Create Subkey, Delete, Change Permissions, and Take Ownership.

8. Click OK three times.

9. Repeat steps 1 to 8 for each registry subkey that is listed in the "Exchange Registry Keys for Auditing Exchange Server 2007" table, and then exit Registry Editor.

To manually implement Exchange registry auditing on Windows Server 2003

1. On the computer that is running Exchange Server, run regedt32.

2. In Registry Editor, locate the first registry subkey that is listed in the "Exchange Registry Keys for Auditing Exchange Server 2007" table in Appendix B.

3. Right-click the subkey, and then click Permissions.

4. Click Advanced, and then on the Auditing tab, click Add.

5. In the Enter the object name to select box, type everyone, click Check Names, and then click OK.

6. In the Apply onto list, click This key and subkeys.

7. In the Access area, click to select the Successful check box and the Failed check box for Set Value, Create Subkey, Delete, Write DAC, and Write Owner.

8. Click OK three times.

9. Repeat steps 1 to 8 for each registry subkey that is listed in the "Exchange Registry Keys for auditing Exchange Server 2007" table, and then exit Registry Editor.

Return to top

After you have enabled registry auditing, you must change the Local Audit policy and then enable auditing of object access for success and failure. You must set these settings on all Exchange servers.

After you enable Object Access auditing on Windows Server 2003, an entry that resembles the following is logged in the Security log when a change is made to a registry key:

After you enable Object Access auditing on Windows Server 2008, an entry that resembles the following is logged in the Security log when a change is made to a registry key:

To perform this procedure, the account you use must be delegated membership in the Domain Administrators group.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To enable Object Access auditing by using a GPO

1. In the GPMC tree, select Group Policy Objects in the forest and domain in which you created the Exchange Server Audit Policy GPO, right-click Exchange Server Audit Policy, and then click Edit

2. Under Computer Configuration, expand Policies, expand Windows Settings, expand Security Settings, expand Local Policies, and then click Audit Policy.

3. In the right pane, double-click Audit object access.

4. Click to select the Define these policy settings check box.

5. In the Audit these attempts area, click to select the Success check box.

6. Click Apply, and then click OK

7. Close the Group Policy Object Editor snap-in, and then close Group Policy Management.

To manually enable Object Access auditing

1. Click Start, point to Administrative Tools, and then double-click Local Security Policy.

2. In the console tree, under Security Settings, expand Local Policies, and then click Audit Policy.

3. In the details pane, double-click the event category for which you want to change the auditing policy settings.

4. To audit successful attempts, click to select the Success check box.

5. To audit unsuccessful attempts, click to select the Failure check box.

6. Click OK.

Return to top

After the new Group Policy settings are verified, you must link the new GPO to the Exchange Servers OU that was created previously.

To perform this procedure, the account you use must be delegated membership in the Domain Administrators group.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To link the Group Policy object for Exchange auditing to the Exchange Servers OU

1. Start Group Policy Management.

2. In the console tree, right-click the Exchange Servers OU, and then click Link an Existing GPO.

3. In the Group Policy objects list, click Exchange Server Audit Policy.

4. Click OK.

Return to top

After you have configured auditing, you need a way to capture and report an audited event. Because the audited events appear in the Security log, you can use code to search the log for these events.

The sample code in this section uses Windows Management Instrumentation (WMI) to search the Security log and retrieve event ID 566 when it contains "msExch" in the event description. To monitor Windows Server 2008 Directory Service Change events, change the EventCode from 566 to 5136.

This sample code was generated using Scriptomatic2 and then modified. To obtain this tool, see Scriptomatic 2.0: Readme. For information about how to use the Scriptomatic tool, see the Readme file that is included with the download.

You can also use Eventcombmt, which is included in the Windows Server 2003 Resource Kit, to parse the event logs. For more information about how to use the Eventcombmt tool, see the Help file that is included with the tool. To obtain Eventcombmt, download the Windows Server 2003 Resource Kit Tools.

To perform this procedure, the account you use must be delegated membership in the Domain Administrators group.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To use sample code to search the Security log

1. Start Notepad or any other text editor.

2. Paste the sample code shown below into the text editor.

3. Modify the line that starts with "arrComputers" to use the names of domain controllers in your organization. Ensure that each domain controller name is in quotation marks. If there are multiple domain contollers, the names must be separated by a comma.

4. To monitor Windows Server 2008 Directory Service Change events, change the EventCode from 566 to 5136.

5. Save the file as a plain text file by using a name such as ExAudit.vbs.

6. Open a command prompt, and then run the script by typing:

   cscript ExAudit.vbs >AuditEntries.txt 
   

Sample code to search the Security log

On Error Resume Next

Const wbemFlagReturnImmediately = &h10
Const wbemFlagForwardOnly = &h20

arrComputers = Array("DC1","DC2")
For Each strComputer In arrComputers
   WScript.Echo
   WScript.Echo "=========================================="
   WScript.Echo "Computer: " & strComputer
   WScript.Echo "=========================================="

   Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
   Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_NTLogEvent where logfile = 'Security' AND EventCode=566 AND Message like '%msExch%'", "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)

   For Each objItem In colItems
      WScript.Echo "Category: " & objItem.Category
      WScript.Echo "CategoryString: " & objItem.CategoryString
      WScript.Echo "ComputerName: " & objItem.ComputerName
      WScript.Echo "EventCode: " & objItem.EventCode
      WScript.Echo "EventType: " & objItem.EventType
      WScript.Echo "Logfile: " & objItem.Logfile
      WScript.Echo "Message: " & objItem.Message
      WScript.Echo "RecordNumber: " & objItem.RecordNumber
      WScript.Echo "SourceName: " & objItem.SourceName
      WScript.Echo "TimeGenerated: " & WMIDateStringToDate(objItem.TimeGenerated)
      WScript.Echo "Type: " & objItem.Type
      WScript.Echo "User: " & objItem.User
      WScript.Echo
   Next
Next

Function WMIDateStringToDate(dtmDate)
WScript.Echo dtm: 
      WMIDateStringToDate = CDate(Mid(dtmDate, 5, 2) & "/" & _
      Mid(dtmDate, 7, 2) & "/" & Left(dtmDate, 4) _
      &" " & Mid (dtmDate, 9, 2) & ":" & Mid(dtmDate, 11, 2) & ":" & Mid(dtmDate,13, 2))
End Function

Return to top

You can also use the PowerShell script in this section to view events in the Security log. This sample script exports Exchange configuration auditing entries from the Security logs of domain controllers

To perform this procedure, the account you use must be delegated membership in the Domain Administrators group.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To run a PowerShell script to export configuration auditing entries on domain controllers

1. Start Notepad or any other text editor.

2. Paste the PowerShell script shown below into the text editor.

3. Locate the line that says $servers = "DC1","DC2", and then change DC1 and DC2 to the names of the domain controllers in the Exchange environment.

4. Change the EventID from "566" to "5136" to query Windows Server 2008 domain controllers.

5. Save the file as a plain text file by using the name ExAudit and the .ps1 file extension.

6. Start Exchange Management Shell, and then run the ExAudit.ps1 script.

PowerShell script to export Exchange Configuration Auditing entries

#Script to export Exchange Configuration Auditing Entries on Domain Controllers
#Modify Server list below with the name of your DCs
$servers = "DC1","DC2"

#Constants
#Change EventID to 5136 to query Windows Server 2008 Domain Controllers
$EventID = "566"
$filter=[string]"*msExch*"

#Test if existing log.csv file exists and if so, remove it.
if (test-path Auditlog.csv)
{
remove-item Auditlog.csv
}

#Add CSV header to log.csv
add-content -path Auditlog.csv -value "Computername,EventCode,Message,TimeGenerated"

#Begin Processing
Write-Host "Parsing Security Event Log entries on"

#Query Each Server listed in array
foreach ($server in $servers)
{
                Write-Host $server -fore green
                gwmi -class Win32_NTLogEvent -ComputerName $server -filter "(logfile='security') AND (Eventcode=$EventID)" | where {$_.Message -like $filter} |  select-object Computername,EventCode,Message,@{n="TimeGenerated";e={$_.converttoDateTime($_.timegenerated)}} | export-csv -path $server".csv" -notype

#Remove first line of server CSV file in memory
$f=get-content $server".csv"
$f[0]=$null

#Merge Server data into log.csv
add-content -path Auditlog.csv -value $f

#Remove Temporary Server data
remove-item $server".csv"
}
Write-host "Exchange Auditing entries saved to Auditlog.csv"

Return to top

The Wevtutil tool is installed when you install Windows Server 2008. In a Windows Server 2008 domain, you can use Wevtutil to query logs on local or remote domain controllers.

To perform this procedure, the account you use must be delegated membership in the Domain Administrators group.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To use the Wevtutil tool to query logs on a local domain

• At a command prompt on a local domain controller, run the following command where <Event_ID_Number> is the event ID that you want to locate:

  wevtutil qe security /q:"*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and (EventID=<Event_ID_Number>)]]" /f:text /rd:true
  

To use the Wevtutil tool to query logs on a remote domain

• At a command prompt on a local domain controller, run the following command where <Event_ID_Number> is the event ID that you want to locate and <RemoteServer> is the remote server that you want to query:

  wevtutil qe security /r:<RemoteServer> /q:"*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and (EventID=5136)]]" /f:text /rd:true
  

For more information about how to use the Wevtutil tool, see Wevtutil.

Return to top

To audit Administrative access to mailbox permissions, monitor when write access to the msExchMailboxSecurityDescriptor attribute occurs. To do this, you can use Event Viewer to monitor the Security log on the domain controller.

During the monitoring process, make sure that there are no time gaps between the logged events in a log file. A gap between logged events indicates that someone has tried to distort or tamper with the event log and that there is an issue with the administrator account.

If an issue with the administrator account occurs, follow these steps to help secure the administrator account and the Exchange servers:

• Remove remote terminal access to the servers.

• Restrict physical access to the servers.

• Log access to the servers.

• Use surveillance equipment to monitor access to the server.

To perform this procedure, the account you use must be delegated membership in the Domain Administrators group.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To monitor write access to the msExchMailboxSecurityDescriptor attribute

1. Start Event Viewer.

2. Expand Windows Logs, and then click Security.

3. On the Action menu, click Find.

4. In the Find what box, type msExchMailboxSecurityDescriptor, and then click Find Next.

Return to top

The volume of logged audit events in the Exchange Auditing event log is directly related to the load on a server together with the number of user operations of the audited type that are occurring at a given time. Because the Application log is also a source of diagnostic and troubleshooting data, Access auditing does not log events to the Application log. With Exchange 2007 Service Pack 2 (SP2), 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 subkey:

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

Note   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 about SDDL formats, view the Event Log topic.

To obtain a user or groups SID value, use the PsGetSid tool from Windows Sysinternals. For more information, visit the PsGetSid v1.43   Web page.

You can also use PowerShell to obtain the SID for a user. To do this, 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 rights 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 available only when the program supports sending extended client data. Microsoft Office 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 you select the appropriate logging level for your 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 folder access using Administrative rights is logged.

• At logging level two (2) and four (4) only folder 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.

Return to top

The mailbox folder hierarchy consists of a non-Interpersonal Message (IPM) subtree and an IPM subtree. The non-IPM subtree houses folders for application use, such as search folders. The IPM subtree houses folders, such as the Inbox or Sent Items folders, that are viewed and used by users. 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 event 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, Sent Items, or Drafts folders, do not have to enable higher level event logging. The following table shows the events that are logged at each logging level for the Folder Access category.

Category: Folder Access

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

Return to top

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 shows the events that are logged at each logging level for the Message Access category.

Category: Message Access

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

Return to top

Extended Send As events indicate that one user sent a message as another user. Extended Send As events do not support Basic events and apply only when one user sends a message as another user. At logging level one (1), an event is only recorded if the user used administrator rights to open a mailbox and send 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 shows the events that are logged at each logging level for the Extended Send As category.

Category: Extended Send As

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

Return to top

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 apply only 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 rights to open a mailbox and 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 shows the events that are logged at each logging level for the Extended Send On Behalf Of category.

Category: Extended Send On Behalf Of

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

Return to top

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

In Exchange 2007 Service Pack 2 (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.

You can use the Add-ADPermission cmdlet to grant the appropriate right for each mailbox database to bypass auditing for specific service accounts.

To perform this procedure, the account you use must be delegated membership in the Domain Administrators group.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

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
  

For detailed syntax and parameter information, see the Add-ADPermission topic.

Return to top

Auditing mailbox access in Exchange is a complex process that depends 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 in which one user opens another user's mailbox.

• Only cases in which 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. Be aware 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 and security descriptors or from clearing the event log.

At logging level two (2) and four (4), folder auditing 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. Shared mailboxes and resource mailboxes are associated with disabled user accounts. Additional users are then 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 level 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 has 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.

Return to top

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 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 cannot identify changes to the auditing configuration.

The Exchange Auditing event 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 event 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.

Return to top

Windows Server 2008 can automatically archive an event log when the maximum event log size is reached. This Windows Server 2008 event log setting is named Archive the log when full, do not overwrite events. By default, this setting is enabled for the Exchange Auditing event log. When the maximum Exchange Auditing event log size is reached, Windows Server 2008 closes the current log file and archives the log file to the folder in which the Exchange Auditing event log is located. You can see the archived log files under Saved Logs in Event Viewer.

The format of the archive log file is as follows:

Archive-<Exchange Auditing Log file name>-<datetime>.evtx

For example, if the path to the Exchange Auditing log file name is D:\ExchangeAuditing\ExchangeAuditing.evtx, the file name resembles the following:

Archive-ExchangeAuditing-2009-05-06-12-54-33-725.evtx

When a log file is rolled over, event ID 105 is logged to the System log. This event resembles the following:

Sample event ID 105 entry

To perform this procedure, the account you use must be delegated the following:

• Local Administrator rights

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To use the Windows Server 2008 Event Viewer to automatically archive event logs

1. Click Start, click Run, type eventvwr, and then click OK.

2. In Event Viewer, expand Application and Services logs, and then click Exchange Auditing.

3. Right-click Exchange Auditing, and then click Properties.

4. Click Archive the log when full, do not overwrite events.

5. Click OK.

Return to top

On Windows Server 2008, you can use the Wevtutil tool to view the current event log size and location. On Windows Server 2003, you can modify the registry to change the event log location.

For more information about how to use Wevtutil, see the Wevtutil topic.

When you use Wevtutil to check the size and location of an Auditing log, you can check that log archiving is set correctly. The output of this utility tells you whether Retention and AutoBackup parameters are set to True. Both these settings must be True to allow for correct automatic archival of the event logs.

To perform this procedure, the account you use must be delegated the following:

• Local Administrator rights

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To use Wevtutil to view the current event Exchange Auditing log size and location

• At a command prompt, run the following command:

  wevtutil gl "Exchange Auditing"
  

This command generates output that resembles the following:

Return to top

You may want to move log files to another location if you require more disk space in which to log data. In this case, you must change the log path. You can use the Wevtutil tool or the Exchange Management Console to change the log file path or the log size.

For more information about how to change the event log location in Windows Server 2003, see Microsoft Knowledge Base article 315417, How to move Event Viewer log files to another location in Windows 2000 and in Windows Server 2003.

To perform this procedure, the account you use must be delegated the following:

• Local Administrator rights

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To use Wevtutil to change the Exchange Auditing log file path

• Run the following command:

  Wevtutil sl "Exchange Auditing" /lfn:<path>\ExchangeAuditing\ExAudit.evtx
  

  In this command, replace <path> with an appropriate drive letter or path.

To use Wevtutil to change the Exchange Auditing log size

• Run the following command:

  Wevtutil sl "Exchange Auditing" /ms:<size in bytes>
  

  For example, to change the log file to 100 MB, run:

  Wevtutil sl "Exchange Auditing" /ms:104857600
  

To use the Exchange Management Console to change the Exchange Auditing log size and path

1. Use Windows Explorer to create a folder in which to store the Exchange Auditing log file.

2. Click Start, click Run, type eventvwr, and then click OK.

3. In Event Viewer, expand Application and Services Logs, and then click Exchange Auditing.

4. Right-click Exchange Auditing, and then click Properties.

5. In the Log path box, type the full path of the new location of the .evtx event log file.

6. In the Maximum log size (KB) box, specify an appropriate value for the size of the log file.

7. Click OK.

Return to top

You can use the Exchange Management Console and the Exchange Management Shell to view the current Exchange Auditing logging levels.

You can use the Exchange Management Console or the Exchange Management Shell to view logging levels 0, 1, 3, and 5.

To perform this procedure, the account you use must be delegated the following:

• Local Administrator rights

• Exchange Organization Administrators rights

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To use the Exchange Management Console to view logging levels 0, 1, 3, and 5

1. Start the Exchange Management Console.

2. Expand Server Configuration, and then click Mailbox.

3. In the details pane, right-click the mailbox server for which you want to view the logging levels, and then click Manage Diagnostics Logging Properties.

4. Expand MSExchangeIS, and then expand 9000 Private.

5. Click the following categories to view the current logging level:

   • Message Access

   • Folder Access

   • Extended Send As

   • Extended Send On Behalf Of

To use the Exchange Management Shell to view logging levels 0, 1, 3, and 5

• Run the following command:

  Get-EventLogLevel MSExchangeIS\9000*\*
  

For detailed syntax and parameter information, see the Get-EventLogLevel topic.

When you view logging levels two (2) and four (4), you will see if any mailbox-enabled user has contacted another mailbox. You can use the Exchange Management Shell to view logging levels 2 and 4.

To perform this procedure, the account you use must be delegated the following:

• Local Administrator rights

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To use the Exchange Management Shell to view logging levels 2 and 4

1. Start the Exchange Management Shell, and then run the following command:

   Set-Location "HKLM:\System\CurrentControlSet\Services\MSExchangeIS\Diagnostics\9000 Private"
   

2. Run the following command to list the logging levels that are currently set:

   Get-ItemProperty .
   

For detailed syntax and parameter information, see the Get-ItemProperty topic.

Return to top

You can use the Exchange Management Console to set Exchange Auditing logging level 0, 1, 3, or 5. To set Exchange Auditing levels 2 or 4, you must use the Exchange Management Shell.

To perform this procedure, the account you use must be delegated the following:

• Local Administrator rights

• Exchange Organization Administrators rights

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To use the Exchange Management Console to set logging level 0, 1, 3, or 5

1. Start the Exchange Management Console.

2. Expand Server Configuration, and then click Mailbox.

3. In the details pane, right-click the Mailbox server for which you want to set Exchange Auditing, and then click Manage Diagnostics Logging Properties.

4. Expand MSExchangeIS, and then expand 9000 Private.

5. Click one of the following items, as appropriate for the logging that you want to perform:

   • Message Access

   • Folder Access

   • Extended Send As

   • Extended Send On Behalf Of

6. Click one of the following logging levels, as appropriate for the logging level that you want to set:

   Expand table

   Logging level	Setting
   0	Lowest
   1	Low
   3	Medium
   5	High

7. Repeat steps 5 and 6 for each item that you want to audit.

8. Click Configure, and then click Finish.

9. Stop and then start the Microsoft Exchange Information Store service.

To use the Exchange Management Shell to set logging level 2 or 4

1. Start the Exchange Management Shell, and then run the following command:

   Set-Location "HKLM:\System\CurrentControlSet\Services\MSExchangeIS\Diagnostics\9000 Private"
   

2. Run the following command to list the logging levels that are currently set:

   Get-ItemProperty .
   

3. To modify a logging level, such as the Message Access logging level, run a command that resembles the following:

   Set-ItemProperty -Path . -Name "9075 Message Access" -Value 2
   

4. Stop and then start the Microsoft Exchange Information Store service.

For detailed syntax and parameter information, see the Set-ItemProperty topic.

Return to top

In a large organization, a long term management solution that can archive the audit events to a centralized repository or database may be needed. Audit Collection Services (ACS) is a core feature of Microsoft System Center Operations Manager 2007. ACS provides a mechanism to forward, collect, store, and analyze security event data. Security events are collected and stored in a central Microsoft SQL Server database. An administrator can quickly run a report to help understand changed events that have occurred in an environment. This can help provide a faster resolution to common problems and allow for accountability among employees.

For more information about understanding and deploying ACS, see the following topics:

• About Audit Collection Services (ACS) in Operations Manager 2007

• The "Deploying ACS Reporting" topic in the Operations Manager 2007 Deployment Guide

• How to Deploy Operations Manager 2007 ACS Reporting

• Auditing and Compliance in Windows Server 2008

Return to top

In addition to auditing Exchange Server, you may want to consider the following:

• We recommend that you also use Journaling. Journaling lets you keep a copy of every e-mail message that is sent in or out of your Exchange organization. For more information, see White Paper: Exchange 2007 Transport Journaling.

• To help prevent misuse of service accounts, make sure that the service accounts you have for applications that need “global administrative rights” over Exchange are set so that no one can log on interactively. For example, Blackberry Enterprise Server should be configured in this manner.

• Protect your Exchange Server backups. If someone could take a backup tape and restore it off site, they could have access to all the mailboxes on the backup tape.

• Include a mechanism that can audit your auditing so that you know when someone has modified the audit logs.

• Make sure that your Exchange administrators use their user accounts for day-to-day e-mail and their Exchange Admin accounts for administration and delegation.

• To help secure user mailboxes and protect the confidentiality of their contents, make sure that the user who has permissions to a mailbox is also the mailbox owner. To monitor this scenario, generate a report regularly that provides details about the user mailboxes for which permissions have been granted (not pushed out by policy on the accounts).

There are number of companies that provide tools that can help audit systems and capture data from the event logs. The following companies are among those that offer third-party auditing tools:

• Dorian Software, Event Analyst

• TNT Software, Event Log Monitor

• RippleTech, Logcaster

• Sensage

• Opalis Robot

• Argent Software, Guardian

• BMC Patrol

• NetIQ

• Quest - Intrust Audit Package for Exchange

Return to top

Implementing auditing functionality in your Exchange environment can provide useful information about the environment's configuration and usage. Auditing can also help you document configuration changes and troubleshoot complex problems.

The Mailbox Access Auditing feature that is introduced in Exchange 2007 SP2 provides a useful addition to the auditing features that are provided with Windows Server. Mailbox Access Auditing allows logging of events whenever a client has accessed messaging data or exercised rights that affect messaging data.

Auditing features can be implemented in Active Directory on Windows Server 2003-based computers or in AD DS on Windows Server 2008-based computers. Because the auditing functionality that is available on Windows Server 2008 is more robust, Microsoft recommends that customers who require auditing in their Exchange Server environment use Windows Server 2008 to achieve the best results.

Use the following text to create an INF file that can be used as a security template for the procedures in the "How to Use a Security Template to Implement Auditing of Exchange Server Registry Keys" section of this white paper.

[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[Registry Keys]
"MACHINE\SOFTWARE\Microsoft\Exchange",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\SOFTWARE\Microsoft\WBEM",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\SOFTWARE\Microsoft\RPC",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\ESE",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\EXOLEDB",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\INETINFO",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\HTTP",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\DAVEX",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\VSS",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\SYSTEM\CurrentControlSet\Services\msftesqlIDX-Exchange",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\SYSTEM\CurrentControlSet\Services\msftesqlFD-Exchange",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\SYSTEM\CurrentControlSet\Services\msftesql-Exchange",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeWS",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeUMSubscriberAccess",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeUMPerformance",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeUMGeneral",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeUMFax",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeUMClientAccess",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeUMCallAnswer",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeUMAvailability",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeUMAutoAttendant",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeUM",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeTransportLogSearch",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeTransport SmtpSend",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeTransport SmtpReceive",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeTransport Routing",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeTransport Resolver",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeTransport Queues",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeTransport Pickup",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeTransport Dumpster",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeTransport DSN",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeTransport Database",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeTransport Batch Point",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeTransport",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeServiceHost",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeSearch",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeSA",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeRepl",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangePop3",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeMU",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeMonitoring",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeMailSubmission",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeMailboxAssistants",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeIS",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeImap4",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeFDS:UM",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeFDS:OAB",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeFDS",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeFBPublish",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeEdgeSync Topology",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeEdgeSync Job",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeEdgeSync",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeAutodiscover",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeAntispamUpdate",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeAL",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchangeADTopology",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Web Services",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Update Agent",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Unified Messaging",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange TransportService",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Transport Rules",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Topology",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange System Attendant Mailbox",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Store Interface",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Store Driver",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Sender Id Agent",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Sender Filter Agent",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Secure Mail Transport",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Search Indices",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Search Indexer",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Resource Booking",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Replication",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Replica Seeder",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Repl",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Recipient Filter Agent",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Recipient Cache",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Protocol Analysis Background Agent",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Protocol Analysis Agent",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Process Manager",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange POP3",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange OWA",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Messaging Policies",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Management Application",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Managed Folder Assistant",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Journaling Agent",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange IMAP4",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Extensibility Agents",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Extensibility",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange EdgeSync",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Content Filter Agent",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Connection Filtering Agent",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Common",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Cluster",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Calendar Attendant",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Availability Service",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Availability",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Autodiscover",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Assistants",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Antispam",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange Anti-spam Update",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange ADAccess",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\System\CurrentControlSet\Services\MSExchange AD RMS Prelicensing Agent",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"
"MACHINE\SYSTEM\CurrentControlSet\Services\MSExchange ActiveSync",0,"S:AR(AU;CISA;DCLCSDWDWO;;;WD)"

Return to top

Return to top