Exchange 2007 Permissions: Frequently Asked Questions

Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

 

Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3

This topic answers permission-related questions that we've received since Microsoft Exchange Server 2007 was released.

Many answers describe specific changes to permissions that you can make to allow or disable access. If you are not familiar with the tools that you can use to manage permissions, see Planning and Implementing a Split Permissions Model.

The questions and answers are organized into two sections:

• Exchange 2007 Deployment

• Exchange 2007 Management

Exchange 2007 Deployment

Q: What permissions do I need to run the forest and domain preparation steps?

A: The following permissions are required:

• To run the Setup /PrepareLegacyExchangePermissions command, you must be a member of the Enterprise Admins security group.

• To run the Setup /PrepareSchema command, you must be a member of the Schema Admins and Enterprise Admins security groups.

• To run the Setup /PrepareAD command, you must be a member of the Enterprise Admins security group.

To run the Setup /PrepareDomain, setup /PrepareDomain:<FQDN> command or the Setup /PrepareAllDomains command, you must be a member of the Enterprise Admins group or you must be a member of the Domain Admins group in any domain that you will prepare.

Q: What does /PrepareLegacyExchangePermissions for Exchange 2007 do?

A: For detailed information, see Preparing Legacy Exchange Permissions.

Q: How does Setup /PrepareLegacyExchangePermissions determine the list of domains to update?

A: The Setup /PrepareLegacyExchangePermissions task retrieves the list of domains in the forest from the forest configuration. The task then connects to a global catalog server and performs a lookup in each domain’s naming partition. Next, the task determines whether the domain has been prepared for Microsoft Exchange 2000 Server or Exchange Server 2003 by trying to resolve the security identifiers (SID) of the Exchange Domain Servers and Exchange Enterprise Servers security groups. After the task has built a list of domains that have been previously prepared, the task tries to establish a domain configuration Lightweight Directory Access Protocol (LDAP) session with each domain. If the task can establish a session, it sets the legacy permissions for the domain. If the task cannot establish the session because of a permissions-related problem or because the domain is not available, it adds that domain to a list of unreachable domains. If the list of unreachable domains contains any domains, the task fails after it has processed the reachable list.

If the task fails, you must determine a corrective strategy, such as running the task on a domain controller in that domain by using an account that has appropriate credentials, to make sure that the domain is updated before you continue with the rest of the Exchange 2007 preparation steps.

Q: What does Setup /PrepareSchema for Exchange 2007 do?

A: For detailed information, see How to Prepare Active Directory and Domains.

Q: What does Setup /PrepareAD for Exchange 2007 do?

A: For detailed information, see How to Prepare Active Directory and Domains.

Q: What does Setup /PrepareDomain for Exchange 2007 do?

A: For detailed information, see How to Prepare Active Directory and Domains.It creates the Microsoft Exchange System Objects container in the domain.

This container is used to store public folder proxy objects and Exchange-related system objects, such as the mailbox store's mailbox.

The Setup /PrepareDomain command assigns specific permissions on this folder. For more information about the specific permissions granted, see Exchange 2007 Server Setup Permissions Reference.

The Setup /PrepareDomain command creates the Exchange Install Domain Servers global security group and puts it in the Microsoft Exchange System Objects container.

It adds the Exchange Install Domain Servers global security group into the Exchange Servers universal security group.

It assigns permissions at the domain level for the Exchange Servers universal security group. For more information about the specific permissions granted, see Exchange 2007 Server Setup Permissions Reference.

It assigns permissions at the domain level for the Exchange Recipient Administrators universal security group. For more information about the specific permissions granted, see Exchange 2007 Server Setup Permissions Reference.

It assigns to the Exchange Servers universal security group the Manage Auditing and Security Logs permission set on the Default Domain Controller Policy organizational unit.

Q: When do I have to run Setup /PrepareDomain for Exchange 2007?

