4.3 Active Directory replication

---

Exchange information about users and resources must be replicated throughout the Exchange organization so that accurate information is available to every Exchange server and every Outlook user. Replication of the resource information is necessary for proper functioning of the Exchange infrastructure, and replication of the recipient names ensures that messages will be delivered to the correct mailboxes.

Directory replication has changed between Exchange 5.5 and Exchange 2000. The most obvious change is that Exchange no longer has a directory and is no longer responsible for replicating directory information; Active Directory has assumed that responsibility. The type of information that was previously stored in the Exchange 5.5 directory is now stored in the Active Directory.

Exchange 5.5 supported object-level directory replication. In Exchange 5.5, if you make changes to any attribute of a directory object, all attributes for the object—not just the changed attribute—were replicated to other Exchange servers. For example, if you changed the telephone number for a particular user, the user’s telephone number, display name, address, city, state, e-mail addresses, and all other attributes for the user object were replicated to other servers. With object-level replication, even minor changes to selected object attributes within the directory could cause significant network traffic.

Active Directory (and thus Exchange 2003) uses a per-attribute replication-mechanism. If you make changes to any attribute of a directory object, only the changed attribute is replicated. Using the same example as before, if you change a user’s telephone number, only the modified telephone number is replicated—not the entire user object. Per-attribute replication is more efficient and generates less network traffic than Exchange 5.5.

By default, objects within the domain naming context, such as user objects, are only replicated between DCs within the local domain. Selected object attributes from the domain naming context are tagged for replication to the GC. The GC is replicated to all GC servers within the Active Directory forest. This allows processes and users in all domains to access selected attributes that normally would not be replicated outside of the local domain. Table 4.2 includes some of the user attributes that are included by default in the GC. Notice that not all user attributes are tagged for replication to the GC. Additional attributes can be marked for GC replication using the Schema Manager MMC console.

The per-attribute replication mechanism and the use of the GC have some benefits for Exchange. They also affect some of the ways you may be currently managing your Exchange environment. Users, contacts, and groups are now objects that exist in the Active Directory rather than in a separate Exchange directory. The per-attribute replication means that you can make more frequent changes to object attributes without significantly increasing network traffic.

4.3.1 Synchronizing directory data between forests

A single Exchange organization cannot span multiple forests. If you have multiple forests, then you must have multiple Exchange implementations. It is best to avoid this situation, but that is not always possible. There are several legitimate business reasons that may force you to support multiple Exchange implementations for multiple forests. The most obvious reason is when two companies merge and both have already implemented their own separate Active Directory forests. There are also situations in which different divisions of the same company are legally required to maintain separate environments.

Unless you have an overwhelming business reason for implementing multiple forests, you should avoid doing so. Once you implement multiple forests, there are no automated tools for merging them.

If you find yourself unavoidably faced with multiple forests, you can create-manual trust relations between specific domains in the different forests. However, these are nontransitive trusts, which means you will have a domain model that resembles a Windows NT 4.0 environment, with multiple manual trusts between each domain.

You also will need to replicate data between the two separate Exchange implementations. Because the standard Active Directory replication process cannot span multiple forests, this replication must be done using other mechanisms. Several options are available for synchronizing multiple forests. Hewlett Packard’s LDAP Synchronization Utility and other third-party tools can be used for this purpose.

A Public Folder Interorganization Replication tool is included with Exchange. This tool can synchronize public folders between different Exchange organizations. The Public Folder Interorganization Replication tool also can replicate Free/Busy System folders, thus allowing users from different forests to schedule meetings with one another and look up free and busy times.

---