The supportability of Exchange 2000 organizations and of Exchange 2003 organizations across multiple forests

In Exchange , the Active Directory forest acts as the boundary for the Exchange organization's configuration data. Therefore, all configuration information for an Exchange organization must be contained in a single Active Directory forest. This includes all sites that are connected through directory replication connectors. Microsoft Product Support Services (PSS) does not support an Exchange organization that spans multiple forests. A scenario that is not supported exists when an Exchange Server 5.5 organization contains multiple Exchange 2000 servers or Exchange 2003 servers, where the latter servers are members of different Active Directory forests.

In Microsoft Exchange Server 5.5, the organization object is shared between all Exchange Server 5.5 sites that are connected to the organization through directory replication connectors. When you join an Exchange 2000 server or an Exchange 2003 server to an existing Exchange Server 5.5 site, the Active Directory forest of the new Exchange 2000 server or Exchange 2003 server inherits the Exchange Server 5.5 organization object. After the Exchange organization object is added to the Active Directory forest, the forest represents the boundary of the organizational object.

The Microsoft Exchange Setup program cannot detect whether an Exchange Server 5.5 organization already contains Exchange 2000 servers or Exchange 2003 servers from other forests. Therefore, the Exchange Setup program does not prevent you from introducing Exchange 2000 servers or Exchange 2003 servers from different forests into Exchange Server 5.5 sites that are in the same organization. If you span the original Exchange organization across multiple forests, many intra-organizational features of Exchange 2000 and Exchange 2003 will not work correctly. Because there is no central management of site components and of topologies for each forest in a spanned configuration, long-term problems may occur that Microsoft PSS cannot support. Therefore, all Exchange 2000 servers and Exchange 2003 servers in an organization must reside in the same forest.

Known issues

The following list discusses some of the known issues that you may experience if you try to configure Exchange 2000 servers or Exchange 2003 servers from different forests to join the same Exchange Server 5.5 organization.

• Although mail flow may appear to work correctly at first, there are long-term mail routing issues. Link-state information does not replicate between servers in different forests. Eventually, users on Exchange 2000 servers or Exchange 2003 servers in one forest cannot send e-mail messages to users who reside on Exchange 2000 servers or Exchange 2003 servers in another forest.
• There is not a centralized or consistent set of configuration information and recipient policies. All the Exchange 2000 servers and the Exchange 2003 servers store and read their configuration from the configuration naming context that is in a single Active Directory forest. However, in this unsupported topology, configuration naming contexts are neither writable nor authoritative for all Exchange 2000 servers and Exchange 2003 servers in the topology. There is no built-in Active Directory replication of configuration naming contexts between different forests.
• You cannot switch your Exchange organization to native mode because if you span an Exchange organization across multiple forests, the Microsoft Exchange Site Replication Service (SRS) will continue to replicate the mixed administrative groups of other forests as pure Exchange Server 5.5 sites. Therefore, you cannot switch the Exchange organization to native mode unless you back down from the unsupported configuration and then remove all instances of the SRS.
• Routing group connectors that are established between each administrative group that contains servers from different forests experience problems because the connectors try to use intra-forest authentication to send e-mail messages. Because the Exchange 2000 machine accounts and the Exchange 2003 machine accounts do not have the same security identifier (SID) in each forest, resolution of P2 headers fails. Therefore, users may see an inconsistent sender display name when they receive e-mail messages that are sent between forests.
• Global settings such as the mobility features in Exchange 2003 and message size limits are no longer "global" because these settings cannot affect Exchange 2000 servers or Exchange 2003 servers that are members of other forests.
• Public folder replication may not work correctly. The public folder hierarchy has backlinks that point to the distinguished names of public stores from different forests. The backlinks cannot be updated. Also, a spanned Exchange organization across multiple forests may produce duplicate MAPI public folder tree hierarchies with different contents.

Potential workarounds

Although a single Exchange organization was not designed to function across multiple forests, there are potential workarounds. If there is a business requirement for data isolation or for administrative autonomy that requires separate forests, you can install new Exchange organizational objects into separate forests. To function correctly, these new Exchange organizations must not replicate their Global Address List information using Exchange Server 5.5 directory replication connectors. Instead, you can configure them to replicate the Global Address List from other Exchange organizations by using replication tools that are not built into Exchange.

If your company business unit maintains your own Exchange Server 5.5 site that is part of a larger conglomerate, you can use either of the following two methods to configure Exchange into a separate forest:

Method one

1. Although your Exchange Server 5.5 site is connected to remote Exchange Server 5.5 sites for other business units, you can remove Exchange Server 5.5 directory replication connectors so that the local business unit is temporarily isolated from the rest of the organization.
2. Install Exchange 2000 or Exchange 2003 into its own isolated forest. When you install Exchange, choose to join the existing stand-alone Exchange Server 5.5 site.
3. You can use Microsoft Identity Integration Server (MIIS) 2003 to replicate and to re-establish the Global Address Lists between the local business unit's forest and the conglomerate's forest.

Although the Exchange organizational object that the new forest inherits matches the name of the conglomerate's organizational object, they are considered to be independent Exchange organizations.

Method two

An alternative method that prevents temporary Global Address List interruption is not to touch the existing Exchange Server 5.5 site at first.

1. Install Exchange 2000 or Exchange 2003 into a new forest without choosing to join an Exchange Server 5.5 site.
2. Set up MIIS 2003 to replicate the Global Address Lists.
3. Use the Exchange Migration Wizard to start a cross-organization migration of the mailboxes in the existing 5.5 site into the new forest that is in a new Exchange organization.
4. After the migration wizard has migrated a user to the new organization, delete the old Exchange Server 5.5 mailbox object and use MIIS 2003 to populate a custom recipient in its place. The custom recipient will point to the migrated mailbox in the new forest. This permits mail flow to continue.

REFERENCES