As you’ve learned from earlier articles, Exchange and Active Directory are tightly connected. One of the ways that Exchange uses Active Directory is to store various security groups that contain members who have special privileges within an Exchange organization. In Exchange 2000 and Exchange Server 2003, there were only a few groups. The Exchange Enterprise Servers group was a domain local security group created in the root domain of an Active Directory forest, and it contained as member all of the domain global security groups that which exist in each Active Directory forest where Exchange was installed. All of these groups are named Exchange Domain Servers. The Exchange Enterprise Servers group was created by forestprep, and the Exchange Domain Servers group was created by domainprep. All of these groups were required to be present in the default Users container for that domain (that is, for the Active Directory domain named example.com, they had to be present in example.com/Users or CN=Users, DC=example, DC=com). There was also a third possible domain global group, Exchange Services, created by the installation of the Active Directory Connector.

In Exchange 2000 and Exchange Server 2003, if you moved these groups outside of the default Users container, then setup would fail and the next time that System Attendant restarted (e.g., the next reboot of the Exchange Server), well it would actually fail to start. Note that this included use of the special utilities redirusr and redircmp (described in KB 324949). If you put those utilities to use, you would manually have to move the groups back to the default User container.

In Exchange Server 2007, Microsoft changed this behavior and created an organizational unit off the forest root domain especially for Exchange’s use. At RTM, there were five universal groups in most environments and another was added with service pack 1. Those groups are:

Exchange Organization Administrators
Exchange Public Folder Administrators (added in SP1)
Exchange Recipient Administrators
Exchange Servers
Exchange View-Only Administrators
ExchangeLegacyInterop

The last group, ExchangeLegacyInterop, is only present if PrepareLegacyExchangePermissions was executed (that is, if the Exchange environment was upgraded from Exchange 2000 or Exchange Server 2003). Along with the elimination of Administrative Groups and Routing Groups in Exchange Server 2007, these groups actually allow for a simplification of Exchange administrative privileges (more on that in our next article).

Another feature provided by Exchange Server 2007 is that these groups may be moved anywhere within a forest. While they are created in the forest root domain, Active Directory provides a feature known as otherWellKnownObjects which Exchange uses for locating these groups. As a quick sidebar, every object in an Active Directory has a GUID attached to it. A GUID is a Globally Unique Identifier. Active Directory provides an interface where any object - including a group - can be accessed using the GUID, instead of using the object’s name. And that GUID can be anywhere in the entire forest. Also, using the otherWellKnownObjects functionality, it is possible to register a set of GUIDs that are to be tracked (loosely stated) by Active Directory as they are moved from place to place. For the Exchange groups, these objects are tracked at CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=example, DC=com (for the example.com forest, and the Configuration container of every domain in that forest).

A final comment about moving these groups… If you are in a single-domain environment, you will have no issue with executing a move, whether using the GUI or a script. However, if you are moving the groups from one domain to any other domain, you must ensure that you execute the move from the domain controller holding the RID master FSMO role of the source domain.