Installing Exchange 2013 : Security groups and accounts Exchange creates

Alongside the schema changes made to support server functionality, the Exchange installation procedure adds a number of security groups and mail-enabled accounts to Active Directory that Exchange uses for different purposes. Table 1 lists the security groups Exchange creates in Active Directory and their purpose. Most are universal security groups (USGs), which are created in a new organizational unit (OU) called Microsoft Exchange Security Groups in the root domain of the forest. As indicated in Table 1, many are used to hold the security principals required to enable users to perform the tasks assigned to role groups defined in the Exchange role-based access control mechanism, though you shouldn’t change the membership of these groups directly; use the role-based access control (RBAC) tools to do so.

Table 1. Exchange USGs created in Active Directory

Group Purpose RBAC
Compliance Management Administrative role group for users who need to work with Exchange compliance features such as data loss prevention policies and retention policies. Yes
Delegated Setup Administrative role group for accounts that complete the setup for an Exchange server after it has been provisioned by an organization administrator. Yes
Discovery Management Administrative role group for accounts that perform discovery searches and retrieval of discovered information from user accounts. Yes
Exchange Servers Every Exchange server in the organization is a member of this group, which is used to allow the servers to authenticate against one another mutually. No
Exchange Trusted Subsystem A highly privileged group that has read-write access to every object in the Exchange organization. Unless the Active Directory split permissions model is used, this group is a member of the Administrators local group and the Exchange Windows Permissions group and can create and update Active Directory objects. Exchange system components such as the System Attendant and Information Store processes use the access granted through this group to perform tasks. Removal of this group from other groups or access control lists (ACLs) will invariably cause Exchange to malfunction. If you deploy Exchange 2007 SP3, you’ll find that the Exchange Trusted Subsystem group is created in the Microsoft Exchange Security Groups OU to support interoperability among Exchange 2007, Exchange 2010, and Exchange 2013. No
Exchange Windows Permissions A privileged group Exchange uses to manipulate Windows permissions and Active Directory objects. No
Exchange LegacyInterOp A group Exchange uses to perform privileged operations with older servers in the same organization. No
Help Desk Administrative role group that enables users to perform common help desk tasks such as modifying options on behalf of a user. Yes
Hygiene Management Administrative role group to manage tasks to cleanse the email stream such as anti-spam and antivirus. Yes
Organization Management Administrative role group for accounts that have permission to manage objects at an organization level such as to create new connectors or transport rules. Members have full control over any object in the Exchange container in Active Directory. The account used to install the first Exchange server in an organization automatically belongs to this group. Yes
Public Folder Management Administrative role group for accounts that have permission to manage (add, modify, delete) public folders and their settings (quotas, expiration periods, and so on). Although these accounts can mail-enable a public folder, they cannot change mail-enabled attributes for a folder (such as an email address) because this requires recipient management status. Yes
Recipient Management Administrative role group for accounts that have permission to manage mailboxes, distribution groups, and other recipient types. Yes
Records Management Administrative role group for accounts that need to perform records management tasks such as the definition of a managed folder mailbox policy. Yes
Server Management Administrative role group for accounts that need to perform server-specific management tasks such as monitoring messaging queues, configuring virtual directories, and so on. Yes
UM Management Administrative role group for accounts that can manage Unified Messaging. Yes
View-Only Organization Management Administrative role group for accounts that have permission to view details of the Exchange configuration. Yes

In addition to the groups listed in Table 1, a group called Exchange Install Domain Servers is created in each domain that supports an Exchange server. This group is created during the installation of the first Exchange server in a domain and is added to the membership of the Exchange Servers USG in the Microsoft Exchange Security Groups OU. The setup program uses it to ensure that it can complete even if Active Directory replication has not yet populated details of the USG in the local domain. It is therefore best to wait for replication to finish before you attempt to install a server.

Exchange creates a small number of mail-enabled accounts in the default Users OU of the root domain in the Active Directory forest. Microsoft could have created these accounts in a special OU but preferred to exploit the fact that you can usually guarantee that the Users OU is always available unless it has been removed for some reason by an administrator, so using it this way eliminated the need to create an additional OU. If you want, you can move these accounts to another OU. The accounts are named in such a way that it’s obvious that they are intended for system rather than human use:

  • SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}. Used to hold metadata about discovery searches. The display name for this account is Microsoft Exchange. This mailbox is also used to hold administrator audit log reports.

  • SystemMailbox{1f05a927-xxxx-xxxx-xxxx-xxxxxxxxxxxx}. Where x is a randomly assigned number, this account is for moderating messages, for storing details of move requests that are currently in progress, and for testing mail flow and Messaging Application Programming Interface (MAPI) connectivity. The display name for this account is Microsoft Exchange Approval Assistant.

  • FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042. Used for federation operations among different Exchange organizations and for Rights Management operations. This account also has a display name of Microsoft Exchange Approval Assistant.

  • DiscoverySearchMailbox{D919BA05-46A6-415f-80AD-7E09334BB852}. Used for storing the results of discovery searches so that administrators can retrieve these items. Exchange creates the default discovery mailbox with the name just shown. The mailbox is created in the mailbox database of the first Exchange 2010 server in the organization. You can create other discovery mailboxes to use with searches. For example, in a large, distributed organization, you might have separate discovery mailboxes for every country/region.

  • Exchange Online-ApplicationAccount (new for Exchange 2013). Used when a hybrid connection is created between Exchange 2013 and Exchange Online.

  • Migration.8f3e7716-2011-43e4-96b1-aba62d229136 (new for Exchange 2013). Used by the Migration Service to hold details of the mailboxes that are being moved in migration batches.

  • SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} (new for Exchange 2013). The default organization mailbox Exchange uses to hold files for the Offline Address Book as they are generated.


Apart from accessing the discovery mailbox to access the results of discovery searches , you should not attempt to log on to these accounts or use the mailboxes for anything other than management purposes. If you need to remove a server or database that hosts any of these mailboxes, you should move the mailboxes to another database first.

The Exchange Trusted Subsystem USG

The Exchange Trusted Subsystem USG is interesting from many perspectives. It is a highly permissioned USG that allows Exchange services read and write access to any object Exchange owns. Usually, you won’t need to touch the Exchange Trusted Subsystem group, but there are some known circumstances in which you might need to add it explicitly to an object. The most common is when you configure the file share witness for a DAG to be on a server that does not have Exchange 2013 installed on it. In this scenario, you need to add the Exchange Trusted Subsystem group to the local Administrators group on the server that holds the file share witness to enable that server to participate within the DAG.