Exchange Directory Replication

Keep your directory up to date

Windows NT 5.0 administrators will need to understand Active Directory (AD) replication well to keep their networks running smoothly. Learning how Exchange replicates data to keep the Exchange Directory up to date across all the servers in an organization is good preparation for administering an AD network. Exchange's techniques aren't identical to AD's replication methods (and AD replication isn't complete), but many of the concepts that underlie Exchange replication underlie AD replication.

Automatic Replication Within Sites
An Exchange site is a group of Exchange servers that connect via a LAN-quality network. Administrators don't need to configure replication within sites; all the servers in a site automatically share Exchange Directory information. When you introduce a server to a site, Exchange immediately replicates the site's Directory to the new server, and Exchange replicates Directory changes to every server in a site.

Every Exchange server runs Directory Service, the service that is responsible for replicating Directory updates. Directory Service uses encrypted remote procedure calls (RPCs) to replicate intrasite changes, so RPC connectivity is a prerequisite for joining servers to create an Exchange site.

When you want to add a server to an existing site, use the rpcping utility (in the support directory on the Exchange Server CD-ROM) to test the server's ability to communicate with the site's existing servers. Don't try to add a server to a site if the site's servers don't respond to rpcping.

Rpcping probably won't work if you try to connect Exchange servers through a firewall. Exchange doesn't use a set of fixed ports for services such as the Message Transfer Agent (MTA), Directory, and Information Store. When an Exchange server receives a connection request from an RPC client, it redirects the request to the End Point Mapper, which forwards the request to the port Exchange has dynamically assigned to the service the client requires. Firewalls don't typically permit this sort of incoming connection redirection. To resolve this problem and learn how to set up Exchange to use fixed ports for RPC communications, review Microsoft Support Online article Q148732, "XADM: Setting TCP/IP Port Numbers for Internet Firewalls" (http://support.microsoft.com/ support/kb/articles/q148/7/32.asp).

How replication works. Every Exchange server has a Directory update sequence number (USN). When a user changes an object in a server's Exchange Directory, the server's USN increases by one. All the servers in a site maintain a record of the site's other servers' USN values. When a user modifies a Directory object, Directory Service waits for a period called the replication latency before advertising the change to the site's other servers. The default replication latency value, 300 seconds (5 minutes), works well. To change the interval, set the Replicator notify pause after modify (secs) value in the HKEY_LOCAL_MACHINE SYSTEMCurrentControlSetServicesMsExchangeDSParameters Registry key to the number of seconds you want the latency interval to be.

When the replication latency period has passed, the server's Directory Service sends out RPCs that notify the other servers of the server's current USN. Directory Service sends the notification RPCs to one server at a time and pauses for 30 seconds between RPC's to allow time for the recipient server to respond.

When one server receives a notification from another server's Directory Service, the first server compares the USN in the RPC with the USN it has stored for the machine that is advertising the change. If the RPC's USN is higher than the stored USN, the recipient server needs to update its Directory.

Directory Service on the recipient server sends a new RPC to the notification RPC's source server. The new RPC requests Directory updates from the source server. The source server responds to the update request by sending updates for all Directory objects that have higher USNs than the USN the requesting server has stored.

Exchange doesn't immediately update all of a site's servers when an object changes. This lag prevents replication data from swamping the network when users enter many changes in a short period. For example, you can use the Exchange administration program to import data from other messaging products' directories into the Exchange Directory. You can import thousands of data entries from a Comma Separated Values (CSV) file in a short period, and if your server generates a separate update notification for each imported object, your Directory migration's RPCs will swamp the local network. By accumulating Directory changes and sending update RPCs every 5 minutes, Exchange achieves a compromise between performance and Directory accuracy.

Directory attributes solve replication problems. On each server, an object's USN-Changed attribute holds the value of that server's USN at the time the object last changed. The USN-Changed attribute varies from server to server for each object, even when the servers' Directories are synchronized. An object's USN-Source attribute holds the USN value for the server (that the object last changed on) at the time of the change. An object's USN-Source attribute is identical on every server in the site when all the servers' Directories are synchronized. Screen 1 shows my mailbox's USN-Changed attribute. The mailbox's USN-Changed value is 330205.

Exchange uses three object attributes to resolve conflicts that arise when multiple users modify an object on multiple servers at roughly the same time. The Object-Version attribute tracks the total number of times that an object has changed. The DSA-Signature attribute holds a unique identifier that identifies which server an object last changed on. The When-Changed attribute keeps track of when an object most recently changed.

