Planning for and Configuring the Active Directory Connector

One challenge you'll face when you upgrade to Microsoft Exchange 2000 Server is how to migrate your Exchange Server 5.5 Directory information to the Windows 2000 (Win2K) Active Directory (AD). Because many companies store important contact and employee information in their Exchange directories, uploading this information to AD is an important component of their Exchange 2000 migration strategy. To facilitate this migration, Microsoft created the Active Directory Connector (ADC), a service that runs on your Win2K server that lets you synchronize your Exchange Server 5.5 and Win2K directories. Let's look at how to plan for, install, and implement the ADC and consider some scenarios that will help you apply this information to your situation.

ADC Versions
The ADC comes in two versions: One version ships with Win2K Server, and another version ships with Exchange 2000. The Win2K ADC lets you replicate Directory information in your Exchange Server 5.5 organization to the Win2K AD. In addition, this ADC lets the Win2K administrator perform basic administrative tasks in the Exchange Server 5.5 Directory.

By contrast, Exchange 2000's ADC version not only lets you synchronize Exchange Server 5.5 Directory information with Win2K but also lets you replicate the Exchange Server 5.5 configuration data with the Exchange 2000 configuration data stored in AD. This synchronization lets both systems know about the other's configuration so that the systems can coexist seamlessly. If you upgrade to Exchange 2000 on a system on which you've previously installed the Win2K ADC, Exchange automatically updates the ADC to the Exchange 2000 version.

After you synchronize the directories, the Win2K AD becomes the basis of the Global Address List (GAL) for users who connect to the Exchange 2000 server. Users connecting to the Exchange Server 5.5 Directory will continue to access the GAL from the Exchange Directory Store.

Planning the ADC
You configure synchronization between directories by defining the connection agreements (CAs) that the ADC manages. The ADC service (MSADC) can manage multiple CAs. The agreements must contain server names, objects to synchronize, target containers, and a synchronization schedule.

You can set up your CAs in many ways. For example, you can synchronize multiple Exchange recipients containers with one AD container, multiple AD containers with one Exchange recipients container, multiple Exchange containers with multiple AD containers, or multiple AD containers with multiple Exchange containers. Moreover, you can configure each CA to synchronize single or multiple object types. Thus, you can rebuild one Exchange recipients container that holds both users and distribution lists (DLs) into two AD containers—one for users and the other for DLs.

The ADC can manage one-way CAs (i.e., from Exchange to AD or from AD to Exchange) or two-way CAs (i.e., both ways between Exchange and AD). If you want to upload your existing Exchange Server 5.5 Directory information to your Win2K AD, choose From Exchange to Windows—a one-way CA—to update the AD when you modify your Exchange Server 5.5 Directory. Defining one CA that covers an entire Exchange organization is the simplest scenario to manage. However, this choice means that objects modified in remote Exchange Server 5.5 sites won't quickly synchronize to your AD because replicating modifications to your Exchange site takes time—possibly hours or days.

If you want to know the maximum amount of time your Exchange Directory needs to replicate a modified object to your AD, you can calculate how long the Directory takes to replicate object information from the farthest point in your replication topology. For example, assume that XYZ company has four Exchange Server 5.5 sites: Sacramento, Tucson, Minneapolis, and Indianapolis. The company has one Win2K AD domain with domain controllers in each city. The Indianapolis Exchange server and the AD have an ADC and one one-way-from-Exchange CA between them.

These sites connect in a linear fashion over T1 lines (i.e., the T1 topology connects Sacramento with Tucson, then Tucson with Minneapolis, then Minneapolis with Indianapolis). The Exchange site and connector topology follows the physical topology (i.e., X.400 connectors exist between Sacramento and Tucson, Tucson and Minneapolis, and Minneapolis and Indianapolis).

If the T1s are frequently saturated with non-Exchange traffic, you might reasonably schedule replication at 6-hour intervals. If you use a 6-hour replication schedule, replicating an object in the Sacramento site to the Indianapolis site might take as long as 18 hours—the maximum length of time Exchange needs to synchronize a modified object in the Sacramento site with the AD.

