Multiforest Deployments

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

The decision to deploy multiple forests is often associated with the need to manage directory services independently (autonomy) or to manage data or services without threat of interference (isolation). In Microsoft® Windows NT® 4.0 operating system deployments, the domain is the ultimate component and is discrete in its management and its boundaries. With the introduction of Active Directory® in Microsoft Windows® 2000, a new category of forest was introduced, and the forest has service and data implications for all domains.

Availability of service and data isolation or autonomy in an Active Directory domain depends not only on the administrator of that domain and forest administrators, but also on other domain administrators within a forest.

When designing your forest, keep in mind that administrative independence has a cost and that you must carefully consider the tradeoff between autonomy or isolation versus interoperation and collaboration.

Management Autonomy and Isolation

Management of Active Directory can be divided into two general categories:

• Service management: Configuration and delivery of the directory service.

• Data management: Creation and management of directory contents (account management, organizational unit administration).

Active Directory provides tools for the delegation of control over these areas of management, and delegation can occur at several levels, including forest, domain, and organizational units. At each of these levels and for each of their respective service or data categories, the need for independence can vary widely, depending on the nature of the organization.

In most cases, an appropriate and adequate level of control can be delegated within a single forest by using domains and organizational units to manage data and by the ability to trust service managers at the forest root level. However, the following requirements for independence can exceed the limitations of single-forest delegation of control:

• Service autonomy: Provides the ability to independently manage and manipulate the schema and configuration containers. The need for this level of control is usually driven by organizational structure or operational requirements. For example, one division of a company wants to install directory-enabled applications that extend the schema without depending on approval by the central Information Technology (IT) department.

• Service isolation: Provides the assurance that no administrator outside the organization can interfere with the operation of the directory service. The need for this level of control is usually driven by legal or operational requirements. For example, suppose a hosting company needs to place domain controllers on a customer’s premises. If a breach of domain controller security can affect service delivery in the rest of the forest, that customer’s operations can be separated into its own forest to better protect other clients of the directory service.

• Data isolation: Provides the assurance that no service administrators outside of a limited scope of administrators can control or view any subset of data on a domain controller or on member computers joined to the forest. The need for this level of control is usually based on a legal requirement. For example, a financial institution might be required by law to limit access to data that belongs to clients in a particular jurisdiction to the users, computers, and administrators in that jurisdiction.

Unplanned Deployments

The need for multiforest deployment is not always planned in advance. A change from a single-forest deployment to a multiforest deployment might be required to accommodate the following business decisions:

• Mergers and acquisitions: Assuming the merged or acquired organizations operate one or more existing forests, you might need to enable collaboration between users and resources from the different parts of the new and original organizations.

• Divestitures: When a decision is made to divest your company of certain portions of the organization, you can create a forest to accommodate the users and resources in the departments that are being transferred in advance of the actual organizational spin-off and enable collaboration between the original forest or forests and the spun-off forest.

• Grass-roots deployments: In the event that one or more divisions within your organization deploy their own forest without consulting the central IT department, consider the following courses of action:

  • If no central forest has yet been deployed by the IT department, use the existing forest as the main forest for the entire organization, provided the existing forest satisfies your Active Directory design requirements.

  • If an IT forest already exists, merge the IT forest and the grass-roots forest into a single, central IT forest.

  • If an IT forest already exists, implement a multiforest deployment.

Levels of Collaboration

The level of collaboration determines which functionality needs to be enabled across the forests and, as a result, determines part of the additional cost associated with deploying multiple forests. As the first step in evaluating the cost of enabling functionality across forests, assess the level of collaboration that your business requires. Use the following example scenarios to help determine the functionality you want to enable on the basis of the needed levels of collaboration.

Scenario 1: Organizations Share Only Address List Information

For organizations that require operational and organizational independence, collaboration needs are minimal. For example, a holding company for banks manages businesses that remain competitors. Because the businesses compete, they do not merge to a single forest, modify the messaging system, nor share any resources. Employees of these banks, however, need the ability to look up the phone numbers, office locations, and perhaps managerial information of personnel in the other divisions of the company, and to communicate by e-mail.

These organizations have the following operating conditions and requirements:

• No resource sharing.

• No authentication of users across forests.

• Independent Exchange Server organizations, but commonly viewable global address list between the forests.

In this scenario, the only collaboration requirement is the need to view address information of the users in different forests. The only configuration that is required for this scenario is to enable Exchange address list synchronization between the forests. The cost of this added functionality is that of deploying and operating a directory data synchronization product such as Microsoft Identity Integration Server 2003. An integrated address list synchronization solution works in conjunction with Microsoft Identity Integration Server 2003 to implement address list synchronization.

For more information about implementing address list synchronization, see “Synchronizing Exchange Data Across Forests” later in this paper.

Scenario 2: Organizations Share Schedule Information

In this scenario, in addition to the ability to view address list information, users in the separate forests need to schedule meetings with each other and to use other workflow applications that use Exchange public folders. An example of an organization that requires this type of collaboration is a holding company that includes multiple companies (for example, pharmaceutical companies) that compete with each other. For this reason, the companies require separate forests, messaging system, and prevention of resource access from outside of the forests. At the same time, however, they must conduct joint research projects. These joint research projects involve experts from different organizations working together in virtual teams. To enable these experts to schedule meetings and conference calls with each other, the organization decides to synchronize public folders, which also include free and busy calendar information, to make it viewable outside of the forest boundaries.