If a server receives two notification RPCs with the same Object-Version value but different DSA-Signature values, Exchange assumes that two servers updated the object at the same time. Exchange uses the two updates' When-Changed attributes to determine which Directory change occurred most recently, then accepts that update and ignores the other RPC. You must specify the /R qualifier when you start admin.exe to run the Exchange administration program in raw mode and see the Object-Version, DSA-Signature, and When-Changed values.

Other than adjusting the replication latency, you can do little to affect the flow of Directory data among a site's servers. Fortunately, Exchange's intrasite replication seldom provides any reason to interfere in the process. As long as all servers in your site are in the same NT domain and successfully communicate through RPCs, Directory replication works properly.

Connectors for Intersite Replication
You can add, delete, or modify Directory objects only when you're logged on to the object's home site. You must make sure Exchange replicates Directory changes among all your sites if you want to keep Directory information consistent throughout your organization.

Replication between Exchange sites does not occur automatically. Two basic rules govern intersite Directory replication. First, all replication data moves between sites via email. Second, Directory information from a site can follow only one path; you can establish only one directory replication connector connection between any two sites.

You must provide sites the capability to send messages to each other before you can establish Directory replication. Set up a site (RPC-based), X.400, or Simple Mail Transfer Protocol (SMTP) connector between the sites you want to share Directory information.

Unlike intrasite replication, in which every server communicates with every other server to exchange Directory updates, intersite replication requires each site to have a bridgehead server that acts as the site's Directory replication connection point. The bridgehead server periodically provides its site's Directory updates to other sites' bridgehead servers, collects other sites' Directory updates from their bridgehead servers, and distributes other sites' updates to the servers in its site via intrasite replication. Bridgehead servers exchange Directory updates through messages addressed to the recipient servers' Directory Service.

Screen 2 shows eight directory replication connectors in the Dublin site of a large Exchange organization. Each directory replication connector connects Dublin to another site. Screen 3 shows the properties of the directory replication connector between the organization's Dublin and Melbourne sites. DBO-EXCHANGEIST is the Dublin site's bridgehead server, and ECC is the Melbourne site's bridgehead server.

If you use a site messaging connector, you can configure your directory replication connector in one operation. However, if your directory replication connector will use an X.400 or Internet connector to convey replication messages to other sites, you must configure it separately on both sides of the connection. X.400 and Internet connectors usually join sites across slow or extended network links, or sites that reside in different NT domains. RPC connectivity isn't usually possible in such circumstances, so administrators in two such sites must work together to establish Directory replication between the sites.

Screen 4 shows the New Directory Replication Connector dialog box in which I configured a directory replication connector that uses an X.400 messaging connector. I selected No, the remote site is not available on this network to tell Exchange that remote administration isn't feasible over my site's messaging link.

When you configure a new directory replication connector, Exchange inserts a stub for the remote site into the Directory. Later, Directory Service on the bridgehead server requests information from the remote site about the site's configuration, servers, mailboxes, and custom recipients and imports that data into the local Directory. You can't view details about the remote site until the backfill process completes. The process can take a long time to complete in large organizations with a large Directory.

For example, a 15-site organization with 25 servers that host 16,000 mailboxes and custom recipients requires an approximately 46MB Directory. If network links between this organization's sites are slow, transmission of Directory data will take a long time­it might take days if links are slow or congested. For this reason, I recommend joining sites during weekends, when network traffic tends to be slowest.

If you establish Directory replication between sites that connect via extended network links, you might want to build and configure servers at a central location, perform the initial Directory replication across a LAN, and ship the servers to their final destination with the Directory installed. Such an installation requires you to replicate across your slow connections only changes that occur between the time you loaded the Directory on the server and the time you reconnect the server to the network.

Don't mess with directory replication connectors. The Exchange administration program makes creating and removing directory replication connectors easy. However, this fact doesn't mean that you can establish and remove connectors in a live environment without much forethought. When you remove a directory replication connector from a site, Exchange removes from the local Directory all objects that the directory replication connector has imported from remote sites. If you later establish a directory replication connector between the same two sites, Exchange must again transfer all of both sites' objects across the network.

This transfer process generates a huge amount of extra network traffic, and removing connectors can complicate the ownership of public folders. You can run the DS/IS Consistency Adjuster to re-home public folders after you remove a directory replication connector so users in both sites can continue to access the folders. However, if you reconnect the sites, the public folders will conflict, and the folder's original owner might lose rights to the folder. For more information about this problem, see Microsoft Support Online article Q156705, "XADM: Site Tear-Down Causes Public Folders To Be Re-Homed" (http://support.microsoft.com/support/kb/articles/q156/7/05.asp).

Take care to establish directory replication connectors correctly the first time. Give decisions about removing directory replication connectors a great deal of thought unless you want to permanently remove a site from your organization.

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.