Before you deploy the ADC, you need to answer several questions:

1. Do you want to administer all your directory objects from the AD? You can manage all your Exchange Server 5.5 and AD objects with one tool: Active Directory Users and Computers. However, this approach requires a CA to each of your existing Exchange sites, which requires remote procedure call (RPC) connectivity. Moreover, you need to configure your CAs to write to the Exchange Directory. To accomplish these goals, you need to choose a one-way-from-Windows CA to each of your Exchange sites. This option lets the ADC create new objects in the AD and then replicate them to your Exchange Directory.

Because one CA will write Directory information into each of your Exchange Server 5.5 sites, the Exchange Directory Service (DS) will want to replicate that new information to all the other sites. Be careful not to inadvertently choose the wrong AD container in which to create or modify an object and then create an identically named object in another container to compensate for your mistake. This practice could lead to multiple instances of identically named objects in your Exchange Directory. Administering all the Directory objects from the AD requires daily administration of your objects.

2.Do you want to continue using the Microsoft Exchange Administrator program to manage your existing Exchange Server 5.5 environment until you've completed the migration? If you want to continue using Exchange Administrator, you need to define most of your CAs as one way from Exchange; that is, the ADC regards your Exchange Directory as read-only. In addition, this arrangement requires only a single-point CA from one of your sites because the Exchange DS will replicate any new or modified objects into the site hosting the Exchange end of the CA. Moreover, you'll need only one RPC from your Win2K server to your Exchange server. This scenario is beneficial if you want to reduce management time and replication traffic.

3. Do you want the flexibility to create new accounts in both your Win2K and Exchange directories? This scenario gives you great flexibility. For example, you can easily preserve your existing container structure and have only one Exchange site. Simply choose the default recipients container, and the ADC will replicate the entire Directory structure under whatever container you choose in Win2K. Some companies create subcontainers under the recipients container for objects such as custom recipients and DLs. If you want to replicate these subcontainers to different containers or organizational units (OUs) in your Win2K directory, you need a separate CA for each Exchange container that the ADC will replicate to a different Win2K container.

You might want this flexibility if you have decentralized administration in which each department or division manages its user groups or if your migration will extend over a long time (i.e., 6 months or more). This scenario requires a two-way CA (i.e., the ADC regards each directory as write-enabled), and you must carefully coordinate which team creates which user accounts. You need to consider the security and administrative implications if you're giving users outside your administrative teams Lightweight Directory Access Protocol (LDAP) access with write privileges to either of your directories: If outside users incorrectly modify or create objects, the ADC will replicate the incorrect objects to both directories.

As you can see from these scenarios, you set up CAs between containers. Because both Exchange Server 5.5 and Win2K use a directory structure, this migration uploads objects from one container inside one directory to another container inside another directory. Thus, first decide how you want to manage your users, DLs, and custom recipients in Win2K, then map your Exchange Server 5.5 recipient containers and subcontainers to your Win2K containers. This process will help you plan your CAs.

In summary,

Installing the ADC
To install the ADC, you need Win2K Server, Exchange Server 5.5 Service Pack 2 (SP2) or later, LDAP 3.0 (which Microsoft includes with both Exchange Server 5.5 and Win2K), and the ADC. You can obtain the ADC from the ADC folder in the Exchange 2000 beta 3 CD-ROM. The software versions I used for this article are Win2K (the release to manufacturing—RTM—version), Exchange 2000 beta 3, and Exchange Server 5.5 SP3.

You install the ADC from the Exchange 2000 CD-ROM. During the ADC installation, the software prompts you to choose the Microsoft Active Directory Connector Service Component, the Microsoft Active Directory Connector Management Components, or both.

Choosing the Microsoft Active Directory Connector Service Component installs the ADC service (adc.exe). Selecting Microsoft Active Directory Connector Management Components installs the ADC snap-in in a separate Microsoft Management Console (MMC).

The software doesn't force you to install the ADC service to install the administration snap-in, but if you install the service without installing the snap-in and you attempt to open the ADC administration tool, you'll receive an error message stating the ADC service has not been installed. I recommend installing both components.