A: The Setup /PrepareDomain command lets Active Directory domain administrators prepare their domains for Exchange 2007 users and servers. You should run the Setup /PrepareDomain command in each domain that will contain the following:

• Exchange 2000, Exchange 2003, or Exchange 2007 servers

• Mail-enabled objects

• Global catalog servers that Exchange directory access components might use

Q: Why is the Exchange Servers group a member of the Windows Authorization Access group in each domain that has Exchange servers or users with Exchange mailboxes?

A: This change was introduced with the PrepareDomain functionality in Exchange 2007 Service Pack 1. This change lets the Microsoft Exchange Transport service use the Service-for-User (S4U) Kerberos extension collection to perform permissions checks on computers that are not domain controllers.

Q: I have noticed that Setup /PrepareDomain changes the domain controller policy. The Exchange Servers universal security group is granted the permission to manage the auditing and security logs. Why is this required?

A: For the store process to support mailbox auditing, this permission is required because it enables the Exchange server to read System Access Control Lists (SACL) in the domain. If this permission is removed, Exchange server databases will not mount. This is the only adjustment that the Setup /PrepareDomain command makes to the domain controller policy. This policy is replicated to other domain controllers through a combination of Active Directory replication and the File Replication Service (FRS).

Return to top

Q: What function does the Exchange Install Domain Servers security group perform?

A: When an Exchange 2007 server is installed, its computer account is added to the Exchange Servers universal security group. By default, this group is hosted in the root domain of the forest. If the server that you are installing is in a different domain, the Exchange services may not start during Setup because Active Directory replication has not replicated the Exchange Servers membership to the global catalog servers that are located in the domain where you are installing Exchange 2007.

The purpose of the Exchange Install Domain Servers security group is to make sure that during Setup the services can start appropriately without waiting for Active Directory replication. Exchange Setup adds the computer account to the local domain’s Exchange Install Domain Servers global security group.

Q: Can I move the default Exchange security groups to another container or domain in the forest?

A: Exchange 2007 uses a new set of security groups to manage the permission model and to maintain coexistence. These groups are as follows:

• Exchange Servers

• Exchange View-Only Administrators

• Exchange Public Folder Administrators (New in Exchange 2007 Service Pack 1)

• Exchange Recipient Administrators

• Exchange Organization Administrators

• ExchangeLegacyInterop

By default, these security groups are located in the root domain in the Microsoft Exchange Security Groups organizational unit. They can be moved to different organizational units and also to other domains in the forest. Moving the groups in the forest is supported because these groups have two unique properties: a well-known GUID and a distinguished name that can change. By using these two properties and adding them to the forest’s otherWellKnownObjects attribute during the Setup /PrepareAD task, Exchange can find the security group anywhere in the forest. The directory service will handle updating the distinguished name (DN) of the object when it is moved. In this manner, Exchange does not require a fixed location in the directory.

Return to top

Q: My company does not allow inherited permissions from the Active Directory domain level to child containers and organization units. Is this going to cause a problem?

A: The Setup /PrepareDomain command only puts access control entries (ACE) for the Exchange Servers group and the Exchange Recipient Administrators group at the domain level. Therefore, if you block inheritance, Microsoft Exchange will be unable to process user objects. The result is that Recipient Administrators will be unable to provision mail recipients and Exchange will be unable to update the appropriate attributes on the objects.

Upon blocking inheritance, you have the option to either Remove or Copy the permissions on the selected container or organizational unit. If you decide to Copy the permissions, the appropriate ACEs will be applied. If you decide to Remove the permissions, the appropriate ACEs will not be applied and recipient provisioning will not function.

If you want to set permissions manually on an organization unit so that the Exchange 2007 and recipients can process or access objects, you must assign the following permissions:

• Assign the Authenticated Users security object the following permission to all recipient object types in the organizational unit:

  • Read access for the Exchange Information property set

