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 \SYSTEM\CurrentControlSet\Services\MsExchangeDS\Parameters 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.