Planning to Deploy Exchange in a Multiple Forest Environment

Planning Your Active Directory and Administrative Model discusses the following scenarios for deploying Exchange in a multiple forest environment:

• Dedicated Exchange forest (resource forest)

• Multiple forests running Exchange (classic multiple forest)

• Mergers and acquisitions

This topic focuses on configuration requirements for enabling messaging features in a classic multiple forest scenario. However, depending on your requirements, you can apply some or all of this information to the resource forest and mergers and acquisitions scenarios.

Available Features in a Multiple Forest Environment

Most mail features were initially designed to function only in a single forest. Therefore, to ensure that these features are available across forests, you must overcome many design constraints. Some of the more advanced features, such as delegating mailbox access and viewing calendars, are not available if users are in different forests.

Features in a multiple forest environment

Planning a Multiple Forest Deployment

When installing Exchange in a multiple forest environment, your minimum requirement is to provide basic mail functionality by enabling mail flow and creating a common GAL. Depending on your requirements, you must also set up extended mail features, such as free and busy data and public folder synchronization.

With some additional deployment steps, you can configure your environment to provide as many messaging features as possible across the forests. After you have installed or upgraded Exchange in all of the forests, you can finish your deployment with the following steps:

1. To allow users to search a common GAL in order to send mail, use the GAL Synchronization feature in MIIS 2003.

2. Configure mail flow between the forests. Network connectivity is the only absolute requirement for mail flow between forests. No trusts are required, but you must set up SMTP connectors between the forests. It is also strongly recommended that you enable authentication between the forests—this provides functionality such as resolving users' e-mail addresses to their GAL display names.

3. Configure extended mail features (for example, shared SMTP namespace and global settings).

4. Configure the Inter-Organization Replication tool to synchronize free and busy data and replicate public folders. If users in different forests schedule meetings with one another, you must synchronize free and busy data across forests. Likewise, if you share public folders across forests, you must set up replicas in each forest.

5. Move mailboxes and accounts between forests as necessary.

The first two steps are required for basic messaging. A synchronized global GAL must be available to all forests, and a transport route must be in place to allow mail to flow between them. Depending on your requirements, the remaining steps are extended mail features that you may need to implement.

The following sections provide an overview of how to deploy these features.

Using GAL Synchronization in MIIS 2003

By default, a global address list (GAL) contains mail recipients from a single forest. If you have a multiple forest environment, you can use the GAL Synchronization feature in MIIS 2003 to ensure that the GAL in any given forest contains mail recipients from other forests. This feature creates mail-enabled contacts that represent recipients from other forests, thereby allowing users to view them in the GAL and send mail. For example, users in Forest A appear as contacts in Forest B and vice versa. Users in the target forest can then select the contact object that represents a recipient in another forest to send mail.

If each forest contains at least one Exchange 2003 server, you can use MIIS 2003 to synchronize forests that are running any combination of Exchange 5.5, Exchange 2000, and Exchange 2003. (GAL Synchronization does not work for pure Exchange 5.5 forests.) MIIS 2003 synchronizes the GALs, even if the source or target forest is in mixed mode and is running ADC. In the source forest, ADC synchronizes Exchange 5.5 objects with Active Directory. MIIS 2003 then uses the objects in Active Directory to create the metadirectory objects that it synchronizes with other forests. In the target forest, ADC replicates the contacts into the Exchange 5.5 directory.

If you are running ADC, some additional configuration is required; specifically, to ensure that users and contacts can synchronize between forests, you must configure ADC and MIIS 2003 GAL Synchronization to use a common organizational unit.

To enable GAL Synchronization, you create management agents that import mail-enabled users, contacts, and groups from designated Active Directory services into a centralized metadirectory. In the metadirectory, mail-enabled objects are represented as contacts. Groups are represented as contacts without any associated membership. The management agents then export these contacts to an organizational unit in the specified target forest.

The source forest is authoritative over the mail-enabled objects it supplies to MIIS 2003. If you make changes to the attributes of an object in a target forest, the changes do not propagate back to the source forest.

Consider the following when setting up GAL Synchronization:

• A separate management agent is required for each forest participating in the synchronization.

• To ensure that management agents can export contacts to target forests, the server running MIIS 2003 must be able to connect to a domain controller in each of the participating forests. Management agents can manage multiple domains, but they must access domain controllers instead of global catalog servers, because global catalog servers do not have writable copies of all of the naming contexts.

• When setting up a management agent, you must specify an account with the appropriate permissions.

