Additional Configuration for Functionality Across Forests (Multiple Forest Considerations in Windows 2000 and Windows Server 2003)

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

Although most of the operations performed by users and administrators in a multiforest deployment rely on functionality within their own forests, some operations require additional configuration to extend the underlying functionality across the forest boundaries.

In addition to administrative collaboration that is involved in cooperatively operating multiple forests, the following features require additional configuration to enable collaboration across forests:

• DNS name resolution: Enable DNS name resolution between forests to provide domain controller and resource location functionality.

• Access to resources:

  • Establish trust relationships between user domains and resource domains.

  • Configure the access control lists (ACLs) of resources to allow access to appropriate groups from different forests, and create new groups to accommodate forest roles across forests.

• Synchronization of sites and subnets: Enable each forest to recognize the entire scope of the network. To allow clients in one forest to locate the nearest domain controller in another forest and enable access to DFS file shares with minimum network traffic, configure the same sites and subnets in all forests.

• Storage and retrieval of application data: Provide computers of all forests with the ability to access application data in any forest.

• Printer location: Synchronize printer information.

• Exchange Server integration: Enable address list synchronization and free and busy calendar information.

The topics in this section contain discussion of the essentials of each configuration at a high level but do not provide specific configuration instructions. Microsoft intends to issue a deployment guide with instructions for how to enable the functionality described in this section.

Enabling DNS Name Resolution Across Different Forests

Successful Active Directory deployment requires DNS for name resolution. The ability to resolve an IP address from the DNS name of a computer is necessary for the location of domain controllers and resources by users and computers.

Issue

With multiple forests, name resolution is required to function between forests so that users and computers in one forest can locate resources and domain controllers in the other forest.

Best practices for designing the DNS namespace and providing DNS support for deployment of a single Active Directory forest are provided in the “Best Practice Active Directory Design for Managing Windows Networks.” You can view this document on the Microsoft TechNet Web site at https://go.microsoft.com/fwlink/?LinkId=10478. In the process of designing your multiforest Active Directory deployment, follow these recommendations for each individual forest. After you have completed the DNS design for each individual Active Directory forest, you must analyze the requirements to enable name resolution across the forest boundaries.

The ability to resolve the names from the namespace of a different forest is required by the following activities:

• User or computer needs to locate a resource (for example, an Exchange server, file share, or service) that is hosted on a computer that is joined to a different forest.

• User or computer needs to locate a domain controller in a different forest for the purpose of authenticating to a resource in that forest.

In most scenarios, you will need to ensure name resolution across different forests.

Solution

The need for additional DNS configuration to enable name resolution across forests depends on your current DNS infrastructure and on any DNS design that might be planned for new Active Directory forests. The most common DNS scenarios are described below and relevant configuration requirements are enumerated for each.

If a user in a fictitious organization A (Org A) needs to locate resources in organization B (Org B), or vice versa, different configuration changes apply for each of the following scenarios:

• In Figure 1, Org A has a root DNS server that hosts the root (“.”) zone. In In Figure this scenario, a delegation is set up on the root DNS server that hosts the root zone in Org A. This delegation consists of a host (A) resource record and a name server (NS) resource record for the DNS servers that host the highest-level DNS domain in Org B. The effect of these resource records is that queries originating in Org A for names within the namespace of Org B are referred to the DNS servers in Org B. Figure 1 shows the delegation from Org A to Org B.

  Figure 1   Delegation from DNS server hosting root zone in Org A to enable resolution of names in Org B

• In Figure 2, Org A has no root zone, but DNS servers running a member of the Windows Server 2003 operating systems are configured to forward queries up the namespace, eventually to the Internet. In this scenario, conditional forwarding must be configured on a DNS server in Org A to forward queries ending with a particular suffix (in this case, the suffix of Org B) to DNS servers in Org B. DNS servers in Org A can forward to any level in the namespace of Org B. Figure 2 shows conditional forwarding from Org A to Org B.

  Figure 2   Conditional forwarding from Org A to Org B

  Note

  Conditional forwarding is available only in Windows Server 2003.

• In Figure 3, Org B has no root zone and DNS servers in Org B are running a member of the Windows 2000 Server family. To enable DNS servers in Org B to respond to queries for names within the namespace of Org A, DNS servers hosting high-level zones in the namespace hierarchy can be configured to host secondary zones that contain the highest-level zone data of Org A servers. As shown in Figure 3, the Org B servers that host these secondary zones must perform zone transfers from Org A DNS servers to ensure that the secondary zones for names in Org A are updated.

  Figure 3   Secondary zone for Org A in Org B

Enabling Resource Access Across Forests

Access to resources in different forests requires appropriate trust relationships, user and group management, and access control in the trusting domains. Resource sharing between domains is discussed in “Designing the Active Directory Structure” in the Deployment Planning Guide of the Microsoft®Windows® 2000 Server Resource Kit. The model of resource access and management for multiple Windows Server 2003 forests is very similar, with a few basic differences.

Issue

When users in Forest A need access to resources in Forest B, the resource administrators in Forest B can add the accounts of users in Forest A to the access control list (ACL) on the resource. Assuming that there are a large number of users who need the same access to a resource, it is not feasible to add the individual account of every user to the ACL on every resource that is required by each user. Rather, a more scalable management model is required to allow users in Forest A to access resources in Forest B.

Solution

The model that allows users to access resources across forests is very similar to the model for allowing users in different domains in the same forest to have access to resources across domains. The most efficient management model is as follows:

