2.4 The Active Directory Connector

---

The Active Directory Connector (ADC) supports unidirectional or bidirectional directory synchronization between the Exchange 5.5 DS and the AD. Synchronizing the two directories provides the following benefits:

• You can manage objects from the AD and the DS through a single interface, either the Exchange 5.5 administration program or the AD Users and Computers console. You can update attributes of objects and the ADC will replicate the changes to the other directory.

• You can deploy Exchange 2000/2003 servers alongside the existing Exchange 5.5 (SP3 or later) infrastructure in a reasonably graceful manner.

• You can use the information held in the DS to populate the AD to allow realistic testing of replication topologies before you commence final deployment of Exchange 2000/2003. Table 2.6 lists how the ADC creates DS objects in the AD.

  Table 2.6: Synchronization between Exchange and the Active Directory

  Exchange 5.5	Active Directory
  Mailbox	User object (if the account can be mapped to a Windows 2000 domain) Disabled mail-enabled user object (if the account still resides in a Windows NT domain). You can also configure the CA to create a contact.
  Custom recipient	Mail-enabled contact
  Distribution list	Mail-enabled Universal Distribution Group

Bidirectional (two-way) synchronization is the most functional approach, and it achieves all the goals listed previously. Bidirectional synchronization means that you replicate information in both directions, so that the AD learns about mailboxes, custom recipients, and distribution lists held in the DS and vice versa. Bidirectional synchronization is likely to be the most common mode of operation unless you can move your Exchange 5.5 organization to Exchange 2000/2003 over a short period, such as a long weekend. This is certainly possible for small organizations but unlikely for large or distributed organizations.

Unidirectional (one-way) synchronization populates a directory on a one-off basis. For example, after you install the AD for the first time, the directory contains relatively little information. Unidirectional synchronization from a well-populated DS allows you to fill the AD with sufficient data to conduct realistic tests covering aspects such as intrasite and intersite replication. Because the information held in directories changes all the time, it is highly unlikely that you will use unidirectional synchronization for anything other than testing. In fact, Microsoft found that many administrators encountered problems when they attempted to deploy one-way replication, so this option is no longer supported in Exchange 2003.

