Active Directory Forest Topologies

Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

 

Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3

Because Microsoft Windows Server 2003 and Microsoft Exchange Server 2007 both rely on the Active Directory directory service for directory services, you must determine how to integrate Exchange 2007 into your Active Directory structure. Active Directory includes the following logical elements that combine to define an Active Directory topology:

• Forest

• One or more domains

• One or more Active Directory sites

Active Directory Forests

A forest represents the outermost boundary of the directory service. A forest operates within the context of a continuous security context such that all resources within a forest implicitly trust each other regardless of where in the forest they are located. Within each forest, there is a common directory schema and configuration of the directory service. A forest can be comprised of one or more domains. There are two types of forest topologies: the single forest and the multiple forest.

Single Forest Topology

In a single forest topology, Exchange is installed into a single Active Directory forest that spans the whole organization. All user and group accounts and all Exchange configuration information are located in the same forest.

If your organization has a single Active Directory forest, you can implement Exchange 2007 in that forest. We recommend the single forest Exchange design because it offers the richest set of e-mail system features, and also because it has the most streamlined administrative model. Because all resources are contained in a single forest, a single global address list (GAL) contains all users across the forest. The following figure illustrates this scenario.

Two examples of implementing Exchange in a single Active Directory forest

The single forest option offers the following advantages:

• Provides the richest set of e-mail system features.

• Provides a streamlined administrative model.

• Takes advantage of an existing Active Directory structure.

• Uses existing domain controllers and global catalog servers.

• Does not require GAL synchronization.

The main disadvantage associated with a single forest is that administrators must determine how to share or divide responsibilities for managing Active Directory and Exchange objects.

Multiple Forest Topology

Although we recommend a single forest topology because it provides the richest set of messaging features, there are various reasons you may want to implement multiple forests. Some of these reasons include:

• You have multiple business units that require messaging service isolation.

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

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

Whatever the reason, 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 Exchange resource forests, see "Resource Forest Topology" later in this topic.

However, there are scenarios in which a resource forest may not be feasible (for example, with mergers or acquisitions or when multiple forests are already running their own instances of Exchange). In these cases, you can implement a cross-forest topology.

Cross-Forest Topology

In a cross-forest topology, a company has multiple Active Directory forests, each containing an Exchange organization. Unlike a resource forest topology, 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 a cross-forest topology is that you can maintain data isolation and security boundaries between the Exchange organizations. The disadvantages associated with this topology include:

• The richest set of messaging features is not provided.

• Mailbox delegate permissions are not preserved when you move mailboxes from one forest to another unless there is a contact for the delegate in the target forest, or unless you move the delegate mailbox at the same time.

• Although you can synchronize free/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 forest containing the group that is represented as the contact.

• Synchronization of directory objects across forests, as well as replication of free/busy data information is required. The most commonly used solutions for directory synchronization are Microsoft Identity Integration Server (MIIS) 2003 Service Pack 2 (SP2) or Identity Integration Feature Pack for Microsoft Windows Server Active Directory with SP2. The Availability service in Exchange 2007 can be used to share free/busy and calendaring information between Exchange organizations in different forests.

Exchange in a cross-forest topology

Resource Forest Topology

There are some cases in which you may have to set up a separate Active Directory forest that is dedicated to running Exchange. For example, you may have an existing Active Directory forest that you want to retain. Or, you may have to separate the administration of Active Directory objects and Exchange objects. Therefore, you may want to set up a separate Active Directory forest that is dedicated to running Exchange. The separate dedicated forest is referred to as an Exchange resource forest. In the resource forest model, Exchange is installed in an Active Directory forest that is separate from the Active Directory forest where users, computers, and application servers are installed. Companies that require security boundaries between Active Directory administration and Exchange administration typically use this option.

The Exchange resource forest is dedicated to running Exchange and hosting mailboxes. User accounts are contained in one or more forests called the accounts forests. Accounts forests are separate from the Exchange resource forest. A one-way trust between the accounts forest and the Exchange resource forest is created and allows the Exchange forest to trust the accounts forest so that users in the accounts forest are granted access to mailboxes in the Exchange resource forest. Because an Exchange organization cannot cross an Active Directory forest boundary, each mailbox that is created in the Exchange resource forest must have a corresponding user object in the Exchange resource forest. The user objects in the Exchange resource forest are never logged on to by a user and are disabled to prevent them from being a point of exploitation. Users are typically not even aware that the duplicate account exists. Because the account in the Exchange resource forest is disabled and not used for logon purposes, a user's real account from the account forest must be granted access to log on to the mailbox. Access is granted by including the security identifier (SID) of the accounts forest user object in the msExchMasterAccountSID attribute on the disabled user object in the Exchange resource forest.

