Using Multiple Forests with Exchange

 

Although a single-forest topology is recommended because it provides the richest set of messaging features, there are various reasons for implementing multiple forests. Some of these reasons include:

  • You have multiple business units that require data and service isolation.

  • You have multiple business units that have separate schema requirements.

  • You are confronted with a merger, acquisition, or divestiture.

Whatever the case may be, the only way to establish strict boundaries between business units is to create a separate Active Directory forest for each business unit. If this is your Active Directory configuration, the preferred way to implement Exchange is to create an Exchange resource forest. For more information about this, see "Using a Dedicated Exchange Forest." For additional information on how mergers and acquisitions can impact your Active Directory topology, see "Active Directory Implications of Mergers and Acquisitions."

However, if the resource forest option is not feasible (for example, with mergers or acquisitions, or because multiple forests are already running their own instances of Exchange), you can implement Exchange across multiple forests, as illustrated in the following figure.

Exchange deployed in multiple forests, with synchronization between forests (classic multiple forest configuration)

2c4b3dc0-c1e1-40b8-941c-4ed604ef11ce

This implementation is the classic multiple forest configuration. In this scenario, a company has multiple Active Directory forests, each containing an Exchange organization. Unlike the resource forest scenario, user accounts are not separated from their mailboxes. Instead, a user account and its associated mailbox are in the same forest. The main advantage to implementing the classic multiple forest scenario is that you can maintain data isolation and security boundaries between the Exchange organizations.

The disadvantages associated with this scenario include the following:

  • The multiple forest scenario does not provide the richest set of messaging features.

  • Rules are not preserved during a cross-forest move.

  • Because a user or group from another forest is represented as a contact, you cannot delegate mailbox access to someone in another forest. Contacts cannot be designated in a mailbox's access rights.

  • Mailbox delegate permissions are not preserved when you move mailboxes from one forest to another.

  • Although you can synchronize free and busy information across forests and use it to schedule meetings, you cannot use the Open Other User's Folder feature in Microsoft Office Outlook® to view the calendar details for a user in another forest.

  • Because a group from another forest is represented as a contact, you cannot view the group's members. Group membership is not expanded until mail is sent to the source forest.

  • A front-end server cannot proxy requests to a back-end server in a different forest. This limitation applies whether you are using a front-end server for Outlook Web Access or Outlook Mobile Access.

  • When upgrading a multiple forest organization from Exchange 5.5 to Exchange 2003, as you disconnect the Exchange 5.5 directory replication connectors (DRCs), information is no longer replicated to other forests until the new synchronization tool (such as MIIS 2003) takes effect. Therefore, some information (such as distribution list membership) is lost and must be manually re-entered.

Keep these issues in mind when deciding whether you want to deploy single or multiple forests. If you currently have separate Exchange 5.5 sites and want to retain these boundaries, you should evaluate the advantages and disadvantages of deploying multiple Active Directory forests and Exchange 2003 organizations.

For more information about configuring Exchange in a multiple forest environment, see "Planning to Deploy Exchange in a Multiple Forest Environment."