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.

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

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.

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

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

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.

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
  
  

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.

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).

Note:
If you have implemented other policies on your domain controller organizational units, you must add this permission to the highest applicable policy.

Return to top

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.

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

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.

Note:
The permission structure may change in future versions or service packs of Microsoft Exchange. Therefore, we recommend that you allow inheritance, or at the very least, monitor permission changes when you deploy new versions of Microsoft Exchange so that the containers that have inheritance blocked can be updated accordingly.

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

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
  
  

Note:
The Exchange Organization Administrator role is required to install the first server for each Exchange 2007 server role.

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
  
  

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

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. 

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.

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

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

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

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:
  
  

  	Copy Code
  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:
  
  

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

Return to top

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

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

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.
  
  

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

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

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).

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
  
  

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

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.

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

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
  
  

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.

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

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
  
  

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