Using a Dedicated Exchange Forest

 

There are some cases in which you may need to set up a separate Active Directory forest that is dedicated to running Exchange. For instance, you may have a Windows NT forest that you want to retain. Or, you may need to separate administration of Active Directory objects and Exchange objects; therefore, you may want to set up a separate Active Directory forest dedicated to running Exchange. Companies that require security (forest) boundaries between Active Directory administration and Exchange administration may choose this option.

The Exchange forest (also known as the resource forest) is dedicated to running Exchange and hosting mailboxes. User accounts are contained in one or more forests, referred to as the account forests, which are separate from the resource forest. For more information about deploying Exchange in a multiple forest environment, see Planning to Deploy Exchange in a Multiple Forest Environment.

The enabled user from the account forest is associated with a mailbox attached to a disabled user in the resource forest. This configuration allows users to access mailboxes that reside in different forests. In this scenario, you configure a trust between the resource forest and the account forest. You may also need to set up a provisioning process so that each time an administrator creates a user in Active Directory, a disabled user with a mailbox is created in Exchange.

Note

If the user accounts have a security identifier (SID) history, you must turn off SID filtering between the account forest and the resource forest (otherwise, users will not be able to access their mailboxes). Two ways in which accounts acquire a SID history are:
•   If you follow the external migration path to migrate from Exchange 5.5 to Exchange 2003, each new account retains its old SID in the SIDHistory attribute.
•   If you use the Active Directory Migration Tool (ADMT) to move accounts from one forest to another, each new account retains its old SID in the SIDHistory attribute.

Because all Exchange resources are contained in a single forest, a single GAL contains all users across the entire forest. The following figure illustrates a dedicated Exchange forest scenario.

Separate, dedicated Exchange forest

The main advantage of the dedicated Exchange forest scenario is a security boundary between Active Directory and Exchange administration.

The disadvantages associated with this scenario include the following:

• Does not leverage the benefits of integrating Exchange and Active Directory administration, giving you more administrative overhead.

• Requires installing duplicate domain controllers and global catalog servers in Microsoft Windows® sites where Exchange will run, which increases the cost.

• Requires a provisioning process so that Active Directory updates are reflected in Exchange. (For example, creating a new Active Directory user in Forest A generates a mailbox-enabled placeholder object with permissions.) When you create an object in one forest, you must ensure that corresponding objects are created in the other forest. For example, if you create a user in one forest, ensure that a placeholder is created for that user in the other forest. You can create the corresponding objects manually, or you can automate the process by creating scripts or implementing third-party software.

  Important

  The GAL Synchronization feature of Microsoft Identity Integration Server 2003 (MIIS 2003) is not designed to work in a resource forest model (in which a user account exists in a separate forest from its mailbox). Although you cannot use the GAL Synchronization feature in MIIS 2003, you can configure MIIS 2003 to provision objects between a resource forest and an account forest. In addition, you can use GAL Synchronization to synchronize the resource forest and other Exchange forests (but not the account forest).

A variation of the resource forest scenario is multiple forests with one forest hosting Exchange. If you have multiple Active Directory forests, the way you deploy Exchange depends on the degree of autonomy you need to maintain between the forests. Companies with business units that require security (forest) boundaries for directory objects, but can share Exchange objects, may choose to deploy Exchange in one of the forests and use it to host mailboxes for the other forests in the company. Because all Exchange resources are contained in a single forest, a single GAL contains all users across all forests. The following figure illustrates this scenario.

Multiple Active Directory forests with one forest hosting Exchange

The main advantages associated with this scenario include the following:

• Leverages an existing Active Directory structure

• Uses existing domain controllers and global catalog servers

• Provides strict security boundaries between forests

The disadvantages associated with this scenario include the following:

• Requires a provisioning process so that Active Directory updates are reflected in Exchange. For example, creating a new Active Directory user in Forest A generates a mailbox-enabled object with permissions that is disabled in Forest B.

• Requires that forest administrators determine how to share or divide responsibilities for managing Active Directory and Exchange objects.