Exchange Server 5.5 provides users with robust messaging and collaboration services when the users are in one Exchange organization. But when business situations require multiple organizations, such as during a merger, you need additional tools and processes to keep the Exchange directories updated. In Exchange Server 5.5, each organization includes a separate Directory Service (DS), which handles all replication of objects between servers and sites. Using one organization is always preferable to using any interorganizational solutions because one organization is easier to implement and support. In addition to sharing directory information, companies might also need to share public folders and Schedule+ free/busy information between these systems, However, this article discusses only the interorg directory requirements.
You can update directories through replication or synchronization, but when do you use which process? Let's examine both processes and look at scenarios that require one or the other of them so that you can better understand what you need to do in your environment.
Replication and Synchronization
First, let's define the terms replication and synchronization. Replication is the process of updating objects in a common directory namespace to one or more directory instances. Synchronization is the process of copying objects from one directory to another in separate directories with distinct namespaces. Replication is also defined in a multi-master update topology, in which updates can be made at any server; synchronization is generally point-to-point and changes are aggregated across one connection. I use the term replication to refer to the process that keeps objects updated within the Exchange Server 5.5 directory between different sites and servers within the sites. Exchange administrators are familiar with this built-in directory replication process because it keeps their Exchange directories consistent. The term synchronization refers to processes that copy objects between Exchange and another system such as Lotus Notes or Novell GroupWise through Exchange Server 5.5 connectors.
An interorganizational synchronization requirement exists when you need to create directory entries for users in two or more Exchange Server 5.5 organizations that don't share the same root organization name. Keep in mind that the boundary of Exchange Server 5.5 is the organization; you can't create a native directory replication connector (DRC) between two organizations with different names. So if you have one organization named South and another named North, you can't replicate directory entries between them with the built-in directory update process, even if you can create an X.400 or SMTP connector for mail transfer.
Some situations (e.g., using the Active Directory Connector—ADC—to populate the Active Directory—AD—from Exchange Server 5.5) require directory replication rather than directory synchronization. Replication occurs natively in Exchange Server 5.x or the AD.
Several interorg synchronization solutions are available for Exchange Server 5.5. Some solutions work with Exchange Server 5.0 or Exchange Server 4.0, but I cover only those that work with Exchange Server 5.5.
Scenarios That Require Interorg Solutions
One scenario that requires an interorg synchronization solution is the merger of two companies. If each company had deployed Exchange in one organization, which is the optimal configuration, the companies undoubtedly wouldn't have used the same organization name spelled the same way and in the same case. During most mergers, each company's technical support staff must create a seamless messaging environment so that the companies can begin to communicate and create a symbiotic corporate culture. In this scenario, you need to look at the messaging and collaboration requirements. Do you simply need to see the other company's users in your Global Address List (GAL), or do you also need cross-organization scheduling and public folder access? For public folder access or free/busy synchronization, you need additional tools such as the public folder interorg tool from Exchange Server 5.5 Service Pack 2 (SP2).
Another scenario that requires an interorg solution is a company that has deployed Exchange in workgroup pockets that have different organization names. This situation typically occurs in companies that started small or that don't have a centralized information technology standard, but now want to create one standard for messaging and collaboration. These types of interorg solutions are usually more political than technological because the corporate political landscape probably shaped the initial Exchange installations. The company will probably consider any interorg solution only a short-term coexistence option that lets you move all the servers into one organization. In this situation, you must weigh interorg options against using the Exchange Move Server Wizard to move the mailboxes server by server from one organization to another. Be aware that using the Move Server Wizard is tricky. I don't cover the wizard here, so consult the documentation that comes with the tool before you use it. Tony Redmond, "Move Server Wizard War Stories," August 1999, also discusses using the wizard.
Exchange Server 5.5 Interorg Solutions
You can use several methods for interorg directory synchronization in an Exchange Server 5.5 environment. Because of Exchange Server 5.5's limitations, the built-in directory-replication mechanism can replicate directories only with an Exchange system that has the same organization name. This restriction poses problems when companies merge or when business units within the same company decide to connect separate systems.
Options for connecting two organizations range from completely reinstalling Exchange to using interorg synchronization tools such as the InterOrg Synchronization Tool from the Microsoft BackOffice 4.5 Resource Kit (BORK). You can use the Move Server Wizard to rename one of the systems with the name of the other system, but this operation can be difficult, especially if you're working with more than two systems. The following two sections briefly outline two of the most commonly used Exchange 5.5 Server interorg directory solutions—the LinkAge Directory Exchange connector and the InterOrg Synchronization Tool—and explain why you can't use these solutions to perform interorg synchronization in an Exchange 2000 Server environment.
The LinkAge Directory Exchange Connector. The LinkAge Directory Exchange connector lets you synchronize two or more Exchange organizations or synchronize Exchange with foreign mail systems such as Lotus cc:Mail, SNADS, IBM OfficeVision, and Lotus Notes. Microsoft acquired the connector when it bought LinkAge in 1997 and brought technology from this tool's powerful and flexible architecture into the current Exchange Server 5.5 SNADS and Lotus Notes connectors.
A flexible, efficient tool, LinkAge Directory Exchange works by installing agents into the source and the target Exchange system to help the product send and receive directory updates. However, because the Exchange agents use the Directory API (DAPI) and Microsoft is phasing out the LinkAge Directory Exchange, the solution isn't viable for synchronizing between either Exchange 2000 or Exchange Server 5.5 organizations.
The InterOrg Synchronization Tool. Microsoft Consulting Services developed the InterOrg Synchronization Tool for a customer that needed to synchronize many different Exchange organizations into a cohesive directory. This tool is included in the BORK; you can obtain the most recent version of BORK 4.5 on TechNet. For installation instructions, see the Microsoft article "XADM: How to Install, Configure, and Use the InterOrg Synchronization Tool" (http://support.microsoft.com/support/ kb/articles/q198/7/89.asp). The sidebar "How the InterOrg Synchronization Tool Works," page 13, explains how the tool functions.
Because the InterOrg Synchronization Tool uses the Exchange Server 5.5 DAPI, the tool doesn't work with Exchange 2000 because Exchange 2000 doesn't support DAPI for updates. However, to merge an existing Exchange Server 5.5 environment with an Exchange 2000 organization, you can use the InterOrg Synchronization Tool in the Exchange Server 5.5 environment and the ADC to synchronize with the AD. But be aware that after you upgrade or decommission Exchange Server 5.5, the InterOrg Synchronization Tool will stop working. For this reason, you need to remove any InterOrg Synchronization Tool installations from your Exchange Server 5.5 environment before you upgrade. Microsoft Product Support Services (PSS) supports this tool only on a "best-effort" basis, and Microsoft doesn't offer bug fixes. Therefore, you need to consider this support limitation in your decision to use this solution.
Windows 2000 with ADC
The ADC's primary function is to synchronize the Win2K AD with the Exchange Server 5.5 directory. You can use the ADC to help implement the AD in organizations that have already deployed Exchange Server 5.5 and want to achieve coexistence between Exchange 2000 and Exchange Server 5.5. (See Kieran McCorry, "5 Things They Never Told You About the ADC," page 1, for information about this use of the ADC.) However, you can also use the ADC as a standalone tool to synchronize directory entries between two or more Exchange Server 5.5 organizations in an interorg scenario.
You install the ADC as an additional component for Win2K and Exchange 2000. After you install the ADC, a new Windows service—the Microsoft Active Directory Connector—appears in the services section of the computer management console. You can start and stop this service just like any other service. The installation includes a snap-in and an .msc file, which configures connection agreements (CAs) between the AD and the Exchange target directory. The ADC
- Uses the Lightweight Directory Access Protocol (LDAP) APIs to perform fast replication between AD and the Exchange Server 5.5 SP3 DS
- Hosts all active replication components on AD, not another system, so that the AD does the processing and implements the replication logic
- Replicates only changes between the directories whenever possible
- Maintains object fidelity through replication (e.g., the Active Directory Group object maps to the Exchange Distribution List (DL) object)
- Hosts multiple connections on one server and manages these connections through CAs
Configuring the ADC for Interorg Synchronization
Because the ADC can replicate Exchange mailbox, custom recipient, and DL objects to AD and puts them into a specific organizational unit (OU), you can easily build an interorg replication solution. Using AD as the intermediary, you can set up multiple ADC CAs to replicate specific organizations, Exchange sites, or Recipients containers into an OU in AD. Using separate CAs, you can easily replicate those entries to a target Recipients container in separate Exchange organizations.
The first step in creating an interorg solution for Exchange Server 5.5 is to install the Exchange 2000 ADC into your production forest, then establish an intraorganizational CA to the existing Exchange Server 5.5 environment. An intraorg CA is different from an interorg connection; you need an intraorg CA to install Exchange 2000 using the same organization name as the Exchange Server 5.5 environment. Simply put, you can't create an interorg solution without taking the first step toward your Exchange 2000 upgrade by installing the ADC in your production AD forest. For information about installing the ADC and configuring CAs within an organization, see the "Exchange 2000 Deployment Guide" in the Microsoft Exchange Server 2000 Resource Kit and Bill English, "Planning for and Configuring the Active Directory Connector," March 2000.
After you configure the intraorg CA, you can install as many interorg CAs as you need to many different Exchange 5.5 organizations. To create an interorg CA, go to the Advanced tab of the CA Properties dialog box, and select the This is an Inter-Organizational Connection Agreement check box, as Figure 1 shows. This setting tells the ADC and Exchange 2000 that the target mailboxes for this connection are in a different Exchange organization. You usually need to deploy two one-way CAs to create this interorg configuration because this setting gives you more control over source and target locations for mailboxes. A one-way CA would cause all the contacts to be created in the Recipients container with your mailboxes—a situation most administrators don't want. By using two one-way CAs, you can map one or more OUs from the AD to a separate Recipients container in Exchange, then map the Exchange recipients to a separate OU in AD. By design, you can currently set the interorg option only on the From Exchange CA.
If you deploy the ADC in your production Win2K forest and accidentally configure an interorg CA before you configure the required intraorg CA, you won't be able to deploy Exchange 2000 in that forest. You must either recreate the forest before you install Exchange 2000 or deploy Exchange 2000 in a completely separate forest. Therefore, in your migration, you first need to integrate Exchange Server 5.5 with Exchange 2000 and AD, then deploy interorg connections to the other Exchange Server 5.5 organizations. The Microsoft article "XADM: Support Boundaries for Active Directory Connector Inter-Organization Synchronization" (http://support.microsoft.com/support/kb/ articles/q264/4/82.asp) explains this problem.
Two ADC Versions
You can synchronize Exchange Server 5.5 and AD by using the ADC that Microsoft includes with Win2K Server; this version is sufficient for preparing your AD to install Exchange 2000. However, an updated version is installed when you install Exchange 2000. This updated ADC version provides functionality to keep Exchange 2000 and Exchange Server 5.5 synchronized and has new features you need to establish the required intraorg replication between an existing Exchange Server 5.5 organization and Exchange 2000. The Exchange 2000 version of ADC is also the only version that you can use to provide interorg coexistence between multiple Exchange 5.5 Server organizations and Exchange 2000. The Win2K version doesn't support interorg CAs; for this reason, Microsoft doesn't support the Win2K ADC if you try to use that ADC in this manner. Because of other limitations in the Exchange 2000 ADC, you can't use that ADC version to provide interforest replication between two different Exchange 2000 organizations because Exchange 2000 uses the AD instead of a separate directory. For information about interforest solutions, see the "Exchange 2000 Deployment Guide." I'll also discuss solutions for this situation in a future article.
The Best Solution
You can use several solutions to synchronize mailbox information between two or more Exchange Server 5.5 organizations. Some solutions have only limited support or aren't flexible enough to meet many companies' needs. For this reason, the best way to create an Exchange Server 5.5 interorg solution is to take the first step in your Exchange 2000 migration. This process involves setting up the Exchange 2000 ADC in an intraorg CA to the Exchange Server 5.5 forest you plan to upgrade; then you can create as many interorg connections as you need. This approach lets you leverage the AD's power and flexibility to serve as a hub in interorg replication and also facilitates the process of upgrading to Exchange 2000.