• Assign the Exchange Servers group the following permissions to all recipient object types in the organizational unit:

  • Write access for the following attributes:

    groupType	msExchUMPinChecksum	msExchMailboxSecurityDescriptor
    publicDelegates	msExchUMSpokenName	msExchUserCulture
    userCertificate	msExchMobileMailboxFlags	msExchUMServerWriteableFlags

  • Read access for the following attributes:

    garbageCollPeriod	canonicalName
    userAccountControl	memberOf

  • Read access for the Exchange Personal Information property set

  • Read access for the Exchange Information property set

  • Change Password permission

  • Write Permissions permission for group objects

If you are operating an environment that contains Exchange 2000 or Exchange 2003 servers, you will also have to assign the Exchange Enterprise Servers security group the following permissions so that the Exchange 2003 Recipient Update Service can process objects:

• List Contents

• Read All Properties

• Read Permissions

• Write Public Information

• Write Personal Information

• Write Exchange Information

• Write displayName

• Write groupType

• Write Permissions permission on group objects (this permission is necessary to support hidden group membership)

To make sure that the Exchange Recipient Administrators can manage the recipient objects in the organizational unit, you must assign the Exchange Recipient Administrators security group the following permissions:

• Write access to the following property sets:

  • Exchange Personal Information

  • Exchange Information

• Write access to the following attributes:

  legacyExchangeDN	publicDelegates	showInAddressBook
  displayName	garbageCollPeriod	proxyAddresses
  adminDisplayName	textEncodedORAddress	mail
  displayNamePrintable

• Create msExchDynamicDistributionList objects permission

• Delete msExchDynamicDistributionList objects user right

• Full control over msExchDynamicDistributionList objects

• Generic Read permission, which includes Read, List Contents, List Object, and Read All Properties permission

You can set all these permissions by using the Active Directory Service Interfaces (ADSI) snap-in, discretionary access control lists (DACL), or the Add-ADPermission cmdlet in the Exchange Management Shell. For more information about how to set permissions at the organizational unit level, see Planning and Implementing a Split Permissions Model.

Return to top

Q: What permissions do I need to install the first Exchange server?

A: Assuming that you have performed all the forest and domain preparation steps, to install the first Exchange server, you must be logged on to Active Directory with the following permissions:

• Exchange Organization Administrator role

• Member of the local Administrators group on the target Exchange server

Q: What permissions do I need to install additional Exchange servers?

A: Assuming that you have performed all preparation steps and the first Exchange 2007 server role has been installed, to install additional Exchange servers of the same role, you must be logged on to Active Directory with the following permissions:

• Either the Exchange Organization Administrator role or have been delegated the permission to install the server through Setup’s server provisioning process. For more information about how to provision server objects, see How to Provision Exchange 2007 Server and Delegate Setup.

• Member of the local Administrators group on the target Exchange server

Q: How do I delegate permissions to other administrators so that they can manage various Exchange 2007 services?

A: To delegate permissions to other users, use the following:

• The Add Exchange Administrator wizard in the Exchange Management Console

• The Add-ExchangeAdministrator cmdlet in the Exchange Management Shell

To delegate additional administrators, you must be logged on as a user who has the Exchange Organization Administrator role assigned.

Return to top

Q: If I move the Exchange computer accounts to a different organizational unit in Active Directory, will this affect my Exchange permissions and delegation?

A: No, the Add Exchange Administrator wizard assigns permissions in the configuration naming context of Active Directory, not the domain naming context, which is where the computer accounts reside. However, you must restart the Microsoft Exchange System Attendant service on the Exchange server after the computer account object has been moved. For more information about why you have to restart the Exchange server, see Microsoft Knowledge Base article, System Attendant generates Event ID 9186 and Event ID 9187 in Exchange 2000 and in Exchange 2003.

Q: What is the difference between the Exchange Organization Administrator role and the Exchange Server Administrator role?