Next, the installation asks for a location for the installation files. The default location is C:program filesMSADC. Move this location only if your C drive is near capacity or if you've designed your server to hold all applications that install in the Program Files directory on a different partition. Next, the wizard asks for the account name and password under which you want the service to run. Consider using your Exchange service account for this activity. The final screen asks you to finish the installation.

Note that after you've migrated all your Directory information to Win2K and fully implemented Exchange 2000, you'll no longer need the ADC. If you choose to uninstall the ADC service, you must delete all the CAs you defined on the local server before Win2K will let you remove the ADC service.

Configuring the ADC
After you install the ADC, you must create the primary CA. Navigate to the AD Connector Console on your server name, select New, then choose Connection Agreement. You need to name your CA. As you see in Screen 1, I named my CA From Maple Grove because my Exchange Server 5.5 server is in the Maple Grove site; the server that will run the CA is VANCOUVER. (Using the site name instead of a server name is better because you make CAs between sites and the AD.) I also selected From Exchange to Windows because I wanted to continue to administer my Exchange Server 5.5 server with Exchange Administrator and replicate new or modified objects to my Win2K domain controller.

On the Connections Tab, which Screen 2, page 4, shows, I configured the Connect as values for each server because these two servers are in different domains. If you're running Exchange Server 5.5 on a Windows NT 4.0 server, be sure to specify the domain name in front of the NT 4.0 username that you use to log on to the domain (i.e., domain nameusername). If you don't specify the domain name, you'll receive an 8026 error message in the NT Event Viewer application log informing you that the bind was unsuccessful.

Port 389 is the default value for LDAP services and for connecting LDAP clients to the Exchange server. However, if your Exchange server is running on a Win2K server, you need to reconfigure the LDAP port numbers because during the boot process AD components always start before Exchange services. Therefore, the Win2K OS locks port 389 for its use. In this situation, the Exchange Directory starts, but it can't perform LDAP communications over port 389. To work around this problem, use Exchange Administrator to reconfigure the LDAP listening port. Go to the LDAP Site protocols container to enter the port number you want, then set the CA port number on the ADC to match. As Screen 3 shows, I chose port 390, which is the usual alternative setting.

You configure the replication interval on the Schedule tab, which Screen 4 shows. However, be aware that with the ADC, the Always setting means every 5 minutes, not every 15 minutes. This shorter interval allows better alignment with intrasite directory replication. You can also force the entire directory to replicate the next time the software runs the agreement, whether it runs on a predetermined schedule or whether you select the Replicate the entire directory the next time the agreement is run check box on the Schedule tab. This choice sets the msExchServerXHighestUSN attribute to 0 and the ms-ExchDoFullReplication attribute to True for the CA. If the directories have discrepancies, the ADC service will replicate the objects as appropriate. If the objects are consistent between directories, the service won't replicate them again.

The From Exchange tab lets you specify the containers and objects in your Exchange site to replicate and the Win2K containers that will hold those objects. Screen 5 shows how you set this function. In Screen 5, I'm replicating the default recipients container in the Maple Grove site (ou=Maple Grove; o=USTRAINING) to the default users container in the nwtraders.msft domain (CN=Users;DC=nwtraders;DC=msft).

By default, each Exchange site has one recipients container. If you've created multiple containers under the recipients container, you have several options for replicating your objects to Win2K. If you want to retain the same container structure in the AD, create one CA and choose the Exchange site as the source container. AD will automatically create the same container structure in its directory and populate it accordingly. If you want to consolidate several Exchange containers into one AD container, create one CA and individually choose each of the multiple containers as the source and point them to the same AD container.

If you want to have complete control over each container (e.g., to have the mailbox container replicate every 30 minutes but have the custom recipient container replicate every 12 hours), create a separate CA for each container, specifying your source and target containers. If you want to change your structure entirely, you have two options:

