As you migrate from Microsoft Exchange Server 5.5 to Exchange 2000 Server, you probably won't be able to migrate all Exchange Server 5.5 mailboxes in one action. A more likely scenario, particularly if your environment contains thousands of users, is a long period of coexistence during which your organization will have both Exchange 2000 and Exchange Server 5.5 users.
Exchange Server 5.5's Directory Service (DS) provides a Global Address List (GAL) to Exchange Server 5.5 mail clients and offers a repository for Exchange Server configuration information. Exchange 2000 relies on Windows 2000's Active Directory (AD) to provide these services. During a period of coexisting Exchange 2000 and Exchange Server 5.5 users, you must maintain one homogeneous GAL across both user communities. Furthermore, to maintain interoperability between Exchange 2000 and Exchange Server 5.5 systems and enable the seamless transfer of messages, the two environments must be able to exchange configuration information.
The Active Directory Connector (ADC) is a sophisticated tool that uses a synchronization engine based on the Exchange Server 5.5 replication mechanism and Lightweight Directory Access Protocol (LDAP) to provide object-based bidirectional synchronization between the Exchange Server 5.5 DS and AD. Specifically, the ADC synchronizes recipient data (e.g., mailboxes, custom recipients, distribution lists—DLs) from the Exchange Server 5.5 DS to users, contacts, and groups in AD and vice versa. From a directory perspective, the ADC achieves this functionality by synchronizing containers from the Exchange Server 5.5 DS sites with organizational units (OUs) from the AD domain naming context. This synchronization provides a consistent GAL. The ADC also synchronizes configuration data, which facilitates Exchange Server interoperability. The ADC achieves this synchronization by linking the Exchange Server 5.5 configuration container with the AD configuration naming context. However, for successful synchronization, you must use the right ADC for the job.
Two ADC Flavors
An ADC version ships on both the Win2K installation CD-ROM and Exchange 2000 CD-ROM. Which one should you use? As a general rule, you should use the latest version of a tool or utility. If you check the version properties of the different versions' adc.exe files, you'll discover that the ADC from the Win2K CD-ROM has a build number of 6.0.3939.7, and the ADC on the Exchange 2000 CD-ROM has a build number of 6.0.4417.0. If your ADC doesn't have the latter build number, install the Exchange 2000 ADC. If your ADC's build number isn't one of the numbers I listed, you're probably using an ADC from a beta or release candidate (RC) version of Win2K. Replace this ADC with the version on the Exchange 2000 CD-ROM.
Some important functional differences exist between the two ADC versions. For example, the Win2K ADC only synchronizes recipient information between the Exchange Server 5.5 DS and AD. To synchronize configuration information, which is mandatory for Exchange 2000 and Exchange Server 5.5 coexistence, you must use the Exchange 2000 ADC. In addition, early versions of the ADC bundled the synchronization of public folder mail addresses into the general recipient synchronization instance. The Exchange 2000 ADC synchronizes public folder mail addresses in a separate instance; this setup offers administrators more flexibility and a simpler configuration. (The Exchange 2000 ADC synchronizes only the mail addresses of public folders, not public folder content.)
In addition, Microsoft has updated and applied many bug fixes to the Exchange 2000 ADC. To be sure of the highest-fidelity synchronization, use the most up-to-date ADC.
ADC Schema Extensions
The ADC CD-ROM includes a set of schema extensions that the ADC installation must apply to AD. These extensions are a subset of the Exchange 2000 schema extensions, and the ADC requires the extensions because it will create mail- or mailbox-enabled objects in AD to represent Exchange Server 5.5 mailboxes, custom recipients, or DLs. The standard schema that ships with Win2K doesn't provide the necessary class definitions in the directory to represent these mail objects. If you've previously installed the ADC into your production environment, check to ensure that the installation applied the necessary ADC schema extensions.
When you install the ADC, the installation program compares an attribute in AD that defines the version of the schema extensions against the version of the schema extensions provided with the ADC version you're installing. You can perform this check manually by comparing the value of the rangeUpper attribute of ms-Exch-Schema-Version-Adc, which Figure 1 shows, to the value of the same attribute defined at the end of the adcschema9.ldf file in the ADC installation subdirectory. (This attribute in the release to manufacturing—RTM—version of the ADC has a value of 4197.) If the values are the same, another ADC installation won't apply new extensions. To perform a minimal installation of the ADC and install only the schema extensions, you can run the ADC setup.exe /Schemaonly command from the ADC installation directory.
Knowing whether an ADC installation will apply new extensions is useful information. When the installation program applies new ADC schema extensions, the modifications to the schema cause the system to replicate the Schema Naming Context across the whole AD forest. In addition, the ADC schema extensions modify attributes so that the attributes replicate to Win2K Global Catalog (GC) servers. By default, when any change takes place to the set of attributes that are replicated to a GC server, all the attributes that take part in GC forestwide replication are replicated again. Therefore, merely adding extensions to the schema can result in a significant wave of replication across your AD environment, particularly if your environment includes many AD objects.
Container Mapping
The ADC hosts synchronization instances between the Exchange Server 5.5 DS and AD. These instances are known as connection agreements. CAs define synchronization characteristics; they specify the source and target servers for a particular synchronization, the source and target locations in the respective directories, and several object-mapping-related features, and they define the authentication credentials so that the ADC can access both the Exchange Server 5.5 DS and AD.
Generally, a specific CA defines a many-to-one mapping of containers between directories. That is, when you define the source locations for a given CA, you can specify multiple containers from which you'll synchronize objects as long as the objects are all mapped to one container in the target directory. For example, Figure 2 shows three recipients containers from the Exchange Server 5.5 DS that are mapped to one OU in AD. The ADC doesn't let you define multiple target locations.
However, many-to-one mapping doesn't mean you must have one CA per source container if you have multiple containers in your source directory and you want to retain the same structure. Although the mapping function is many-to-one, you can configure the ADC to synchronize the container hierarchy, so you can specify that the ADC synchronize an entire Exchange Server 5.5 site hierarchy (and all objects within that site) to one OU in AD and maintain the hierarchy across the synchronization.
To support centralized management of both Exchange Server 5.5 DS objects and AD objects from the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, each Exchange Server 5.5 site requires its own CA. You need at least one CA per site so that the CA can write changes back to objects in the Exchange Server 5.5 DS because in Exchange Server 5.5, objects outside their home site are read-only.
CA Direction
CAs can be 1-way or 2-way. One-way CAs can be from the Exchange Server 5.5 DS to AD or from AD to the Exchange Server 5.5 DS. With 2-way CAs, synchronization takes place in both directions. Although 2-way CAs are usually preferable, in some cases, 1-way CAs are all that you'll require. Understanding the functional differences between 1- and 2-way CAs is important.
As an example of a single 1-way CA mapping, Figure 3 shows the Exchange Server 5.5 Recipients container for the site Alderaan mapped in a 1-way CA mapping to the Exchange Server 5.5 Recipients OU. In this configuration, the ADC replicates any changes that an Exchange Server 5.5 administrator makes to an object in the Recipients container to the synchronized object in the Exchange Server 5.5 Recipients container in AD. However, if an AD administrator makes any changes to the synchronized object in the AD Exchange Server 5.5 Recipients container, the ADC won't propagate these changes back to the Exchange Server 5.5 object. Furthermore, when the ADC runs again, it will overwrite the value of the modified attribute on the synchronized AD object with the existing value of the attribute from the Exchange Server 5.5 DS. Therefore, 1-way CAs are commonly employed only at the start of a migration as messaging system managers learn to trust AD system managers.
To let modifications flow in both directions, you need to configure this CA so that it operates in 2-way mode. Operating in this fashion lets AD become a single point of administration for Exchange 2000 and Exchange Server 5.5 objects because the ADC will replicate modifications an administrator makes to synchronized objects in the AD Exchange Server 5.5 Recipients container to the Recipients container in the Exchange Server 5.5 DS.
For a CA to be a 2-way CA, the container synchronization you specify on the From Exchange and From Windows tabs of an attribute's properties page must be symmetrical. For example, to configure the previously mentioned 1-way CA to be a 2-way CA, you would set the Exchange recipients containers to Recipients and set the Default destination to Exchange Server 5.5 Recipients. Then, on the From Windows tab, you would set the Windows Organizational Units to Exchange Server 5.5 Recipients and the Default destination to Recipients.
Merely specifying that a CA is 2-way, then providing an arbitrary collection of containers and OUs doesn't produce 2-way synchronization. For example, suppose on the From Exchange tab, you listed Recipients in the Exchange recipients container and defined Exchange Server 5.5 Recipients as the Default destination. Then on the From Windows tab, you specified Users as the Windows Organizational Units and Recipients as the Default destination. You haven't configured a 2-way CA because the synchronization is unbalanced. No mechanism exists for the ADC to replicate modifications to synchronized objects in the Exchange Server 5.5 Recipients container to the Recipients container in Exchange Server 5.5.
In Figure 4, the AD administrator has moved a synchronized object from Exchange Server 5.5 Recipients to the Alternative 5.5 Recipients container. No CA maps the Recipients container in Exchange Server 5.5 to the AD Alternative 5.5 Recipients container; however, if an administrator changes the object in the Exchange Server 5.5 DS, the ADC will replicate the change to the synchronized object in AD even if it has been moved to another container. In this case, the ADC handles synchronization as if it were an invisible 1-way CA from the Recipients container in Exchange Server 5.5 to the Alternative 5.5 Recipients container in AD. Regardless of where you relocate an object in AD, the CA linking the Recipients container to the Exchange Server 5.5 Recipients OU tracks the moved object using the Win2K globally unique ID (GUID) and will always replicate Exchange Server 5.5 changes to AD.
However, the ADC doesn't replicate changes an administrator makes directly to the synchronized object in the AD Alternative 5.5 Recipients container to the original object in the Exchange Server 5.5 DS. For the ADC to replicate these modifications, an additional 1-way CA is required, mapping the Alternative 5.5 Recipients to the Recipients container in the Exchange Server 5.5 DS.
Object Matching and AD Renaming
When the ADC attempts to synchronize an object from the Exchange Server 5.5 DS with AD, it will search AD, attempting to find an existing object with which it can match the source object. If the ADC has previously synchronized an object from the Exchange Server 5.5 DS with AD, the ADC will search for an object that has an msExchADCGlobalNames attribute that matches the distinguished name (DN) of the source object. When it first synchronizes an object, the ADC populates the msExchADCGlobalNames attribute, which helps the ADC track synchronized objects. Figure 5 shows the value of this attribute for an Exchange Server 5.5 mailbox that has an alias of KarenW in the Recipients container of the site Valbonne in the organization Compaq Research.
If the ADC can't find a match, it tries to find a match based on the object's GUID. When the ADC first synchronizes an object, the ADC writes the GUID of the synchronized AD object into the ADC-Global-Names attribute of the original Exchange Server 5.5 object. The ADC uses the NT5 string in this attribute, which is really the GUID of the AD object, and searches the AD looking for a match. (The Exchange Server 5.5 Service Pack 3—SP3—installation program adds the ADC-Global-Names attribute to the Exchange Server 5.5 DS schema.)
If these matching rules fail, or if the ADC has never synchronized the source object to AD, the ADC uses the default matching rules, which employ the SID and SID History attributes, to find a match. (For more information about how to manage ADC object matching, see the Exchange Administrator newsletter article "ADC Filtering and Object-Matching," January 2001, InstantDoc ID 16139.)
If the ADC finds a matching object, the ADC merges the attribute information from the Exchange Server 5.5 DS object into the existing AD object. If no match is found, the ADC creates a new object and merges the Exchange Server 5.5 attribute information into the new AD object.
When the ADC first matches an Exchange Server 5.5 DS object to an object in AD or creates a new AD object, something interesting happens to the DN of the AD object. By default, the AD object's DN is modified to take on the same value as the Exchange Server 5.5 DS object's display name. A mapping rule defined in the msExchServer2SchemaMap attribute of the Default ADC Policy or the properties of the CA controls this remapping process. The following example of a mapping rule effectively instructs the ADC to override the existing AD object's DN with the cn attribute of the Exchange Server 5.5 object:
local###cn#Override_RDN_Value### 140#
(The cn attribute is the LDAP name for the Exchange Server 5.5 display name.)
Although this synergy between the Exchange Server 5.5 mailbox display name and AD object DN is useful, you might find it problematic because it alters the naming structures that you might already have in AD and can therefore result in confusion. You can disable this mapping by setting the flag (i.e., 140 in the previous example) to 10, which instructs the ADC to ignore the mapping. Alternatively, you can change the rule so that the ADC uses a different Exchange Server 5.5 source attribute. (For more information about ADC schema mapping, see the Exchange Administrator newsletter article "How to Customize DS-to-AD Attribute Synchronization," March 2001, InstantDoc ID 19712.)
Closing Thoughts
At first glance, the ADC appears to be a straightforward tool: You simply point one end of a CA at an Exchange Server 5.5 system and the other end at AD, and the result is a homogeneous directory. Although this simplified scenario is partially true, the whole truth is that you must apply quite a few refinements to configure the ADC to function correctly in your environment.
To build a solid foundation of understanding, which will be indispensable when you deploy the ADC in a real-world production environment, this article touched on many of the less intuitive aspects of the ADC. In Part 2, I'll take a closer look at how this functionality is put to work in case studies that involve coexisting Exchange Server 5.5 and Exchange 2000 environments and migration projects.