A: An Exchange Organization Administrator can manipulate and change settings for any Exchange object in the configuration partition in the Exchange organization.

An Exchange Server Administrator can manipulate only the Exchange server object, and everything under it, to which the administrator has been delegated permission.

Q: If I grant a user or group permissions at the Exchange organization level, do these automatically flow down?

A: Yes. Permissions are inherited, as they are in Exchange 2003.

Q: What permissions do I need for the service account in Exchange 2007 cluster configuration?

A: The cluster service account does not require any Exchange organization permissions.

Q: What permissions do I need to install Exchange 2007 in a cluster configuration?

A: For more information about how to perform a delegated installation of clustered mailbox servers, see How to Perform a Delegated Setup of a Clustered Mailbox Server.

Return to top

Q: I have a third-party messaging application that requires full access to each user's mailbox. With Exchange Server 5.5, we grant a special account the Service Account Admin permissions, and then tell the application to use this account. How can I achieve similar functionality in Exchange 2007?

A: Exchange 2007 security works differently from that of Exchange Server 5.5. In fact, Exchange 2007 does not use a site service account. Instead, all services start as the local computer account.

If your logon account is the Administrator account, a member of the root Domain Administrators, a member of the Enterprise Administrators groups, or a member of the Exchange Organization Administrators role, you are explicitly denied access to all mailboxes that are not your mailbox, even if you have full administrative rights over the Exchange system. All Exchange 2007 administrative tasks can be performed without having to grant an administrator sufficient rights to read other people's mail.

You can achieve the results that you want in the following ways, but do so only in accordance with your organization's security and privacy policies:

• In the Exchange Management Shell, use the following command to allow access to all mailboxes on a given mailbox store:

  Add-ADPermission -identity "mailbox database" -user "serviceaccount" -ExtendedRights Receive-As
  

• In the Exchange Management Shell, use the following command to allow access to an individual mailbox:

  Add-MailboxPermission -identity "user" -user "serviceaccount" -AccessRights FullAccess
  

Return to top

Q: Why can domain administrators spoof mailbox-enabled user accounts in their domain?

A: Active Directory includes a base set of permissions that can be applied against objects in the directory. In particular, Active Directory includes the Send As extended permission. By default, the Administrators group, the Domain Admins group, the Enterprise Admins group, and the Account Operators group have Send As permissions for all users. The Administrators group permissions and the Enterprise Admins group permissions are inherited from the domain level. The Account Operators group and the Domain Admins group receive explicit permissions that are based on the definition of the user object that is in the Active Directory schema.

You may want to consider implementing a Deny Send As ACE against administrators for user objects in the domain. If you decide to implement a Deny Send As ACE against administrators for user objects in the domain, consider the following:

• An explicit Allow ACE will override an inherited Deny ACE. That means that explicit ACEs are applied before inherited ACEs.

• Members of the Domain Admins group can remove the Deny ACE and add an explicit Allow ACE.

• The addition of a Deny ACE may have additional consequences in your environment.

If implementing a Deny Send As ACE against administrators for user objects in the domain puts your messaging environment at risk, you should implement one or more of the following:

• Limit the number of domain administrators in the domain by delegating specific tasks. For more information, see Best Practices for Delegating Active Directory Administration.

• Use auditing to monitor the account logon events for those accounts that are members of the Domain Admins group.

Return to top

Q: Why do members of the Enterprise Admins group and root Domain Admins group have full control in the Exchange organization?

A: In Exchange 2000 and later versions of Exchange Server, data about the Exchange organization is not stored in a separate directory. Exchange stores organizational data in Active Directory in the Configuration naming context. The forest administrators, who are members of either the Enterprise Admins group or root Domain Admins group, control all aspects of the directory and control the data that are stored in the directory. Forest administrators must control the directory because a single configuration change could adversely affect the whole forest. The Configuration naming context, and, by inheritance, the Exchange organization stored in the Configuration naming context, have the following permissions:

