Establish transitive connections. Sites don't need to connect directly to share Directory data. Two sites can exchange Directory information through a directory replication connector on a third site.
Screen 5 reveals details about Dublin's DRC NSIS Malaysia directory replication connector. DRC NSIS Malaysia connects the Dublin site to a site in Kuala Lumpur, Malaysia. The list of outbound sites specifies which sites' Directory information this directory replication connector transfers from Dublin to Kuala Lumpur. Because the Dublin-Kuala Lumpur connector hosts Directory data for many other sites, you can assume that Dublin is a hub site for this Exchange organization. Screen 5's list of inbound sites specifies which sites provide Directory information to Dublin through this connector: Kuala Lumpur and Tokyo. The Kuala Lumpur site connects directly to Dublin. Tokyo connects to Kuala Lumpur, and Kuala Lumpur forwards Tokyo's replication messages to Dublin.
The connection between Dublin and Tokyo is transitive. Kuala Lumpur acts as an intermediary between the two sites. Transitive Directory connections are common in hub-and-spoke networks. If you use transitive connections between sites in your organization, be careful when you make changes to intermediate sites, because a change to an intermediate site might affect many other sites. For example, if I remove the directory replication connector that connects Dublin and Kuala Lumpur, the Tokyo site no longer has a connection to Dublin or any of DRC NSIS Malaysia's outbound sites. Keep a chart that depicts all your organization's directory replication connectors so you understand how Directory information flows between sites and what effect removing a directory replication connector will have on your site.
Carefully schedule replication. Your intersite replication schedule is important. Exchange doesn't support field-level replication. When a user changes an object in the directory, Exchange replicates the object's complete content to other servers, so replication can create a significant workload on a network. You don't want to replicate changes so often that replication messages compete with interpersonal messages for network bandwidth. But, you want to maintain an up-to-date Directory at all your sites so users don't address messages incorrectly.
Some companies perform Directory replication only at night to keep the network free for other work during the day. Other companies update directory data hourly during the day to ensure that the replication process circulates new information throughout the company as quickly as possible.
Every company is different, so one type of schedule doesn't work for every firm. Even within a company, a replication schedule changes as an Exchange deployment progresses. For example, as you migrate from other messaging systems to Exchange, the Directory constantly receives updates because you are introducing new entries regularly. When the migration finishes and everyone has an Exchange mailbox, you need to update the Directory less often, and you can throttle the replication schedule.
Don't get so enthusiastic about replication that you set a schedule that generates thousands of replication messages daily. When your network is running smoothly, you might not notice heavy replication activity, but when a messaging connector or other network device has a problem, replication traffic will build up in large MTA queues and increase the transfer time for interpersonal mail across the network.
I always specify a replication schedule for my connectors. The default replication interval, 3 hours, is acceptable in many circumstances, but I like to create my schedule because doing so forces me to consider the time during the day when the directory needs updating and what effect replication will have on my network. Screen 6 shows the replication schedule for Dublin's directory replication connector to Utrecht, Netherlands. I set the grid to 15-minute increments rather than the default hour increments, because when you select an hour period for replication, Exchange sends replication messages every 15 minutes during the hour.
Replication Between Organizations
Exchange provides no automatic method for sharing information between organizations. The Directory doesn't let organizations join to form a super-Directory in the way that X.500 permits chained directories.
To replicate Directory information among Exchange organizations, you must use a method for directory import and export operations. These methods range from manually exporting CSV files from one organization's Directory and importing them into another organization's Directory to using tools such as Inter-Org Directory Synchronization, which comes in the Microsoft BackOffice Resource Kit or commercial products such as Compaq's LDAP Directory Synchronization Utility (LDSU).
Replication Analysis
Exchange Directory replication isn't a black art. It's not at all mysterious if you have good messaging connectivity and knowledge of how directory replication connectors work. If you need to analyze intersite replication problems, you can find replication-related event log entries by their reference to the directory replication agent (DRA). The DRA runs as part of Directory Service, generating and processing replication messages.
Now you can look forward to AD and hope Microsoft has learned lessons from administrators' experiences with Exchange. If it has, AD is sure to be a success.