• Create trust relationships between domains in different forests, as follows:

  • To enable resource sharing between all domains in two Windows Server 2003 forests, create a forest trust between the forest root domains. This trust relationship, which is available in Windows Server 2003 forests, enables two-way transitive trust between all domains in two forests. Forest trust relationships are not transitive beyond the two forests that share the trust.

    Note

    A transitive trust relationship flows throughout a set of domains, such as a domain tree, and forms a relationship between a domain and all domains that trust that domain. For example, if domain A has a transitive trust with domain B, and domain B trusts domain C, then domain A trusts domain C. Transitive trusts can be one-way or two-way, and they are required for Kerberos-based authentication and Active Directory replication.

• To enable resource sharing between specific domains in different forests, create external one-way, non-transitive domain trust relationships (explicit trusts) between the specific domains.

• To represent the sets of users who need access to the same type of resources, create role-based global groups in every domain and forest that contains these users.

  Note

  You might already have such groups created in some forests.

• Create universal groups that correspond to the global groups.

• Add multiple global groups to a universal group so that you can assign permissions to related resources in multiple forests.

  Note

  Universal groups are not available as security groups in Windows 2000 mixed-mode domains or in Windows Server 2003 domains that have a domain functional level of Windows 2000 mixed. They are available for distribution groups. For information about Active Directory functional levels, see Help and Support Center for Windows Server 2003.

• Create resource-based domain local groups in every domain for the resources in that domain that need to be accessed from outside the forest.

• Add universal groups (or global groups in mixed-mode domains) from all such forests to the domain local groups across the organization, and use the domain local groups to assign permissions on the resources within the respective domains.

When a new user account needs access to a resource in a different forest, add the account to the respective global group. When a new resource needs to be shared across forests, add the appropriate domain local group to the ACL for that resource. In this way, access is enabled for resources on the basis of group membership.

Figures 4 and 5 compare and contrast this model in single versus multiple forests and in Windows 2000 versus Windows Server 2003. In Figure 4, Forest A has Windows 2000 domains that are in mixed mode and therefore universal groups are not available. Global groups from Domain A and Domain C are added to the domain local group in Domain B, and that group is added to the ACL on the Domain B resource and permissions are assigned to the group that provide the appropriate level of access. The multiforest deployment follows the same model for three forests as is used for three domains in the single-forest deployment.

The scenarios in Figure 4 apply to domains and forests that do not have universal groups available to them. Domains that do not have the ability to use universal groups can be:

• Windows 2000 domains that have the domain mode of mixed.

• Windows Server 2003 domains that have the domain functional level of Windows 2000 mixed.

In Figure 4, group abbreviations are as follows:

• Global group (GG).

• Domain local group (DLG).

  Figure 4   Resource sharing when universal groups are not available

In Figure 5, multiple global groups are added to a single universal group, which is added to the domain local group. In a single forest, one universal group per role is all that’s required. In multiple forests, a universal group can be created for each forest that has users that need access to a resource in a different forest. This approach is useful when multiple global groups from the same forest need access to the same local resource.

The scenarios in Figure 5 apply to domains in which universal groups are available. Domains that have the ability to use universal groups are:

• Windows 2000 domains that have the domain mode of native.

• Windows Server 2003 domains that have the domain functional level of Windows 2000 native or Windows Server 2003.

In Figure 5, group abbreviations are as follows:

• Global group (GG).

• Domain local group (DLG).

• Universal group (UG)

  Figure 5   Resource sharing when universal groups are available

Adding Groups to Domain Local Groups vs. Computer Local Groups

As a general rule, the practice of adding domain local groups to global groups and adding global groups to universal groups is effective when a large number of users must be granted access to several resources. When the number of users is few, you can add them directly to the universal group or to the resource.

In addition, when you have a choice of adding universal groups or global groups to a domain local group or to a computer local group, use the computer local group instead of the domain local group. The reason to do so is that when an access token is constructed, domain local groups, global groups, and universal groups of which the security principal is a member are included in the token. Thus, entries in the token include nested group memberships, which means that if user A is a member of group G and group G is member of group GR, the access token for user A will contain both group G and group GR. A maximum of 1,500 entries can be added to an access token, and if a user belongs to too many groups, this limit can be reached. However, computer local groups are not nested.

Therefore, if resource access is being enabled on a per-computer basis and the number of computers is not very large, using computer local groups avoids potentially nested memberships of a domain local group and is the better practice.

For example, if you want to allow a user to administer an Exchange server, adding their account or group to the computer local group on the Exchange server is more effective than creating a domain local group, adding that domain local group to the Exchange Admins group or to the ACL on the Exchange server object and setting permissions, and then adding the user’s account or group to the domain local group.

Security Considerations for Resource Access Across Forests

Even when you create multiple forests for data isolation, service isolation, or both, trust relationships with other forests (or individual domains from other forests) can be created and users can be added to groups in other forests so that they can be granted access to resources. However, do not include users from other forests in any of the following groups:

• Groups that are responsible for service management or that can manage the membership of service administrator groups.

• Groups with administrative control over computers that store protected data.

• Groups that have access to protected data, or groups responsible for the management of user or group objects that have access to protected data.

Including users from another forest in any of these groups constitutes a potential security breach of the other forest that can lead to disclosure of protected data or service interruptions.

For information about these administrative groups, see “Design Considerations for Delegation of Administration in Active Directory.” You can view this document on the Microsoft TechNet Web site at https://go.microsoft.com/fwlink/?LinkId=10516.

Synchronizing Sites and Subnets