• Enterprise Admins – Full Control

• Root Domain Admins – Read, Write, Create All Child Objects, Special Permissions

In addition to the inherited permissions, Exchange Setup adds a Deny ACE for Send As and Receive As for the Enterprise Admins group and root Domain Admins group. This prevents those administrators from accessing and spoofing mailboxes in the forest. For more information, see Exchange 2007 Server Setup Permissions Reference.

You cannot remove inheritance from the Exchange organization node in the configuration naming context. If the messaging administrators do not trust the forest administrators, the messaging administrators should consider isolating Exchange in its own forest. For more information about deployment options, see the Exchange Server 2007 Deployment.

If you cannot isolate the Exchange organization in a separate forest, we recommend that you perform one or more of the following tasks:

• Limit the number of enterprise administrators and domain administrators in the root domain by delegating specific tasks. For more information, see Best Practices for Delegating Active Directory Administration.

• Use auditing to monitor the account logon events for those accounts that are members of any privileged groups. These include the Enterprise Admins group and the root Domain Admins group.

• Use auditing to monitor changes that occur in the CN=<Exchange Organization>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<root domain> part of the directory.

Return to top

Q: Why can members of the Account Operators group modify the Exchange server security groups?

A: A privileged group, such as the Account Operators security group, is granted specific permissions in Active Directory. In particular, the Account Operators security group is granted explicit Full Control permissions for every object in the domain partition so that the group can manage the objects.

You may want to consider implementing a Deny access control entry (ACE) for Account Operators for those security groups. If you decide to implement a Deny ACE, consider the following:

• Account Operators are granted full control by using an explicit ACE on the objects in the directory. This means that you must put an explicit Deny ACE on each group you want to restrict. Be aware that an explicit Allow ACE overrides an inherited Deny ACE.

• The addition of a Deny ACE may have additional consequences in your environment. For more information, see Planning and Implementing a Split Permissions Model.

If implementing a Deny ACE against Account Operators or other privileged groups for the Exchange security groups puts your messaging environment at risk, you should implement one or more of the following:

• Limit the number of Account Operators in the domain by delegating specific tasks. For more information, see Best Practices for Delegating Active Directory Administration.

• Use auditing to monitor the account logon events for those accounts that are members of the Account Operators security group.

• Use auditing to monitor changes to the Exchange security groups.

Q: Why is there a special service account in Exchange Server 5.5, when Exchange 2007 services can start as the LocalSystem (built-in computer account)?

A: Exchange Server 5.5 required a special logon account for its services because of a limitation with Microsoft Windows NT 4.0. Although local computer accounts in Windows NT 4.0 had tokens, they did not have credentials. Therefore, one computer account could not authenticate to another. In Windows Server 2003, Kerberos authentication is used, and computer accounts have both tokens and credentials.

It is more secure to use the local computer account than an administrator-specified account for the following reasons:

• The local computer password is a random hexadecimal number, instead of a human-readable string.

• The local computer password changes automatically every seven days.

• The Exchange Server 5.5 service account has to be excluded from lockout policies because a brute force attempt to log on could disable the account and shut down the Exchange services.

Return to top

Exchange 2007 Management

Q: What permissions do I need to create and delete Exchange 2007 users?

A: If you are responsible for both user and mailbox management, you must have permissions to create and manage recipient objects in Active Directory. For example, you could be a Domain Admin or Account Operator, or you might have delegated access to a specific organizational unit. Be aware that members of child-domain privileged accounts must also have the Exchange View-Only Administrator role to manage the mail-related properties from the Exchange Management Console and Exchange Management Shell. If you do not have elevated permissions, you must have the following permissions:

• The Exchange Recipient Administrator role or have been delegated the appropriate permissions. For more information about how to delegate recipient administration, see Planning and Implementing a Split Permissions Model and Permission Considerations.

  • To move the mailbox between servers, the administrator must be an Exchange Organization Administrator or have been delegated the Exchange Server Administrator role on the source and destination servers.