For businesses that have separate Exchange organizations, this level of collaboration has the following requirements:

• No resource sharing.

• No authentication of users across forests.

• Address list synchronization as described in Scenario 1.

• Free and busy information synchronization (public folder synchronization).

Synchronizing free and busy information involves synchronizing Exchange public folders across forests. The information that is required for scheduling meetings is stored only in public folders on Exchange servers, and not in Active Directory. The solution for enabling this functionality is to use a public folder synchronization tool to synchronize the contents of the Exchange system public folders between forests.

For more information about synchronizing public folders, see “Synchronizing Exchange Data Across Forests” later in this paper.

Scenario 3: Organizations Share Resources

In this scenario, the organizations need to be able to assign access to resources in one forest to groups of users in another forest. In addition, users need to be able to look up other users throughout the organization by using the global address list, and to view free and busy calendar information to enable them to schedule meetings with people in different forests.

This scenario is commonly used in the following real-life cases:

1. Two organizations merge and their management decides to eventually merge directory or messaging infrastructures, or both. Because merging directory and messaging infrastructures is a time-consuming process, the IT department is tasked with enabling single sign-on capability for resource access outside of a forest and to simulate the experience of single-forest messaging, in which address lists are viewable and free and busy information is available for all users in both forests.

2. Two organizations merge, but unfortunately domain controllers of one organization are located in less secure location(s) than domain controllers of the other organization. The IT department of the less secure organization does not accept the level of physical security of domain controllers in the more secure organization. For this reason, these administrators decide to not merge their directory and messaging infrastructures. At the same time, businesses of these two organizations need close collaboration, which requires single sign-on capability for resource access outside of a forest and the same messaging experience that is available in a single forest.

3. An enterprise has deployed a test selfhost forest where new configurations, operations, and applications are deployed before they are deployed in the main production forest. All employees are equally trusted and need access to various resources in both forests, and therefore users must have access to the same resources, regardless of which forest contains a user’s account. Although deploying a single messaging system is feasible in an environment where employees are equally trusted, this organization chooses to deploy Exchange Server in each forest to completely simulate the main production forest environment. In this way, they can identify any disruptions to messaging before any new configurations, operations, or applications are deployed in the main production forest.

This level of collaboration includes:

• Bridged DNS infrastructures.

• Separate Exchange organizations, but a commonly viewable global address list.

• Free and busy information synchronization between Exchange organizations in separate forests.

• Resource sharing among users across both forests:

  • Controlled sharing or full sharing.

  • Security groups can have members from both forests.

  • Access control lists (ACLs) can list security principals from both forests.

• Single sign-on between forests: User logon experience is the same for access to resources in any forest.

Solutions for this scenario involve configuring DNS to locate servers in the different forests. Enabling resource access requires trust relationships between domains in different forests as well as appropriate groups and permissions for resource sharing. For the forest functional level of Windows Server 2003, forest trust relationships are available that enable bidirectional, transitive trust relationships between all domains in the respective forests. For Windows 2000 forests or Windows Server 2003 forests that have a functional level other than Windows Server 2003, you must manually create explicit trust relationships between specific domains to enable resource sharing.

For more information about bridging DNS, see “Enabling DNS Name Resolution Across Different Forests” later in this paper. For more information about enabling resource sharing and single sign-on between forests, see “Enabling Resource Access Across Forests” later in this paper. For more information about address list synchronization, see “Synchronizing Exchange Data Across Forests” later in this paper.

Scenario 4: Organizations are Completely Integrated and Share a Single Exchange Organization

To reduce the cost of providing a messaging solution, administrators might agree to deploy a single Exchange 2000 organization to serve an entire enterprise, in which case their messaging infrastructure does not need to be synchronized. This solution offers tighter integration because a single Exchange Server organization can span multiple forests without additional configuration.

An example of a tightly integrated multiforest organization is a factory that has assembly lines that must never be stopped because the consequences of stopping the assembly line could be devastating for the organization. Considering the mission-critical role of the assembly line, and because the functionality of the assembly line depends on an Active Directory-integrated application, the IT team deploys a separate assembly-line forest that has no external dependencies. For example, this forest might have no dependency on network connectivity, or perhaps it cannot accept the level of service that is provided for the corporate forest in terms of the time required for the IT department to respond to failures.

Some users have accounts in the assembly-line forest. These users roam throughout the company on a regular basis and they use laptops that are joined to the assembly-line forest. They often need access to file shares on the Distributed File System (DFS) servers in the corporate forest and to use printers that are located in the corporate forest. In addition to the DNS integration and resource sharing that is described in Scenario 3, the following functionalities can also be configured to accommodate the needs of these roaming users:

• Site and subnet synchronization.

• Printer information.

For more information about site and subnet information, see “Synchronizing Sites and Subnets” later in this paper. For more information about making printer information available across forests, see “Locating Printers Across Forests” later in this paper.