Although the majority of small- and medium-sized organizations deploy a single Active Directory forest, a significant portion of large organizations recognize and accommodate the need to deploy multiple forests. A multi-forest design carries higher administrative and support costs, and complicates collaboration and messaging. However, it offers the highest level of security isolation. In addition, some companies consider a multi-forest design because of organizational structure issues (such as autonomous business units and decentralized IT departments), business policy, or legal and regulatory requirements.
If a company chooses a multi-forest design, one of the main questions that arise is the setup of the Exchange messaging system.
An Exchange organization consists of one or more Exchange servers, and each Exchange organization is specific to one Active Directory forest. Exchange servers rely on access to the global catalog for address information. Because each forest has a separate global catalog, an Exchange organization is associated with only one forest.
Having multiple Exchange organizations hinders user collaboration and requires cross-forest replication of Exchange data between the organizations. To enable multiple Exchange organizations to function as a single business organization, additional configuration is required to synchronize the Exchange mail recipients in the respective directories in each Exchange organization.
Therefore, a preferred deployment option could be to have multiple forests use the same Exchange organization for mail service. A single Exchange organization that serves multiple forests does not require cross-forest synchronization of mail recipient data because the organization uses only one forest for its Active Directory storage and services.
Whether a single Exchange organization serves one forest or more than one forest, the Exchange organization is still associated with only one of the forests, called the Exchange forest (or resource forest). Users that have accounts in one forest might have mailboxes in the same forest or in a different forest; however, mailboxes are always in the same forest as the Exchange servers because mailbox data is stored on the Exchange servers.
The following figure shows an Exchange organization that has mailboxes on Exchange servers in one forest and user accounts in a different forest. In this scenario, the user account in an accounts forest has a disabled account that represents the user’s mailbox in the Exchange forest.
Figure 1: Processes automated by Active Roles SPML Provider
In the scenario where multiple forests share a single Exchange organization, Exchange servers are installed only in the Exchange forest. Users have their accounts in accounts forests and their mailboxes are stored in the Exchange forest. To associate a user with a mailbox, a disabled user account (shadow account) is created for that user in the Exchange forest. A mailbox is then created for the shadow account, with a certain attribute on the shadow account referencing the user’s account held in the accounts forest. This type of Exchange environment is known as the Exchange resource forest model.
The main advantage of the Exchange resource forest model is a security boundary between Active Directory and Exchange administration. Also, a single Exchange organization provides for a single Global Address List (GAL), preserves all Exchange collaboration capabilities, and uses native Exchange data replication, thus lowering administrative overhead.
The major problem that arises in the resource forest model is that the separate Exchange forest and the various accounts forests require directory synchronization between them. A provisioning process needs to be set up so that each time an administrator creates a user account in an accounts forest, a shadow account with a mailbox is created in the Exchange forest. The account properties must also be synchronized between the accounts forest and the Exchange forest. These processes cannot be automated using native Active Directory mechanisms, which leads to the need for a third-party solution.
Exchange Resource Forest Management extends the Active Roles capabilities to enable the management of mailbox users in Exchange environments leveraging the resource forest model. The following figure illustrates the processes that are automated by Exchange Resource Forest Management.
The AutoProvision, Synchronize, and Deprovision processes maintain the shadow accounts in the Exchange forest in sync with the master accounts upon creation, modification, deprovisioning, or deletion of master accounts in accounts forests.
The AutoProvision process creates a shadow account in the Exchange forest upon:
Then, the AutoProvision process creates a linked mailbox associated with that shadow account, designating the user from the accounts forest as the linked master account for that mailbox.
To maintain a link between the master account and shadow account, Exchange Resource Forest Management assigns the globally unique identifier (GUID) of the shadow account to a certain attribute of the master account (the adminDescription attribute by default).
Normally, the AutoProvision process creates a shadow account with the same name as the name of the user from the accounts forest. In case of a name conflict, a different name is used to ensure the uniqueness of the shadow account’s name.