• Appropriate permissions in the domain partition to create, delete, and manage the objects in question.

Additionally, if you manage public folder objects, we recommend that the administration account, which is the account that you log on as when you manipulate objects in the Exchange Management Console or Exchange Management Shell, be mail-enabled or mailbox-enabled. In some cases, odd behavior in the permission user interface and errors in display name resolution may occur if the account that administers public folder objects is not mail-enabled or mailbox-enabled.

For more information, see the "Other Problems" topic in the "Troubleshooting and Repairing Exchange Server 2003 Store Problems" section of Working with Exchange Server 2003 Stores.

Return to top

Q: Why do I need additional permissions not provided with the Exchange Recipient Administrator role to perform certain operations against mailboxes, such as changing the mailbox type?

A: In order to convert a mailbox from one type to another, we must make several changes in Active Directory that may require elevated privileges that the Exchange Recipient Administrator role does not provide.  An example, scenario where we want to convert a user mailbox to a room mailbox is as follows:  Resource mailboxes, by design, are disabled user accounts that are mailbox-enabled, whereas user mailboxes are mailbox-enabled user accounts.  So, to convert the mailbox from a type of UserMailbox to a type of RoomMailbox, we have to disable the user account. This requires changing the user’s attribute userAccountControl from value 512 (enabled) to 514 (disabled).  In addition, because the account is now disabled, for the mailbox to continue being used, we have to set the msExchMasterAccountSID attribute and apply the appropriate permissions.  In this case, we are not assigning a linked account, but instead assigning the NT AUTHORITY\SELF privilege to the msExchMasterAccountSID attribute.  In addition, we need to ensure that the NT AUTHORITY\SELF privilege has the appropriate permissions so that mail flow and the mailbox are not affected.  We do this in two ways.  First, we grant the NT AUTHORITY\SELF privilege full access to the mailbox by updating the mailbox security descriptor.  Second, we grant the NT AUTHORITY\SELF privilege the Send-As extended right and read and write access to the Personal Information property set (so that publicDelegates and other attributes can be managed by NT AUTHORITY\SELF).

Q: What permissions do I need to modify the mailbox permissions of a user object?

A: To correctly modify the mailbox permissions through the Exchange Management Shell, you must have the following permissions:

• Exchange View-Only Administrator role

• Administer Information Store permission granted on the mailbox store where the mailbox resides

• Write permission granted on the mailbox store where the mailbox resides

Q: What permissions do I need to move a mailbox between Exchange mailbox stores?

A: The Move Mailbox functionality that can be accessed from the Exchange Management Console and Exchange Management Shell logs on to the source mailbox and moves the folders and messages to the destination mailbox. You can move mailboxes between mailbox stores in the same storage group, across different storage groups on the same server, and between Exchange servers. You must have permissions on the user object in Active Directory to modify its Exchange mailbox attributes. A user who is an Account Operator will have these permissions. You must also have the following permissions:

• Exchange Organization Administrator role or be delegated the Exchange Server Administrator role on the source and target Exchange 2007 mailbox servers.

  Note

  If you move mailboxes between administrative groups in an Exchange 2007–Exchange 2003 mixed environment, you must be delegated the Exchange Administrator role on the source and target administrative groups.

• Member of the Administrators group on the local workstation or server to create a dynamic MAPI profile

Return to top

Q: What permissions do I need to create a new mailbox or public folder store or a storage group on an Exchange 2007 server?

A: You must be logged on with the following permissions:

• Exchange Organization Administrator role or be delegated the Exchange Server Administrator role on the Exchange 2007 mailbox server

  Note

  Exchange Server Administrators cannot create public folder databases.

Q: I have noticed that several of the security identifiers (SID) for various Receive connectors and Send connectors do not resolve. Why is that?