Site and subnet information represents the physical topology of the network and is not related to the Active Directory structure. Active Directory can determine the location of computers on the network according to the relationship of their respective IP addresses to a range of addresses defined by a subnet object in Active Directory. Subnets are associated with sites, and sites identify areas of good network connectivity. Sites are usually connected by Wide Area Network (WAN) links. For this reason, an ideal connection is one that does not cross site boundaries (traffic does not traverse a WAN link). Site and subnet information enables computers that are running Windows 2000, Microsoft® Windows® XP, or a member of the Windows Server 2003 operating systems to locate the following computers and services in the same site or a nearby site:

• Domain controller, global catalog server, or Key Distribution Center (KDC).

• Distributed File System (DFS) server that hosts a requested resource.

Issue

When site and subnet information in both forests is identical, or the Netlogon optimization is leveraged, computer and service location is optimized according to site (see article 916474 (https://go.microsoft.com/fwlink/?LinkId=166344) in the Microsoft Knowledge Base). The ability to locate computers and services in the same site or a nearby site depends in part on whether the appropriate site and subnet information is available in Active Directory.

It is important to note that establishing synchronization of site and subnet information is not an immediate requirement of implementing multiple forests. You can establish site and subnet synchronization at any point throughout the lifetime of a multiforest deployment, or you can decide to not establish it. If you decide to establish synchronization of site and subnet information, the question of how soon to establish it depends on the impact of not having an identical site topology between forests or not having Netlogon optimized.

For example, suppose an organization has Forest A and Forest B, and site and subnet information is not synchronized between them. The following scenarios describe the effects on the performance of three common operations that are affected by site awareness:

• Logon process

• File downloads

• Authentication

Use these scenarios to help determine whether the reduction in network traffic or request execution time, or both, outweigh the additional effort that is required to synchronize site and subnet information across the forests.

Logon Process Across Forests

When a user from Forest A logs on to a computer in Forest B, the logon process requires location of a domain controller from the user’s domain in Forest A. If the site of the computer from Forest B is not specified in Active Directory in Forest A, the computer might locate any (rather than the closest) domain controller from the user’s domain in Forest A. If the connection to the domain controller is made over a WAN, then this logon process adds traffic to the WAN (the amount of traffic depends on the number of Group Policies and logon scripts, as well as the size of the roaming profile). This connection generates traffic during logon as well as logoff and usually ranges from 100 kilobytes (KB) to a few hundred KB. Depending on the WAN bandwidth that is available for logon traffic, logon duration over the WAN might be increased. If these drawbacks are acceptable, especially if you anticipate that most users will be logging on to computers in their own forest, then site and subnet information might not be important enough to warrant synchronizing the data between forests.

File Download Across Forests

When a user who is logged on to a computer that is joined to Forest B requests a file that is hosted by multiple DFS servers, the nearest one being a server that is joined to Forest A, the DFS server that is contacted for the download depends on whether site and subnet information for Forest A is available in Forest B. If the site of this DFS server is not specified in Forest B, then the file might be downloaded from an arbitrary (potentially remote) DFS server. If the site of the DFS server is available in Forest B, the server in Forest A can be located.

Note

DFS enhancements in Windows Server 2003 ensure that files are downloaded from the next closest DFS server that hosts the desired file and is joined to Forest B.

Downloading a file from a remote DFS server increases network traffic over a WAN (the amount of traffic is determined by the size of the file to be downloaded) and potentially increases the download time (the delay depends on bandwidth available to download the file). If these drawbacks are acceptable, especially if you anticipate that users download files only from the DFS servers in their own forest, then synchronizing site and subnet information might not be important.

Authentication Across Forests

When a user needs to authenticate to a resource in a different forest, the user’s computer or domain controller (depending on the authentication mechanism that is used) must contact a domain controller in the domain of the resource. Domain controller location is optimized by the closest site across forests only when identical site and subnet information is configured in Active Directory in both forests. However, if the traffic that is generated by authentication of the user does not cause significant delay, then it is not critical that a local domain controller be contacted.

Solution

The initial solution for mirroring site and subnet information is to create the same site and subnet objects in all forests. After these objects have been created, two methods can be used to ensure that site and subnet information is maintained identically in both forests:

• Use a directory data synchronization product (for example, Microsoft Identity Integration Server 2003) to synchronize the data when site and subnet information changes in one forest. This approach is characterized by a high level of automation and requires practically no administrator involvement after Microsoft Identity Integration Server 2003 configuration is in place. However, this approach is not acceptable in scenarios where service isolation is required (the service administrators in the destination forest do not trust the service administrators from the source forest).

• Establish a business process by which network administrators inform service administrators in each forest when site and subnet information changes, and the service administrators then update the information in their respective forests. This approach is most appropriate for the customers who have service isolation requirements for separate forests. However, this approach requires a high level of administrator overhead to create mirrored information in multiple forests.

Microsoft intends to issue a deployment guide that will describe the site and subnet objects and attributes that need to be synchronized to mirror network topology information.

Retrieving Application Data Across Forests

A rapidly growing family of applications is using Active Directory to store and retrieve application-specific data. Application architecture assumes that application-specific data is stored in a well-known (for service providers and consumers) Active Directory location that is populated by the service providers or administrators.

Issue

When clients of the service or application data need to obtain the data or locate the service, they perform a search against Active Directory and retrieve the data. Most clients assume that they are joined to the same forest as the service provider. In multiple forest deployments, this condition is not always true.

For example, service providers for service App1 are running on computers that are joined to Forest A and they register the information that enables clients to locate these service providers only in Forest A. In this case, if a client in Forest B queries Active Directory to discover a service provider for service App1, the query fails and the client cannot locate a service provider.

Clients do not always use the data stored in Active Directory to locate service providers. Sometimes a client or other service provider needs to retrieve data from Active Directory but does not need to locate any other service provider. The following solutions apply to both scenarios.

Solution

Two approaches can be used to give clients the ability to find information in Active Directory in a different forest:

• Deploy service providers in each forest.

• Synchronize the data across the forests.

Making a choice between the two approaches depends on the following requirements of the application:

• Load sharing.

• Discovery of the nearest service provider.

• Autonomy or isolation, or both (for security purposes).

Deploy Additional Service Providers

The following scenario describes a condition that requires deploying additional service providers on the basis of different application requirements.

Load requirements

If service providers that are deployed in one forest cannot sustain the load of requests from clients from multiple forests, then deploying additional service providers might be necessary. Deploying them in all individual forests eliminates a need to synchronize this application-specific data across the forests.

Synchronize Data Across Forests

The following scenario describes a condition that requires synchronizing data across multiple forests on the basis of different application requirements.

Nearest service provider

For some network-traffic-intensive or response-time-sensitive applications, it is important to ensure that a client locates the nearest service provider. In this case, deploying one or a few service providers to serve an entire network that spans multiple sites might not be appropriate. You might need to deploy at least one service provider per forest per site, but if multiple forests span the overlapping set of sites, then duplicating service providers for each forest might unnecessarily increase the cost of hardware and support of the service providers. In this case, synchronizing the application-specific data across different forests allows clients from one forest to locate the nearest service providers, even though the clients belong to a different forest. For an example of the service providers that can be used by all clients in the same site regardless of their forest affiliation, see “Locating Printers Across Forests” later in this paper.

No Sharing of Application Data Across Forests

In the following cases, providing application data across forests is not feasible.

Autonomy or isolation

For some applications, in addition to availability of the service and proximity of the service providers, some administrators might have additional requirements of autonomy. If, for example, an application or service owner in one division (that also has its own forest) requires special configuration of the service provider (not matching the configuration in other parts of organization), then users in this forest might not use the service providers in other forests and must rely on only the service providers in the same forest. In this case, there is no reason to synchronize the application-specific data between the forests.

In addition to autonomy or isolation requirements, the owner of a service might also have security reasons for requiring that users and computers use only the service providers from their own forest. Remember that service administrators in a different forest have full control over the services and data stored on the computers joined to their forest. If you cannot allow delivery of your service to depend on another forest (for example, if the other forest is compromised), then you must not synchronize the service-specific data to your forest.

Considerations for Using Microsoft Identity Integration Server 2003 to Synchronize Application-Specific Data Between Forests

If you decide to synchronize some application-specific data between forests, the recommended synchronization solution is Microsoft Identity Integration Server 2003. The solution involves the following administrative cooperation:

• The Microsoft Identity Integration Server 2003 administrator configures Microsoft Identity Integration Server 2003 to perform synchronization of the application-specific data.

• The application owner provides the Microsoft Identity Integration Server 2003 administrator with the description of the objects and attributes that need to be synchronized between the forests.

• The forest administrators indicate to Microsoft Identity Integration Server 2003 administrators the directory locations that the information should be read from and written to.

In collaboration with application administrators, administrators of the individual forests must decide relative to each application if they want to participate in data synchronization. This decision should be based on a need to share application-specific data with other forests, to use application-specific data from other forests, and on security requirements.

Credentials for Writing Application Data

When a forest administrator decides to allow Microsoft Identity Integration Server 2003 to write application-specific data for a specific application, the administrator must decide which credentials Microsoft Identity Integration Server 2003 should use to write this data. The recommended method is to create a user account that uses its credentials exclusively to allow Microsoft Identity Integration Server 2003 to write this data. The administrator does not have to create separate credentials for each application and might use the same set of credentials for data that is used by different applications.

Security Considerations for Writing Application Data

A forest administrator must also add appropriate write permissions to the container into which Microsoft Identity Integration Server 2003 will write the data. Depending on security requirements, the destination forest administrator might need to ensure that these credentials do not enable one to overwrite data from a different forest.

Even if you trust the Microsoft Identity Integration Server 2003 administrator to appropriately configure the synchronization server and you completely eliminate the possibility that the Microsoft Identity Integration Server 2003 administrator could be rogue, the possibility of the administrator being coerced still exists. To minimize the risk that a Microsoft Identity Integration Server 2003 administrator could jeopardize the functionality of an entire individual forest, the forest administrator, in addition to creating a dedicated organizational unit in which synchronized objects are created, should ensure that write permission granted to Microsoft Identity Integration Server 2003 to create, update, and delete data is limited to only this organizational unit, and no other portion of the forest.

Restricting access to a single organizational unit eliminates the possibility that Microsoft Identity Integration Server 2003 can overwrite any data outside of the organizational unit. If this approach is taken, the forest administrator must inform the Microsoft Identity Integration Server 2003 administrator of the location of this organizational unit in the forest hierarchy and ensure that any requirements of the application to read and write to various objects on the directory are fulfilled. For example, some applications expect the data to be in specific locations of the Active Directory hierarchy, and only in those locations.

Note

If you are using Microsoft Metadirectory Services version 2.2, Microsoft recommends that you hire a Microsoft Consulting Services (MCS) consultant who specializes in Microsoft Metadirectory Services 2.2 to configure Microsoft Metadirectory Services 2.2 to enable data synchronization.

Locating Printers Across Forests

The presence of printer objects in Active Directory enables a computer that has an account in that forest to browse for printers that have specific characteristics (for example, printers that support color printing or stapling) and that are located near the computer.

Issue

In the multiforest scenario, a user might be logged on to a computer that is in the same physical location as a printer, but the computer account and printer information exist in different forests. In this case, the user can locate a printer in a different forest only by providing the print server and printer name. You might want to allow users to browse for printers on the basis of their proximity and without regard to forest membership.

Solution

It is possible for a user to configure a computer to use a particular printer by specifying the printer name, which requires no additional configuration on the part of the forest administrator. However, if you want to enable users in one forest to browse for printers in a different forest, then consider using Microsoft Identity Integration Server 2003 to synchronize printer data between the forests, as described in “Retrieving Application Data Across Forests” earlier in this document.

Microsoft intends to issue a deployment guide with instructions for how to enable this functionality.

Synchronizing Exchange Data Across Forests

Exchange 2000 Server uses Active Directory to store configuration and user information and to provide user authentication and permissions management. In multiforest deployments where more than one Exchange organization is deployed, additional configuration is required to synchronize mail-related data of multiple Exchange organizations among the multiple forests.

Exchange Organizations and Active Directory

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.

However, multiple forests can use the same Exchange organization for mail service. A single Exchange organization that serves multiple forests does not require additional configuration across forests because the Exchange organization uses only one forest for its Active Directory storage and services.

Although user accounts in different forests can use the same Exchange organization to send and receive mail among users in all forests, the servers of a single Exchange organization cannot access information from more than one Active Directory. To enable multiple forests that each deploy separate Exchange organizations to function as a single business organization, additional configuration is required to synchronize the Exchange mail recipients in the respective Active Directories.

The ability to access address information from different forests requires that shadow (or proxy) versions of all mail recipients be created and maintained by synchronization in each relevant directory. With these shadow objects in place, when an Exchange server queries a single directory, it can view information about mail recipients that originate in its forest as well as those that have been created as shadow objects.

Single Exchange Organization

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. 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.

For example, in a scenario where Forest A and Forest B share a single Exchange organization, Exchange servers are installed only in Forest B. User A has a user account in Forest A and User A’s mailbox is stored in forest B. To associate the user in Forest A with the user’s mailbox in Forest B, a disabled user account is created for User A in Forest B and the mailbox is associated with it. User A’s mail is stored on Exchange servers in Forest B and an attribute on the disabled account references User A’s account in Forest A. This type of Exchange environment is known as the resource forest model.

Figure 6 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 objects in Forest A have corresponding disabled user accounts that represent their respective Exchange mailboxes in Forest B, which hosts the Exchange servers.

Figure 6   Single Exchange organization with users and mailboxes in different forests

Single Exchange organizations can have users in more than one forest, as shown in Figure 7.

Figure 7   Single Exchange organization that serves multiple forests

Multiple Exchange Organizations

When the same enterprise deploys Exchange servers in multiple forests, each Exchange organization has a separate Exchange forest and therefore a separate global catalog and global address list. Additional configuration is required to enable users in each forest to be able to look up address list information in the other forests. To achieve this goal, mail recipient information from multiple Exchange organizations must be synchronized.

Figure 8 shows a multiforest enterprise that deploys Exchange servers in multiple forests.

Figure 8   Multiple Exchange organizations and multiple forests

Note

It is not a goal of this document to prescribe best practices to design Active Directory for Exchange 2000 Server. For more information about designing Active Directory for Exchange 2000 Server in a Windows 2000 Server environment, see “Best Practice Active Directory Design for Exchange 2000.” You can download this document from the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkId=10517.

For deployments in which multiple Exchange organizations serve separate forests in the same multiforest enterprise, additional configuration might be needed in order to enable:

• Viewing the global address list in all forests.

• Viewing free and busy calendar information in all forests.

The configuration information in this paper encompasses all scenarios in which Exchange Server is deployed in more than one forest, but not necessarily in every forest in the enterprise.

Address List Synchronization

In a multiforest environment with a single Exchange organization, all user accounts reference global catalog servers in the Exchange forest to gain access to the global address list. Although the users are in different forests, Exchange uses a single global address list for these users and therefore no synchronization of address list information is needed.

In a multiforest environment with multiple Exchange organizations, each Exchange forest has its own address list and therefore synchronization is required to present the same view of address list data across the forests.

The global address list is a list of entities in a forest that can receive mail. Mail recipients can be user accounts (both enabled and disabled accounts), contacts, distribution lists, security groups, and folders. Exchange administrators can also create different views of the global list of mail recipient information to generate logical groupings of recipients, which are viewable as address lists.

Every Outlook client is configured with the name of an Exchange server. When an Outlook client user opens the Address Book, or when a user composes a message and types a name or an address in the To: field, the Outlook client uses the global catalog server that is specified by its Exchange server to search the contents of the global address list or other address lists.

Issue

Outlook clients must use global catalog servers and Exchange servers in only one forest to look up addresses. For this reason, the clients in one forest can view address lists of another forest in the same Exchange organization, but not of a forest in a different Exchange organization. Therefore, the following issues must be addressed in a multiforest deployment that has multiple Exchange organizations:

• Users in one forest need to be able to look up Address Book data, including mail addresses of objects in a different forest.

• The Exchange client must be able to resolve all addresses in its own forest.

Figure 9 shows two Active Directory forests with Exchange servers in each forest and an example of a mail-enabled user in each forest. The global address list (GAL) of each respective forest does not contain users from the other forest. For this reason, a query by an Exchange client does not find address lists for the other forest.

Figure 9   Two forests with separate Exchange global address lists (GALs)

In the configuration that is shown in Figure 9, separate Exchange organizations are deployed in two forests. In this case, before any additional configuration occurs, Forest A does not contain an account for Fred, who resides in Forest B. Likewise, Forest B does not contain an account for John, who resides in Forest A. Therefore, when the user of the Outlook client that is referencing the Exchange server that is configured to use the global address list in Forest A opens the Address Book, Fred is not found in the Address Book. John also cannot send mail to Fred by using an alias, but must use the full Simple Mail Transfer Protocol (SMTP) address for Fred.

The same restriction applies to the distribution lists and resources (for example, conference rooms) that reside in different forests. For example, if a distribution list exists in Forest A, then without this additional configuration, a user whose Outlook client is retrieving global address list information from the global catalog in Forest B does not see this distribution list in the Forest B Address Book.

Solution

To allow users to see mail recipients from another forest in the Address Book, the mail recipients must be synchronized between forests. In this scenario, the mail recipients are synchronized in both directions.

Synchronizing users and groups between forests

The solution that enables users in different forests to see the identities of each other in the Address Book is to create a proxy, or “shadow,” version of mail-enabled objects in the forests that have Exchange 2000 Server deployed. The shadow version is represented by a contact object. In Figure 10, the mail account of John in Forest A is represented by the contact object John in Forest B, while the mail account of Fred in Forest B is represented by the contact object Fred in Forest A. Synchronization is performed by a directory data synchronization product such as Microsoft Identity Integration Server 2003.

Figure 10   Mailbox synchronization between two forests

In this example, if administrators of both forests want to allow users from Forest B to view the users from Forest A in the Address Book, then administrators can configure a directory synchronization server, such as Microsoft Identity Integration Server 2003, to perform the following operations:

• Search Forest A for all mail-enabled objects.

• Create corresponding contact objects in Forest B.

These operations can be scheduled to run periodically to dynamically update information in all forests when a mail-enabled object is added, deleted, or modified in its source forest. Upon completion of these operations, Exchange services (running every minute by default) in all forests that have an Exchange server installed will appropriately update existing address lists, including the global address list. Thereafter, when the user Fred in Forest B attempts to find the user John from Forest A by searching the Address Book, Fred successfully finds John because John is represented by a contact object in Forest B.

In addition, because routing information is included in the contact object, a user in Forest B can successfully send messages to John by specifying John’s alias. The Exchange server locates the full SMTP address for the alias for the user John in the John contact object and properly forwards the message to the Exchange Server service that contains the mailbox of the user John.

Depending on the decision of the administrators of the source forest (the forest from which data is read) and the destination forest (the forest in which data is updated to match the appropriate data in the source forest), and assuming proper configuration, Microsoft Identity Integration Server 2003 can perform synchronization in one or both directions.

The process is very similar for contact objects that are synchronized out of this forest as well as mail-enabled security and distribution groups. As shown in Table 1, all of these object types are synchronized as contacts into other forests.

Table 1

Source Directory	Target Directory
User	Contact
Contact	Contact
Group	Contact

Additional scenarios for address synchronization in forests without Exchange

The scenarios described earlier apply to multiple forests that deploy separate Exchange organizations. Under the following conditions, address list synchronization might be deployed in forests that do not deploy Exchange servers:

• The attributes on the mailbox-enabled user account need to be propagated back to the forest with the logon user account. For example, if a human resources database typically updates phone numbers on the user account in the Exchange forest and other applications look up this information in the user account forest, then synchronization is required.

• Applications other than Outlook use the Address Book.

Cost of global address list synchronization

The cost of synchronizing the global address list and other address lists is that of implementing a directory data synchronization product such as Microsoft Identity Integration Server 2003. A single Microsoft Identity Integration Server 2003 server is required for every synchronization infrastructure that you want to implement. For example, if you decide to use a centralized Microsoft Identity Integration Server 2003 administrator who manages global address list synchronization for all of the forests, then the cost is that of running Microsoft Identity Integration Server 2003 on a single server computer plus a Microsoft Identity Integration Server 2003 administrator who will manage the process. However, if the forest administrators do not trust each other and want to run their own solutions, then each forest must have a Microsoft Identity Integration Server 2003 server with a Microsoft Identity Integration Server 2003 administrator who manages getting data into the forest.

Which synchronization solution to use

Any solution that enables synchronization of the objects described above can be used to synchronize address lists across multiple Exchange organizations. However, Microsoft highly recommends using Microsoft Identity Integration Server 2003. Microsoft Identity Integration Server 2003 is capable of synchronizing directory data between multiple Active Directory forests according to the business rules that are specified in the Microsoft Identity Integration Server 2003 configuration.

If you are using Microsoft Metadirectory Services (MMS) version 2.2, it is recommended that you hire a Microsoft consultant to perform the necessary configuration of MMS 2.2 to enable global address list synchronization.

Concurrent with shipping Microsoft Identity Integration Server 2003, Microsoft intends to provide a Global Address List (GAL) Synchronization Solution that automates the configuration of Microsoft Identity Integration Server 2003. The GAL Synchronization Solution significantly simplifies the configuration of Microsoft Identity Integration Server 2003 to perform global address list synchronization, including the creation of contact objects and distribution groups. The GAL Synchronization Solution performs configuration of that is expected to satisfy business rules of the majority of customers. At the same time, customers have the flexibility to modify Microsoft Identity Integration Server 2003 configuration on the basis of their individual business rules regarding global address list synchronization data. Detailed information about the GAL Synchronization Solution is to be included in the Multiforest Deployment Guide, which Microsoft intends to issue in the future.

Administrative considerations for global address list synchronization

To enable synchronization of global address list data by Microsoft Identity Integration Server 2003, administrators of the source and destination forests must provide information to the Microsoft Identity Integration Server 2003 administrators, as follows:

• The source forest administrator creates a user account that has read permission on the object that is to be synchronized. Credentials for this account will be used by Microsoft Identity Integration Server 2003 to read the objects from the source forest. The source forest administrator also specifies whether to allow group membership expansion.

• The destination forest administrator creates or identifies an organizational unit in which Microsoft Identity Integration Server 2003 will create the new contact objects. The administrator also creates a user account and grants permissions on the organizational unit to allow the account to create, delete, and update (write) objects in the organizational unit. To eliminate the possibility of tampering with destination and forest data outside of the organizational unit, allow write permissions only in the organizational unit that the administrator created for the purpose of creating synchronized objects, and to specific attributes of accounts outside the organizational unit that are needed to preserve mail functionality.

Note

If the forest administrator decides to synchronize data both into and out of the forest, then the administrator should use the same user account credentials to perform both read and write operations.

Risk models for global address list synchronization

There are two main risk models that apply to enabling global address list synchronization. The two models can coexist within the same organization. These risks apply in a more general context to all synchronization solutions.

• Individual forest administrators trust centralized Microsoft Identity Integration Server 2003 administrators to synchronize data between the forests. They are willing to risk the possibility that a centralized Microsoft Identity Integration Server 2003 administrator might maliciously or accidentally misconfigure Microsoft Identity Integration Server 2003. As a rule, individual forest administrators can and should protect their forest from data disclosure or tampering by ensuring that the user whose credentials are used by Microsoft Identity Integration Server 2003 to perform synchronization does not have permissions that would allow malicious activities. This approach is recommended.

• Individual forest administrators are not willing to risk the possibility that a centralized Microsoft Identity Integration Server 2003 administrator might maliciously or accidentally misconfigure Microsoft Identity Integration Server 2003. In this scenario, each individual forest administrator might deploy a Microsoft Identity Integration Server 2003 server that performs data synchronization from or into their forests, or both. The only cooperation required in this scenario is that the partner forest administrator must provide sufficient credentials to allow reading and writing the appropriate data. This approach is slightly more complex and might have a higher overhead, depending on the number of forests involved.

Free and Busy Calendar Information Synchronization

Calendar information enables users to schedule meetings by viewing the free and busy times in the schedules of meeting invitees. If frequent meetings are to be scheduled between members of different forests, the availability of schedule information might warrant synchronizing free and busy calendar data between Exchange organizations in different forests.

Issue

John has a mailbox in Forest A and wants to use Outlook to schedule a meeting with Fred, whose mailbox is in Forest B. John also wants to invite a group of people from Forest C. As shown in Figure 11, if John does not see the availability of users and groups in other forests, scheduling a meeting requires contacting them personally.

Figure 11   Scheduling when calendar data is unavailable

Free and busy calendar information is stored in the system public folders on Exchange 2000 servers, but not in Active Directory. For this reason, synchronizing global address list information between different forests is not sufficient to enable users that have mailboxes in one forest to view free and busy calendar information of users and resources that have mailboxes in Exchange organizations in other forests.

Solution

To enable users that have mailboxes in Forest A to view schedule information of users and resources that have mailboxes in the Exchange organizations in Forest B and Forest C, the system public folders data stored on the Exchange servers in Forest B and Forest C must be included in the system public folders of the Exchange servers in Forest A. To enable such synchronization, Microsoft recommends using the Microsoft Exchange Interorg Replication Utility (also called the Public Folder [PF] Sync Tool). For information about using this tool, see article Q238573, "Installing and Configuring InterOrg Replication Utility," in the Microsoft Knowledge Base. To find this article, see the Microsoft Knowledge Base link on the Web Resources page at https://go.microsoft.com/fwlink/?LinkId=291.

In most multiforest environments, a single synchronization server can accommodate multiple forests. Figure 12 shows a multiforest deployment that uses a single server that runs the PF Sync Tool to synchronize free and busy information among all three forests. In this scenario, each forest synchronizes data to and from two other forests.

Figure 12   Free and busy information synchronized across three forests by one server

Migration Considerations

In the environment that contains multiple Active Directory forests and potentially multiple Exchange organizations in different Active Directory forests, reorganizations or individual employee relocations will almost inevitably require you to migrate one or more of these: user accounts, computer accounts, groups, or mailboxes.

User Migration

User migration includes user accounts, groups, and computer accounts. To perform user account migration between forests, use Active Directory Migration Tool (ADMT). For information about using ADMT and to download ADMT, see “Active Directory Migration Tool Overview” in the Active Directory link on the Web Resources page at https://go.microsoft.com/fwlink/?LinkId=291.

Mailbox Migration

To perform migration of mailboxes between different Exchange organizations in different forests, use the Exchange Server Migration Wizard. For information about how to perform user mailbox account migration, see the Exchange online documentation.

If you need to migrate both user mailboxes and user accounts, perform the migration of the user account prior to migrating the user’s mailbox.

Considerations for Other Technologies

Group Policy and Message Queuing features are not directly transferable across multiple Windows forests. Some workarounds are available, as described in “Group Policy” and “Message Queuing” later in this paper.

In addition, if you use trust relationships between domains in different forests or between two Windows Server 2003 forests, consideration for whether you want the ability to use user principal names (UPNs) to log on across forests can affect your decisions about the UPN suffixes you choose and the type of UPNs you create, as described in “Using the User Principal Name to Log On Across Forests” later in this paper.

Group Policy

Group Policy provides administrative control over users and computers. Group Policy can be applied to a domain, organizational unit, or site within the same forest. It is not possible to apply the same Group Policy object to users and computers in multiple forests.

If necessary, administrators of the forests can apply identical Group Policy objects to the domains, organizational units, or sites in different forests. For example, if you are managing merged organizations and have applied identical Group Policy objects to affect the users and computers in each domain in the original forest, you might want to apply identical Group Policy objects to all users and computers in each domain in the other (merged) forest.

Another scenario in which Group Policy management across forests is important is in the test-to-production scenario. For example, for staging purposes, many customers maintain a separate test forest that closely resembles the production forest. After the policy deployment has been tested in the test environment, they want to reproduce this deployment in the production forest.

The Group Policy Management Console (GPMC) enables you to manage Group Policy across multiple forests by importing and copying Group Policy objects across forests. The GPMC will be available on the Microsoft Web site shortly after the release of Windows Server 2003. Although Group Policy Management can run only on the computers running Windows XP Professional and Windows Server 2003 operating systems, it can remotely manage Group Policy objects on domain controllers that are running a member of the Windows 2000 Server family with Service Pack 2 or greater.

Message Queuing

If you plan to deploy an application that uses Message Queuing (also known as MSMQ) and runs across the boundaries of multiple Active Directory forests, the application developer should the follow these recommendations:

• Use the direct format name for the target queues so that:

  • Message Queuing does not use Active Directory to resolve the target name.

  • The user cannot use Message Queuing built-in authentication and encryption features.

• If the application will run on a Windows XP or Windows Server 2003 platform, then use Message Queuing over HTTPS with client authentication.

For more information about Message Queuing, see Windows 2000 Server Help or Help and Support Center for Windows Server 2003.

Using the User Principal Name to Log On Across Forests

A user principal name (UPN) is a variation of a user account name that looks like an e-mail name but can be used to log on to a domain. The syntax is <user name>@<string>. UPNs allow you to use the same logon name across different domains in the same forest or in different forests.

UPNs are of two types:

• Implicit: Always of the form userID@DNSDomainName. For example, johns@corp.contoso.com is the UPN for the account of John Smith, whose user ID is johns and whose account is a member of the corp.contoso.com forest. The implicit UPN is always associated with the user’s account, regardless of whether an explicit UPN is defined.

• Explicit: Always of the form string@Anystring, where both “string” and “Anystring” are explicitly defined by the administrator. For example, John Smith might have the UPN ITJS@coneast. Explicit UPNs are useful for situations in which the organization does not want to publicize the name of domains or the forest structure.

A UPN suffix is a string that indicates the namespace from which a UPN is derived. A UPN suffix includes everything to the right of the rightmost “at” (@) symbol in the full UPN. Everything to the left of the rightmost @ symbol is considered part of the user name, even if it contains another @ symbol. UPN suffixes can be either flat or hierarchical in structure, although they are typically used to identify flat namespaces.

UPNs are used primarily for interactive logons across domains. With multiple forests, UPN logons are available across forests under some conditions and not others. Under either of the following conditions, UPNs cannot be used to log on to a domain in a different forest:

• Shared UPN suffix: If two or more forests use the same UPN suffix, users cannot use UPNs to log on to a domain in the trusting forest. They can use the UPN only for logons within their own forest.

• Explicit UPN and external trust: When external trust relationships are created between domains in different forests, users in the respective domains cannot use explicitly created UPNs to log on to the trusting domains in the other forest. They can use only implicit UPNs.

Table 2 summarizes a user’s ability to use a UPN to log on interactively across forests according to the different kinds of trust relationships that exist between domains in different forests and whether UPN suffixes are shared by multiple forests.

Table 2   Ability to Use UPNs to Log On Across Forests

Trust Type	Explicit UPNs	Implicit UPNs	Shared UPN Suffixes
No trust relationships between domains in different forests	No	No	N/A
External trust relationship between domains in different forests	No	Yes	No
Forest trust relationship between Windows Server 2003 forests	Yes	Yes	No

Note

Forest trust relationships are available between forests that have an Active Directory forest functional level of Windows Server 2003. For information about Active Directory functional levels, see Help and Support Center for Windows Server 2003.

In summary, if you want to share UPN suffixes among multiple forests but do not need the ability to log on interactively to a domain in another forest, you can use either external trust relationships or forest trust relationships.

To use UPNs to log on interactively across forests, use unique UPN suffixes for each forest. In this case, interactive logons are available as follows:

• If you use forest trust, you can use both explicit and implicit UPNs.

• If you use external domain trusts, you can use only implicit UPNs.

Features that are Unavailable Across Forests

Although experience with multiforest deployments shows that the features that cannot be enabled across different forests are not used by most customers in any case, the description of these features is included in this document to ensure a complete picture of the impact of deploying multiple forests.

Delegating Mail Folders Across Forests

Within a forest, you can delegate authority for a user to have access to the mail folders in another user’s mailbox.

Issue

If mailboxes of two users are hosted by Exchange Server organizations in different forests, then a user in one forest cannot access the mail folders of a user in the other forest.

A typical example of this issue is executives who want to delegate the ability to manage their calendars to administrative assistants. If the mailboxes of such an executive and administrative assistant exist in Exchange Server organizations that are in different Active Directory forests, then such administrative delegation of this ability is not possible.

Workaround

Ensure that mailboxes of people who need access to the mail folders of others are in the same Exchange Server organization. Also, if a user needs access to mailboxes that are hosted by different Exchange Server organizations, you can create multiple mailboxes in the appropriate forests for the same user who needs access to other mailboxes. For example, in the case of the executives and administrative assistants described earlier, the administrative assistant requires an additional mailbox in the forest of the executive.