Obviously, once you begin to migrate from Exchange 5.5 to Exchange 2000, users will depend on an accurate directory to be able to find their correspondents, including distribution lists. Without synchronization, the AD or the DS will only hold details of its own user communities. The ADC is not the only utility that you can use to synchronize DS data with the AD. Any LDAP-based synchronization utility (such as HP's LDSU) can read and write into the AD, so you can normally synchronize entries without recourse to intermediate load files. Load files are simple text files formatted in a particular manner to contain the information necessary to manipulate entries in a directory. Only Exchange 5.5 servers support the ADC, so if you have older servers, you must install at least one Exchange 5.5 server in every site to act as a bridgehead server between the site and the AD. The other servers in the site can continue running Exchange 4.0 or 5.0, but since you can only upgrade to Exchange 2000 from a server running Exchange 5.5, it is strongly recommended that you upgrade servers to Exchange 5.5 (with the latest service pack).

Figure 2.10 illustrates how DS objects from Exchange appear in the AD after replication. You can only map mailboxes to user objects if the ADC is able to resolve the name of the mailbox's primary Windows NT account against the AD. Two different versions of the ADC are available. Windows 2000 comes with a basic version, while Exchange 2000 has an extended version. Because you want to replicate more than simple user, group, and contact objects between the two directories, you must use Exchange's version of the ADC. Some deployments start with the Windows version, just to get the AD populated, and then upgrade to the Exchange version before installing the first Exchange 2000/2003 server.

Figure 2.10: Exchange 5.5 data replicated to the Active Directory.

The version of the ADC provided with Exchange 2003 is smarter and contains additional functionality. First, the ADC console contains some tools to validate a target Exchange 5.5 organization to ensure that replication is possible. Second, you can run an ADC Connection Agreement wizard to automate setting up new connection agreements. The wizard does not overwrite existing agreements and it is a useful tool in straightforward situations where you do not need any special processing, such as replicating specific objects to different target containers. However, because these situations exist and it is always good to understand the basic technology, we should consider what a connection agreement is and the function that it serves. Before proceeding to create any connection agreements, make sure that your account is a member of the Local Administrators group on the server where the ADC runs; otherwise, you will be unable to save or modify an agreement. See Microsoft Knowledge Base articles 267373 and 249817 for details.

2.4.1 Connection agreements

You have to configure the ADC with one or more connection agreements before the ADC can replicate information between the DS and the AD. A connection agreement (CA) defines details of the objects to be replicated across a particular link, as well as the type of connection, how the servers will authenticate to each other (see Figure 2.11), and details of the servers that will participate in the link.

Figure 2.11: Configuring a connection agreement.

A single ADC can support multiple connection agreements, so it is possible to build a hub ADC to provide a single point of replication between all the sites in an Exchange organization and the AD. It is also possible to create multiple connection agreements on an ADC to handle a single Exchange site. In this case, each agreement is likely to control replication for a different recipient container in the site. Obviously, if an ADC has to manage a number of connection agreements, it consumes more system resources and the overall synchronization environment is more complex.

According to Microsoft, no architectural restrictions exist on the number of agreements that a single ADC can support, but system resources become a practical constraint after 50 or so agreements. In situations where you need to run more than ten or so connection agreements, consider allocating a dedicated server for this work. Simplicity is better than complexity, and you should, therefore, approach ADC deployments with the aim of restricting the number of agreements in place to the absolute minimum.

Distributed Exchange 5.5 organizations with many sites may require multiple ADC servers, with the connections spread between the servers. Organizations that already operate central Exchange routing sites (usually around a hub and spoke network) find that the central site is a good location for synchronization.

Direct IP connectivity is required between the servers at either side of a connection agreement. This requirement will influence how many ADC servers you need to deploy within a company. As with a Windows site, you can describe an Exchange 5.5 site to an island of high-capacity bandwidth. The initial design might start with an ADC for each Exchange site, and then reduce the number of ADCs by reviewing where sufficient IP connectivity is available to allow an ADC to handle multiple Exchange sites. There is no penalty except additional management overhead incurred to operate multiple ADCs. However, it is best to keep the number of ADC servers to one per Windows domain to reduce management effort, complexity, and replication traffic.

You make the decision to make a connection agreement unior bidirectional when you create the agreement, as shown in Figure 2.12. You can change the agreement type afterward, so you can begin with a unidirectional load from the DS to the AD and then change the agreement to be bidirectional when you are ready to begin deploying Exchange 2000/2003 servers. However, as discussed earlier, Microsoft does not support one-way agreements, so it is best to configure all agreements as two way.

Figure 2.12: Determining the type of connection agreement.

In the Exchange 5.5 architecture, each site exercises full control over its own set of mailbox, custom recipient, and distribution list objects. During Exchange 5.5 replication, each site pushes details of its objects to other sites, and the replication mechanism only permits a single path of replication between sites to avoid the possibility of duplicate replication. You can see this restriction in action if you attempt to create a directory replication connector between two Exchange sites when Exchange already replicates the objects from the sites via an intermediate site. Exchange will not create the new connector, because it will create duplicate entries in the DS. Connection agreements follow the same principle, and a connection agreement must exist between an ADC and every Exchange site before full bidirectional replication is possible. Because a Windows domain "owns" its objects, you also need a connection agreement for each Windows domain if you want to replicate DS information into the domain. Companies that run large, multisite Exchange organizations therefore require multiple connection agreements, even if they only want to synchronize with a single Windows domain.

Figure 2.13 shows how to add the recipient containers from a single Exchange 5.5 site to a connection agreement. The ADC will not allow you to select containers from multiple sites, since it retrieves information about available containers from the Exchange server specified in the Connections property page (Figure 2.11). In this case, the ADC connects via LDAP to port 389 on the DBOIST-MSXCL server, located in the "NSIS European Messaging Team" site, so we can only see the three containers in the site.

Figure 2.13: Specifying target containers for a bidirectional connection agreement.

If you only want to populate the AD and do not care about subsequent updates, you can use unidirectional replication to populate the AD with data from many different Exchange sites. In this case, a single connection agreement is enough. Figure 2.14 shows how to add multiple recipient containers from different sites to a connection agreement for unidirectional replication.

Figure 2.14: Adding multiple Exchange sites to a connection agreement.

The nature of replication presents all sorts of interesting challenges. Large distribution lists that incorporate members from multiple sites are a good example. A distribution list becomes a Windows universal distribution group after ADC replication. It is quite conceivable that not all members of the list exist as AD objects, because they are still awaiting replication. The AD cannot add invisible members to the new group, so an obvious problem exists if you replicate a half-empty group back to the DS. If the DS then removed the members who do not appear in the group, the affected users would lose any of the benefit of their list membership (access to public folders, etc.). Fortunately, the ADC solves the problem by writing details of members that it cannot find in the AD into an attribute for the group called "unmergedAtts." This allows Exchange 5.5 to maintain its membership, and the AD can merge in the missing members as they appear through replication.

Operating in a mixed-mode Windows domain also affects distribution groups. Universal security groups are not supported in a mixed-mode domain, so you can't use distribution groups to secure access to public folders on an Exchange 2000/2003 server in the same way that distribution lists are commonly used in Exchange 5.5. You will have to wait until you can move the domain to native mode before you can make the distribution groups into security groups. Alternatively, if it is going to be a long time before you can move a domain into native mode, you will probably end up creating separate universal security groups to protect public folders, and include users who have Windows accounts in these groups. This is one reason why it is best practice to use a native-mode Windows domain to support Exchange.

One-way synchronization is straightforward; bidirectional synchronization is quite another matter. The major gain that you can achieve through bidirectional synchronization is the ability to make changes to objects in either the AD or the DS and have the change replicated back to the partner directory. There is a certain attraction in the concept of being able to use a single utility, such as AD Users and Computers, to manage users, contacts, and groups-even if the actual object "belongs" to Exchange 5.5.

However, you have to offset the attraction of being able to manage everything from one place by the potential difficulties of managing synchronization across a distributed network. Bidirectional synchronization works best with strong centralized management models but exposes some weakness when exposed to more distributed models. Once you have more than ten sites, multiple recipient containers that require complex connection agreements, and potentially multiple servers running the ADC, it becomes easier to set up all the connection agreements to be one way. This method forces you to manage Exchange 5.5 objects through Exchange and Windows objects through AD Users and Computers. While this might seem to be a retrograde step, it is not a problem in practice. As always, this technique makes sense in some situations but not in others. Consider both approaches and select the one that is most appropriate for the way that your company is organized.

2.4.2 Handling multiple recipient containers

By default, Exchange creates a container called "Recipients" in every site to be the default repository for mailboxes, custom recipients, and distribution lists. Companies that deployed Exchange 4.0 often created new recipient containers to divide address types or to allocate separate containers for all objects that belonged to a specific department or function. For example, they would have a container to hold all distribution lists or all custom recipients, or one specially created to hold all the recipients that belong to departments such as "Marketing" or "Finance." Less commonly, specific recipient containers sometimes act as the target for synchronization from other directories. For example, you could use a container called "Lotus Notes Recipients" to hold the custom recipient entries created for people in the Lotus Notes address book via the Lotus Notes Connector.

Microsoft introduced Address Book Views (Address Lists in Exchange 2000/2003) in Exchange 5.0 to allow administrators to create virtual views of recipients taken from different containers and eliminate the need to create recipient containers for departments or functions. Nevertheless, many Exchange deployments operate multiple recipient containers, and this has an impact on how you will deploy connection agreements.

Assume that you have a site with three separate containers: the standard "Recipients" container; one called "External Contacts," which holds custom recipients outside the company; and a container for VIP users. If the intention is to synchronize the entries from all these containers to a single organizational unit in the AD, the task is simple, because a single agreement is able to handle the requests. It is feasible to consider a plan where the ADC synchronizes all objects to a single organizational unit initially, followed by some refilling to different organizational units after you complete the migration to Exchange 2000 and you only deal with AD objects. However, if the need is to immediately direct the information from Exchange 5.5 into multiple organizational units, you then need a different connection agreement for each organizational unit.

2.4.3 How the ADC performs synchronization

The AD and DS both store a set of attributes or properties for each object. Replication ensures that the same set of objects exists in both directories and that the same values are present in the objects' attributes. Whenever you have multiple directories and are able to change objects in either directory and depend on scheduled synchronization to match everything up, you cannot achieve a state of absolute consistency across the two directories. The aim is to maintain the two directories in as close a state of consistency as possible. The nature of networked systems and the experience gained with the DS since 1996 mean that it is reasonably easy to attain a state of loose consistency (the directories are 99 percent synchronized). Driving toward tighter consistency requires frequent synchronization across reliable network links.

When replication occurs from the DS to the AD, an LDAP query is executed to discover outstanding changes in the DS (how many changes have taken place since the last known USN). The ADC then examines each returned object. Incoming objects from the DS are examined to retrieve values from the DN, NTGUID, and PrimaryNTAccount attributes. The NTGUID is a unique numeric value, which serves as the key for the object within the AD, while the PrimaryNTAccount attribute holds the SID for the account associated with the mailbox.

Since the GUID is the primary key for the AD, the ADC attempts to use it first to locate the object. If this search fails, we know that the object does not exist under this GUID, but it may be present using another GUID. To check, the ADC searches using the DN against the legacyExchangeDN attribute. The legacyExchangeDN attribute holds the DN for the object in the DS, so a successful search will turn up DS objects synchronized into the AD, perhaps through another CA. If we still cannot find the object, the ADC performs a final search using the SIDHistory attribute to see whether the object's SID can be found. Failure at this stage means that the object does not exist in the AD, so the ADC creates a brand new object according to the CA policy (user, contact, or disabled user). If the ADC can find the object at any stage, the ADC updates its values.

Note that whereas the AD supports attribute-level replication, the DS performs replication on an object level. In other words, even if you change just a single attribute on an object in the DS, it replicates the complete object. Replication happens at the lowest common denominator, so the ADC replicates data between the AD and DS at object level.

The process is a little simpler when coming from the AD to the DS. The AD can contain many different types of objects, most of which are not supported by the DS, so the query to locate outstanding updates applies a filter to ensure that synchronization is only attempted with mail-enabled objects.

When the ADC synchronizes AD objects into the DS, they receive a DN stored in the LegacyExchangeDN attribute. The ADC can subsequently use the DN as the key for lookups into the DS. If the ADC can find an object with its DN, and its NTGUID value matches an AD object, the ADC knows that it has already synchronized and can update its attributes; otherwise, the ADC creates a new object.

2.4.4 Scheduling a connection agreement

As with an Exchange 5.5 Directory Replication Connector, a schedule controls how often the ADC activates a connection agreement to check for updates to replicate. As discussed earlier, a replicated directory is normally in a state of loose consistency. Synchronization achieves a similar state of consistency between two directories, and the frequency that synchronization occurs determines the exact level of consistency. In other words, the more often you synchronize, the closer the two directories become. The options in an ADC schedule are "Always" (which forces a connection approximately every seven seconds^[4]), "Never," or according to an exact schedule as set in the "Schedule" property page of the agreement (Figure 2.15).

Figure 2.15: Setting a schedule for a connection agreement.

Directories are often in a state of flux during migrations and their contents change more rapidly during periods when you move users from one environment to another. During migrations, you should schedule ADC connections to run very regularly, perhaps once per hour, and then tone back the schedule after the majority of users are moved to the new environment.

Determining a suitable schedule is, therefore, a balancing act between the need to replicate changes quickly and the desire to dedicate a reasonable amount of system resources to the job. Obviously, if you activate a connection agreement every ten minutes, the directories will stay in a higher state of consistency than a schedule that runs every two hours. However, the activation of each agreement generates some network traffic to allow the two directories to communicate to exchange updates. Operating a default schedule and allowing the ADC to check for updates at regular short intervals is not a problem when you have a few Exchange sites and recipient containers to process. However, in some of the larger and more complex deployments, which require bidirectional replication from 20 or 30 sites involving some degree of object remapping, you need to take care to ensure that the schedule for all the agreements managed by an ADC does not exhaust system resources. In these circumstances, you are more likely to end up with a situation where each agreement has its own phased schedule linked into an overall schedule that does not interfere with other agreements.

2.4.5 Primary and nonprimary connection agreements

You can set a connection agreement to be the primary agreement between an Exchange 5.5 organization and the AD or from the AD to an Exchange 5.5 organization. The default is for a connection agreement to be nonprimary. The difference is that a primary connection agreement is able to create new objects in its target directory, whereas a nonprimary agreement is only able to apply updates to existing objects. There should only be one primary agreement to any specific target within a directory, and, in this context, a target is defined as being from an Exchange 5.5 recipient container to an AD organizational unit or from an Exchange 5.5 site to an Exchange 2000 administrative group.

Two different options are available to control primacy. When the agreement has primacy "for the connected Exchange organization," it means that the connection agreement can create new objects in the DS. When the agreement has primacy "for the connected Windows domain," the agreement is able to create new objects in the target domain in the AD. The first connection agreement established by the ADC is always a primary agreement, because you always need at least one primary agreement for the ADC to operate.

The concept of primacy for a connection agreement is present to prevent the ADC from creating duplicate objects, because administrators create multiple agreements that channel objects from the same source into a directory. There should only be a single prime agreement between each AD domain and an Exchange organization. The exception to this rule is when an agreement handles a particular set of objects (such as only custom recipients) not covered by any other agreement. If there are multiple AD domains that need to synchronize with an Exchange organization, multiple connection agreements will be necessary, and one agreement for each domain will be marked as primary.

Before you begin replication, you should create a plan to identify all the different sources (sites and recipient containers on the Exchange 5.5 side and organizational units in the AD) and decide how best to connect the dots together.

2.4.6 Synchronizing multiple Exchange 5.5 organizations

Some companies find themselves in a situation where they are running multiple Exchange 5.5 organizations, perhaps after a corporate merger. In this situation, they can merge the Exchange 5.5 organizations together using the Move Server Wizard utility before proceeding to migrate to Exchange 2000/2003, or they can use the ADC to combine the directory entries from the different organizations together into the AD and use the AD as the basis for creating one logical organization.

Connecting multiple Exchange 5.5 organizations via the ADC takes some planning. For example, you cannot begin by creating an interorganizational connection agreement as the first connection agreement for the ADC, since this will prevent you from deploying a production Exchange 2000/2003 environment. The correct approach is to:

• Select the Exchange 5.5 organization that will be the "prime" migration path to Exchange 2000/2003. This organization will synchronize with the AD via normal connection agreements. All of the other Exchange 5.5 organizations will use interorganizational connection agreements.

• Use the version of the ADC provided with Exchange 2000 or 2003 and not the version shipped with Windows 2000, which does not support inter-organizational connections. Note that Microsoft provides an updated version of the ADC for Exchange 2003 and you have to update any existing ADCs that you established for Exchange 2000 by installing the new code from the Exchange 2003 CD. Apart from some bug fixes, the new version includes extra functionality in a set of ADC Tools that can automate the setup of connection agreements and the synchronization environment to a large degree. If you migrate from Exchange 5.5 to Exchange 2003 and use the ADC to synchronize information, the Exchange 2003 installation procedure expects you to run the ADC Tools before you can install an Exchange 2003 server into an Exchange 5.5 site.

• Configure the ADC with connection agreements to synchronize the primary Exchange 5.5 organization with the AD.

• When synchronization with the primary Exchange 5.5 organization is working properly, proceed to configure interorganizational connection agreements to incorporate the secondary Exchange 5.5 organizations. Figure 2.16 illustrates the creation of an interorganizational agreement.

  
  Figure 2.16: Configuring an interorganizational CA.

Synchronizing multiple Exchange 5.5 organizations into the AD is not a simple task. You should practice by configuring agreements in a test environment and check that everything works as expected before proceeding to implement inside your production systems. You should also test alternative solutions, such as synchronizing all of the directories into a metadirectory or using a purpose-designed synchronization tool such as HP's LDSU.

2.4.7 Site replication services

Site replication services (SRS) allow an Exchange 2000/2003 server to share configuration data with downstream Exchange servers in a mixed-mode organization. Essentially, SRS mimics the DS Service Agent (DSA) so that a downstream Exchange server views an Exchange 2000 server as if it is running Exchange 5.5.

SRS is closely associated with the ADC, which you must configure on the Windows server before an Exchange 2000/2003 server can join a downstream site. It is important to make it clear that SRS has nothing to do with the exchange of data between servers, since this is entirely a function of the connection agreements managed by the ADC. Instead, the SRS provides a shadow Exchange 5.5 DS to allow other 5.5 servers to continue with Exchange directory replication in exactly the way that they did before a server moved to Exchange 2000/2003.

During the installation process, setup automatically configures the connection agreements necessary to replicate configuration data. SRS is configured and becomes operational under specific conditions:

• When the first Exchange 5.5 server is upgraded to Exchange 2000 in an existing site

• When the first Exchange 2000 or 2003 server is installed into an existing site

• When you upgrade a bridgehead server in an Exchange 5.5 site- often, the bridgehead server is a good candidate for the first server for upgrade.

Once configured, SRS is then able to share data about Exchange 2000/ 2003 servers, all of which are fetched from the configuration naming context in the AD with all the downstream servers in the site. SRS consists of the following three major components:

• A pseudo Exchange 5.5 DS with its replication engine

• The Exchange 5.5 Knowledge Consistency Checker (KCC), a component similar to the KCC used in AD replication, which validates the replication paths between Exchange 5.5 sites

• The Super Knowledge Consistency Checker (SKCC), new code that is able to act as an interface between the Exchange 2000/2003 configuration data held in the AD and the legacy site topology used by the Exchange 5.5 servers. The SKCC is, therefore, able to produce a complete picture of a mixed-mode organization.

SRS maintains a copy of the directory in a database called SRS.EDB to track the interchange of configuration data between Exchange 2000/2003 and the legacy servers. RPCs always carry replication data between SRS and the downstream servers. Remember that you need to take regular backups of the SRS database, ideally on the same schedule as the AD. If you lose the server that hosts SRS, you will have to restore the database from backup, and it is obviously much better if you use a recent backup. The alternative is to rebuild the SRS database by following the instructions contained in Microsoft Knowledge Base article 282061, but a restore is usually faster.

You manage Exchange 5.5 servers through the ADMIN program and have to possess administrator permission for a site before you can work with servers in that site. After you remove the last Exchange 5.5 server in a site, its entry still exists in the configuration data held in the AD. To remove the server, use the technique documented in Microsoft Knowledge Base article 284148 to connect to the Exchange 2000/2003 server that hosts the SRS and delete the entry.

SRS is one of the Exchange components not supported on a cluster. From a planning perspective, this means that you cannot use a cluster as the first Exchange 2000/2003 server in a mixed-mode site, because this server must run SRS to act as a bridgehead server for the site. The simple workaround is to install a nonclustered server to host the ADC and SRS first, then the cluster, and then remove the initial cluster after the organization moves into native mode.

^[4] . The interval can be adjusted by setting the number of seconds in the Sync Sleep Delay value in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSADCParameters registry key.

---