• If one of the forests contains a connector to a foreign messaging system, by default, that forest is authoritative for the contacts; however, this setting can be changed. For more information, see "Configuring Mail Flow Between Forests" later in this topic.

• Users cannot send encrypted mail from one forest to a distribution list in another forest. In cases where forests are connected by an SMTP connector and synchronized with GAL Synchronization, a distribution list is represented as a contact in the target forest, and its membership cannot be expanded.

For complete information about MIIS 2003 GAL Synchronization, see the following resources:

• Microsoft Identity Integration Server 2003 Scenarios

  (https://go.microsoft.com/fwlink/?LinkId=21270)

• Microsoft Identity Integration Server 2003 (MIIS 2003) documentation

  (https://go.microsoft.com/fwlink/?LinkId=21271)

Supported Topologies for GAL Synchronization

As described in MIIS 2003 GAL Synchronization documentation, the servers running MIIS 2003 and Exchange forests must be arranged in either a mesh or a hub-and-spoke configuration. A combination of the two configurations is also supported. However, you cannot connect the forests in a chain.

Hub-and-spoke topology

In a hub-and-spoke topology, a single server runs MIIS 2003 and reads all of the data about all of the forests, evaluates changes and conflicts, and propagates the changes to each forest. This topology is recommended because it is centrally administered and is the easiest topology to deploy.

Supported mesh topology

In a mesh topology, each forest contains a server running MIIS 2003. Each forest is responsible for setting up the connections from their server running MIIS 2003 to every other forest. This topology is complex and is not recommended without thorough pilot testing. The main reason for selecting this topology is that forests do not have to allow write access to their directories. However, read access is still required; the management agents are configured to read directory information from all of the other forests.

Configuring Mail Flow Between Forests

After setting up GAL synchronization, you must ensure that mail flows properly between organizations and the Internet. For basic mail flow, the only requirement is that a route can be resolved to each adjoining forest. Trusts between the forests are not required.

Mail flow is determined by the network connectivity between forests and the way in which SMTP proxy addresses are configured. The ideal configuration is to have direct network connectivity between the forests with no firewalls. (If there are firewalls between the forests, you must open the appropriate ports.)

You must also set up SMTP connectors between the forests. Furthermore, it is recommended that you enable authentication across the forests. Enabling authentication has the following benefits:

• User name resolution (ResolveP2 registry key) between forests is automatic, which means that a user's e-mail address resolves to the user's name that is stored in Active Directory.

• Additional calendaring features and mail features, such as mail forwarding, are available.

To prevent the forging of identities (spoofing), Exchange 2003 requires authentication to resolve a sender's name to its display name in the GAL. In a multiple forest environment, it is recommended that you configure authentication so that users who send mail from one forest to another are resolved to their display names in the GAL, rather than to their SMTP addresses.

To enable cross-forest SMTP authentication, you must create connectors in each forest that uses an authenticated account from another forest. After you enable authentication, any mail that is sent between the two forests by an authenticated SMTP connection resolves to the appropriate display name in the GAL. For more information, see the Exchange Server 2003 Deployment Guide (https://go.microsoft.com/fwlink/?linkid=47569).

Configuring Extended Mail Features

Most companies have Internet connectivity and one or more published domain names. If each Exchange organization maintains a separate namespace, contacts that are synchronized between organizations need only one SMTP address for proper routing. However, you may have several Exchange organizations but only a single namespace that represents your company on the Internet (for example, contoso.com). In this case, to retain individual forest namespaces but still route mail properly to the individual forests, you must distinguish the forests from one another.

In addition, to enable or disable mail features such as out-of-office responses, automatic replies, and delivery reports, you may have to configure global settings.

Configuring a Shared SMTP Namespace

When GAL Synchronization creates contacts from mail recipients in a source forest, it uses SMTP addresses to create a TargetAddress property for each contact. Therefore, when users in a forest send mail to a contact, the mail is delivered to the contact's TargetAddress property, even if the user manually entered the primary reply address. To determine which TargetAddress GAL Synchronization should assign to a contact, it compares the recipient's ProxyAddresses property to the SMTP address for which the Exchange organization is responsible. Each organization must have a unique SMTP domain namespace so that contacts receive a unique TargetAddress. If your forests do not have unique namespaces, you can add a unique SMTP address to the appropriate recipient policies for each Exchange organization that contains users to be replicated across forests. After you do this, messages sent to a contact are routed directly to the source forest, where the target address resolves to the actual mailbox and the message is delivered.

You can also route contacts on a forest-by-forest basis. When setting up management agents for GAL synchronization, you can select whether mail sent to contacts that have been imported into a forest should route back through the source forest. If you have a connector to a foreign messaging system, by default, mail that is intended for a contact is routed to the source forest (the forest that manages the connector); however, the forest administrator can change this routing configuration.

As an example of SMTP routing in a multiple forest environment, consider two forests that each have a default recipient policy with an SMTP proxy address of contoso.com. To set up unique namespaces, you would do the following in each Exchange organization:

• In Organization 1, add an SMTP proxy address of Org1.contoso.com to the default recipient policy.

• In Organization 2, add an SMTP proxy address of Org2.contoso.com to the default recipient policy.

In both cases, when adding the proxy address, you would select the This organization is responsible for all mail delivery to this address check box. Also, you would leave the contoso.com proxy as the primary address so that, when a user sends mail, their reply address is user@contoso.com (rather than user@Org1.contoso.com or user@Org2.contoso.com).

Another example illustrates mail flow in a hub-and-spoke topology. In this example, multiple Exchange organizations are present, but all users can be addressed in a single domain space (for example, @example.com). In this case, all external mail addressed to @example.com flows into a central hub organization called OrgA. OrgA is configured with secondary SMTP proxy addresses that represent each spoke organization. One of these addresses is @OrgB.example.com. When mail addressed to UserB@example.com arrives at OrgA, the mail resolves to the contact, and the mail is redirected to OrgB. When the message leaves OrgA, the To line is changed to the TargetAddress propertyto allow for routing, but the Reply To address remains UserB@example.com.

For the following reasons, moving recipients from one organization to another does not prevent users from replying to old e-mail messages:

• The message retains the legacyExchangeDN property so that recipients can reply to the mail.

• GAL Synchronization creates a secondary X.500 proxy address for the user who was moved so that old messages can be properly routed to the user's new mailbox based on the legacyExchangeDN property.

For example, UserA sends mail to UserB, who is in the same organization. Later, UserA is moved to a different organization. The mail originally sent by UserA still specifies UserA's legacyExchangeDN property. GAL Synchronization creates a contact for UserA in the old organization and assigns an X.500 address with the old legacyExchangeDN property. This allows UserB to reply to the old mail, which, in turn, is properly routed to the TargetAddress property for UserA. If a mailbox is moved many times, the list of secondary proxy addresses can potentially grow large.

SMTP Relay Servers

If you want to use an SMTP relay server to route all mail from the Internet to the correct forest, it is recommended that you set up an SMTP relay server. On the SMTP relay server, create SMTP connectors to all of the other forests so that mail routes directly to each forest. This configuration allows you to add SMTP servers as needed for load balancing. You can also add SMTP connectors to route all outbound Internet mail through the new forest.

Configuring Global Settings

To enable or disable mail features such as out-of-office responses, automatic replies, and delivery reports, you must configure Internet Message Formats for the appropriate domains. Three methods for configuring Internet Message Formats are:

• Configure the Default domain (*) so that all domains have the same settings.

• Add a separate Internet Message Format domain for each SMTP namespace (for example @OrgA.contoso.com), and then configure each domain differently.

• Add an Internet Message Format domain that represents domains with a common suffix (for example @*.contoso.com) and then configure each entry differently.

Internet Message Formats are located in Exchange System Manager under Global Settings.

Sharing Free and Busy Data

In companies that have multiple Exchange organizations, a common requirement is the ability to coordinate meetings, appointments, and contact information with users in different Exchange organizations. Therefore, to replicate these free and busy system folders between forests, you can use the Inter-Organization Replication tool. If your company uses public folders, you can also use the Inter-Organization Replication tool to share public folder data across Exchange organizations.

The Inter-Organization Replication tool consists of two programs: the Exchange Server Replication Configuration tool (Exscfg.exe) and the Exchange Server Replication service (Exssrv.exe). Exscfg.exe creates a configuration file that Exssrv.exe uses to continuously update information from one server to another. The server that sends updates is the publisher, and the server that receives updates is the subscriber. All replication takes place over MAPI sessions that are established between servers in the organizations.

The Inter-Organization Replication tool publishes free and busy data for mailbox-enabled user objects and contact objects to other organizations, providing that equivalent contact objects exist in the target organization (as created by GAL Synchronization). The contacts are matched by their SMTP addresses. (When setting up the Inter-Organization Replication tool, use the Publish custom recipient free/busy data option.) You can then replicate all or a portion of the free and busy data from one organization to another. However, free and busy data replicates only in one direction. Therefore, to update free and busy data in both directions, you must configure two sessions.

You cannot use the Inter-Organization Replication tool to modify address books or directories. Any address book changes are not propagated to other organizations. These changes must be made independently.

Similar to free and busy data, you can replicate all or a portion of public folder data from one organization to another. However, unlike free and busy data, you can replicate public folders from publisher to subscriber or bi-directionally, resulting in fewer sessions. In addition, a single instance of the Inter-Organization Replication tool can support up to fifteen sessions—this means that a public folder server can subscribe to multiple publisher servers. You can specify individual folders or both folders and subfolders. Furthermore, you can configure the replication frequency, message and folder replication logs, and the amount of processing power you want dedicated to the replication process.

Whether you should configure the Inter-Organization Replication tool in a mesh configuration or in a hub-and-spoke configuration depends largely on the number of organizations in your environment. A mesh configuration is feasible for up to four organizations. However, if you have more than four organizations, it may be easier to manage the Inter-Organization Replication tool in a hub-and-spoke configuration.

Detailed configuration information for the Inter-Organization Replication tool is provided when you download the tool. For more information about the Inter-Organization Replication tool, see the following Microsoft Knowledge Base articles:

• 238573, "XADM: Installing, Configuring, and Using the InterOrg Replication Utility"

  (https://go.microsoft.com/fwlink/?linkid=3052&kbid=238573)

• 238642, "XADM: Troubleshooting the InterOrg Replication Utility"

  (https://go.microsoft.com/fwlink/?linkid=3052&kbid=238642)

Moving Mailboxes and Accounts Across Forests

To migrate accounts and mailboxes from one Exchange 2000 or Exchange 2003 organization to a separate Exchange 2000 or Exchange 2003 organization, it is recommended that you first use the Active Directory Migration Tool (ADMT), followed by the Exchange Migration Wizard.

First, run ADMT to create active user accounts in Active Directory. It is recommended that you select the option for migrating SIDs so that ADMT adds the source account's SID to the new target account's SID history attribute. (Migration Wizard uses the SID to match mailboxes to accounts in the next step.)

After you migrate the accounts, use Migration Wizard to migrate mailboxes. If you migrated SIDs when you ran ADMT, Migration Wizard uses the SIDs to match mailboxes to the new accounts and converts the accounts to mailbox-enabled user accounts. If you did not migrate the SIDs in the first step, Migration Wizard cannot match a mailbox to an account; instead, the wizard creates a disabled user account to associate with the mailbox.

There may be cases where you have to migrate mailboxes before you migrate accounts. In these cases, Migration Wizard creates disabled user accounts to hold mailboxes and then associates new mailboxes with external Windows NT accounts. Later, when you use ADMT to migrate accounts, new accounts are created in Active Directory. As a result, Active Directory contains two objects that relate to the same user. To merge these duplicate objects, use the Active Directory Account Cleanup Wizard (Adclean.exe). Adclean.exe is installed with Exchange and you can access it from Exchange System Manager (click Start, point to Programs, point to Microsoft Exchange, point to Deployment, and then click Active Directory Account Cleanup Wizard).

The following are limitations associated with moving mailboxes across forests. Plan for these situations, and notify users of the steps they must perform before and after the move:

• Outlook profiles cannot resolve users that have been moved across forests. After a user has been moved, the profile must be updated with the new server name to which the user has been moved. The Exchange Profile Update tool (Exprofre.exe) is a command-line tool that you run on client computers to automatically update users' Outlook profiles. Exprofre.exe modifies the default Outlook profile so that users can successfully log onto their mailboxes after the move. This tool is available from the Exchange Server 2003 Tools and Updates Web site (https://go.microsoft.com/fwlink/?linkid=21316).

• If you are using the Cached Exchange Mode feature in Outlook, ensure that, after you migrate accounts, the new profiles are associated with the correct .ost files on the users' computers. This action eliminates the need for re-synchronizing the .ost files. Also, before moving users, ensure that they have synchronized all of their offline files with the Exchange server.

• Mailbox access control lists (ACLs) or delegate permissions are not preserved during a cross-forest move.

• Published certificates are not migrated during the move. In addition, you cannot recover Key Management Service certificates after a move. To be recovered, the certificates require a domain name.

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

For more information about using Exchange Migration Wizard, see the Exchange Server 2003 Deployment Guide (https://go.microsoft.com/fwlink/?linkid=47569).