When an Exchange resource forest is used, it is possible that directory synchronization will not be required. From the perspective of Exchange and Outlook, all the objects that are listed in the directory service are sourced from a single location, in this case, the directory service that hosts the Exchange resource forest. However, if GAL-related data is present in the account forests, synchronization must occur to get the data into the Exchange resource forest for GAL usage. In addition, you may need to set up a process so that when accounts are created in the accounts forest, a disabled account with a mailbox is created in the Exchange resource forest.

The enabled user from the accounts 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 relationship between the resource forest and the accounts forest. You may also have to set up a provisioning process so that every time an administrator creates a user in the accounts forest, a disabled user with a mailbox is created in the Exchange resource forest.

Because all Exchange resources are contained in a single forest, a single GAL contains all users across the 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 topology include:

• Implementing a resource forest allows for segregation of Exchange and Active Directory administration, however, the cost associated with deploying a resource forest may outweigh the need for this segregation.

• Installing additional domain controllers and global catalog servers in Microsoft Windows sites where Exchange will run is required, thereby increasing cost.

• Provisioning process is required so that Active Directory updates are reflected in Exchange. When you create an object in one forest, you must make sure that corresponding objects are created in the other forest. For example, if you create a user in one forest, make sure 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.

A variation of the resource forest scenario is a multiple forest where one forest hosts Exchange. If you have multiple Active Directory forests, how you deploy Exchange depends on the degree of autonomy that you want 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 main advantages associated with this scenario include:

• Uses 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:

• Requires a provisioning process so that Active Directory updates are reflected in Exchange. For example, you can create a script so that 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.

Exchange in a resource forest topology

Active Directory Domains

A domain is a grouping of security principals and other objects that are administered collectively. Domains are flexible. The implementation of what comprises a domain is open and subject to an administrator's discretion. For example, a domain can represent a group of users and computers that are located at a single physical location, or it can represent all users and computers across many locations or a large geographical region. As consolidation of administration and infrastructure support occurs, it is common for domains to be deployed across large geographical areas to decrease support costs. However, as the scope of a directory service increases, it is necessary to be able to target directory access to the appropriate resources as efficiently as possibly.

Active Directory Sites

Active Directory sites represent a logical grouping of computers within Active Directory that have reliable connectivity. With an Active Directory site, it is possible to partition client computers to use a particular set or group of directory resources. An Active Directory site is one or more well-connected TCP/IP subnets that allow administrators to configure Active Directory access and replication. These subnets may or may not correspond to the physical topology.

The following figure illustrates some of the more commonly deployed relationships between Active Directory logical definitions and physical locations.

Forests, domains, locations, and sites

Active Directory Deployment Scenarios

There are four main scenarios for integrating Exchange with Active Directory:

• Single forest

• Resource forest

• Cross-forest

• Mergers and acquisitions

The following table summarizes the benefits of each scenario.

Active Directory scenario	Description	Why you use this scenario
Single forest	Users and their mailboxes are contained in the same forest.	Richest set of mail system features Streamlined administration Uses existing Active Directory structure Does not require synchronization with other forests
Resource forest	One forest is dedicated to running Exchange and hosting Exchange mailboxes. The user accounts associated with the mailboxes are contained in one or more separate forests.	Security boundary between Active Directory and Exchange administration Easier deployment of Exchange in a multiple forest environment Limited control of network and user account infrastructure
Cross-forest	Exchange runs in separate forests, but e-mail functionality is available across forests.	Multiple business units require data and service isolation Multiple business units have separate schema requirements Merger, acquisition, or divestiture
Mergers and acquisitions	Mergers and acquisitions frequently involve coexistence between Exchange organizations until they are merged. The planning considerations are similar to those of the multiple forest scenario, with additional migration concerns.	Mergers and acquisitions are a special case for a multiple forest deployment that requires extra attention to migration issues