On the Advanced tab, which you see in Screen 6, you need to configure several important values. First, in the Paged results area, you can change the number of entries per LDAP page. Under ordinary circumstances, you won't need to change these values. However, if your Exchange server is running on a Win2K domain controller, you might want to increase the number of entries per page because both the AD and the ADC will be using LDAP to send and receive queries. Paging improves performance by grouping together objects to be replicated before each replication request. Larger page sizes (i.e., more objects per page) require fewer LDAP requests to complete replication of all objects, but they require more memory to operate. Setting the page size to zero results in no replication; therefore, don't set the page size to zero unless you want to disable the CA.

The check boxes for configuring primary agreements are important, and you need to configure them carefully. The This is a primary Connection Agreement for the connected Exchange organization option is the default. A nonprimary CA doesn't create new objects in the Exchange Server 5.5 Directory but only replicates attributes between the Exchange Server 5.5 mailbox and its corresponding Win2K user object. Furthermore, if the CA is nonprimary, the CA establishes replication only if you've designated a Primary User Account on the mailbox's General tab. If no corresponding Win2K user object exists, a non-primary CA won't attempt to create the object.

Having multiple primary CAs from one AD container to multiple Exchange Server 5.5 sites means that each new object you create in the AD container will replicate to each Exchange Server 5.5 site. This replication will create multiple instances of the same object in your Exchange Server 5.5 organization. If you want to create multiple CAs from the AD to the Exchange Server 5.5 Directory, the best practice is to set only one CA as primary and the rest as nonprimary. Clearing the This is a primary Connection Agreement for the connected Windows Domain check box on all but one of your CAs will configure only one CA as primary and the rest as nonprimary.

The most complicated scenario is if you need some objects that are created in the AD replicated to certain Exchange Server 5.5 sites and other objects created in the AD replicated to other Exchange sites. In this situation, you can create separate primary CAs from different AD containers to each Exchange site. Although this configuration increases the complexity of your ADC administration, it also lets you specifically target which AD objects are replicated to which Exchange site.

Associated with the This is a primary Connection Agreement for the connected Windows Domain check box is the setting for replicating a mailbox object that has no primary NT account. This check box controls whether an object is created in the Win2K domain if no user account match exists between the two directories. The drop-down list becomes unavailable if you clear the check box. The best practice is to use this setting if you need to migrate several mailboxes and you're sure that some of the mailboxes don't have user accounts in the AD.

Object Deletions and the ADC
The Deletion tab, which Screen 7, page 6, shows, lets you configure how you want the target directory to manage deleted objects in the source directory (i.e., AD or the Exchange Directory). In both scenarios, you can either delete the source object or preserve the source object but make a notation of the object's deletion in a file. For example, if you delete an object in the Win2K directory, you can specify that the object's counterpart in the Exchange Server 5.5 Directory be deleted or preserved with a notation in a Comma Separated Values (CSV) file. For example, you might want to preserve an object to use it again.

In my example, because this agreement is one-way, I can configure only the Exchange Directory portion of this tab. I can choose to either delete the Windows account or keep the Windows account and store the deletion list in a temporary LDAP Data Interchange Format (.ldf) file.

If you delete the object in either or both directories, the object will have a default tombstone timestamp. Tombstoning affixes a future date and time to an object after deletion so that all copies of the object in the Directory delete simultaneously. This practice prevents replication services from backfilling a deleted object into the Directory and presenting it as though it had never been deleted.

Remember that Win2K strips an object of its permissions after you delete it. If you think you might want to use the object again, keep the deleted item in the deletion list. However, the only way to remove those objects from the deletion list is to import those files and delete the objects through the importation process.

Setting the Default Policy for the ADC
By right-clicking the Active Directory Connector Management snap-in inside the MMC console, which you see in Screen 8, you can configure which attributes of each object you want to replicate to the other directory. As I mentioned previously, a nonprimary CA replicates only the attributes of an object to the other directory. This dialog box lets you choose the attributes you want to replicate.

Planning Is Key
The ADC is still evolving, so don't rush into deploying it. In the meantime, you can take time to learn about Win2K, the AD, and Exchange 2000 and plan how to implement your ADC. Planning will result in smoother, more efficient replication of your Exchange data. Spending more time on planning will save you many hours of troubleshooting and administration in the long run. For more information about the ADC, see Tony Redmond's Windows NT Magazine article "The Active Directory Connector" (January 2000).