A: Some logical groups that are used to assign permissions for various Receive connectors and Send connectors are represented by an SID and do not have a display name. In those cases, the Get-ADPermission cmdlet only outputs the SID. The following SIDs have been defined in Exchange 2007 Transport:

• Hub Transport servers in the same organization: S-1-9-1419165041-1139599005-3936102811-1022490595-21

  Note

  For authentication and authorization between two Hub Transport servers in the same domain, the computer account that is a member of the Exchange Servers security group is used.

• Trusted Edge Transport servers: S-1-9-1419165041-1139599005-3936102811-1022490595-22

• Trusted third-party servers, serving the same authoritative domain or domains: S-1-9-1419165041-1139599005-3936102811-1022490595-23

• Exchange 2003 servers in the same organization: S-1-9-1419165041-1139599005-3936102811-1022490595-24

• Partner transport servers: S-1-9-1419165041-1139599005-3936102811-1022490595-10

Return to top

Q: What permissions do I need to search for a message?

A: To search multiple mailboxes by using the Export-Mailbox task, the administrator must have the following permissions:

• Exchange Server Administrator role or higher on the source and target Mailbox server

• Member of the Local Administrators group on the local workstation or server where the task is being run

Q: What permissions do I need to track a message?

A: The following permissions are required to track a message:

• For the release to manufacturing (RTM) version of Exchange 2007   Exchange Server Administrator role or higher on the Mailbox and Hub Transport servers that the task might query

• New in Exchange 2007 Service Pack 1   Exchange View-Only Administrator role or higher within the organization

• Local administrator on the Edge Transport server

• Local administrator on the workstation where the task is being run

  Note

  In Exchange 2007 RTM, you must restart the Microsoft Exchange Transport Log Search service after granting the Exchange Server Administrator role to an administrator if you want the administrator to track messages.

Q: What permissions do I need to run the Exchange Troubleshooting Assistant?

A: The following permissions are required to run the Exchange Mail Flow Analyzer:

• Domain Administrator or a member of the BUILTIN\Administrators group on the Active Directory server for enumerating Active Directory information and calling the Microsoft Windows Management Instrumentation (WMI) providers on domain controller and global catalog servers

• Member of the Local Administrators group on each Exchange server for calling the WMI providers and accessing the registry and IIS metabase

• Exchange View-Only Administrator role or higher

The permissions that are required to run the Exchange Performance Troubleshooting Analyzer are as follows:

• Domain User or higher permissions on the global catalog server specified in the connections step

• Member of the local Administrators group on each server that is running Microsoft Exchange and that is to be analyzed. These permissions are required to access WMI, the registry, and performance data.

The permissions that are required to run the Exchange Disaster Recovery Analyzer are as follows:

• Member of Local Administrators group on each Exchange server for calling the WMI providers, accessing the registry and IIS metabase, and accessing the database and transaction log files and the database engine

• Exchange Server Administrator role or higher on each server

Return to top

Q: What permissions do I need to run the Microsoft Exchange Best Practices Analyzer?

A: To run the Exchange Best Practices Analyzer, you must have the following permissions:

• Exchange View-Only Administrator role or higher

• Machine Administrator permissions for enumerating Active Directory information and calling the WMI providers on DC or GC servers

• Member of Local Administrators group on each Exchange server for calling the WMI providers and accessing the registry and IIS metabase

Q: What permissions do I need to manage message queues?

A: To manage message queues, you must have the following permissions:

• On Edge Transport servers, you must be a member of the local administrators group.

• For Exchange 2007 RTM   On Hub Transport servers, you must be a member of the Exchange Server Administrator role or higher.

• New in Exchange 2007 Service Pack 1   On Hub Transport servers, you must be a member of the Exchange View-Only Administrator role or higher to view the queues. If you want to manipulate the queues, you must be a member of the Exchange Server Administrator role or higher.

Return to top