A consistent, automatically updated directory is one of Microsoft Exchange's major strengths. Exchange maintains the directory by replicating, or copying, changes in one server to other remote servers. (Figure 1 illustrates an Exchange hierarchy and defines Exchange's components.) Servers throughout an Exchange organization can see objects (i.e., connectors, mailboxes, email addresses, and public folders), regardless of the objects' physical location, as a result of directory replication. To take advantage of Exchange's directory features, you need to understand how the directory works and how to configure Exchange components across your enterprise for optimal performance.
Typically, a company has only one Exchange organization name. You can easily manage the hierarchy from one window via Exchange Administrator. Screen 1, page 12, shows an organization (Beyond Help), two sites (DAYTONOH and DOMAIN1), and one server in each site (SQUIRT and HECKLE, respectively). Directory replication lets the DOMAIN1 site see the objects in DAYTONOH.
Directory Replication
The Directory Replication Agent, a part of the Directory Service (DS), manages replication. Replication can occur within one site with multiple servers (intrasite) or in a multiple-site environment (intersite). Note that directory replication is not the same as directory synchronization, which is the ability to share address information with a foreign messaging system (such as Microsoft Mail).
Replication offers many advantages. For instance, replication lets mail administrators manage the entire Exchange organization from one seat (if they have access permissions). Replication lets clients see each user's email address (and other information, such as phone numbers) in the Global Address List (GAL). And replication lets each server know about the objects on other servers so a server can use those remote resources (e.g., connectors). This capability doesn't come without a cost. Directory replication consumes network bandwidth, which can become an issue if you replicate large amounts of directory data or if replication occurs often.
Replication Within a Site
In an intrasite environment, directory replication is automatic. Replication occurs by default every 5 minutes after Exchange detects a change in a directory object. The 5-minute replication delay, called replication latency, lets Exchange replicate changes in batches. If you want Exchange to replicate changes at longer intervals and therefore in larger batches, you can change the default delay from the Registry editor. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\MSExchangeDS\Paramters\ ReplicatorNotifyPauseAfterModify to change this value from 300 secondsto another interval. (Note: Changing Registry values incorrectly can prevent Windows NT or Exchange from starting.)
Here's how intrasite directory replication works:
- When someone changes a directory, the source DS notifies the other destination servers in the site.
- Each server and each object in a directory has an update sequence number (USN), and each change in a directory object modifies the object's and the server's USN. Each remote server in the site that receives the notification requests from the source DS just the changes it does not have. The remote server checks its update sequence number to find out which changes it needs. If the USNs are equal between the two servers, no replication occurs.
- The source DS uses remote procedure calls (RPCs) to connect to the destination DS and download the changes.
- The destination server then integrates the new objects into its hierarchy.
For example, suppose you add a few mailboxes on Server X. After 5 minutes, Server X begins notifying each server in the site that a change has occurred. Server X's DS waits 30 seconds after notifying each remote server so the remote post office can transfer the new objects into its hierarchy. This delay ensures that multiple simultaneous requests from the other servers in the site don't overwhelm the source server. This process continues until all servers in the site have the same directory. When all servers are finished replicating, every mail client in the site can see the new recipients in the GAL and send mail messages to these mailboxes.
Neither the Message Transfer Agent (MTA)—the Exchange service responsible for submitting, routing, and delivering messages—nor the Information Store (IS) participates in this transfer of directory information within a site. In other words, Exchange doesn't use any mail messages to pass data. The site service account validates the connection before the source server uses RPCs to transfer data.
Replication Between Sites
Intersite directory replication works differently from intrasite replication because all data transfer between sites must use the MTA. Instead of the servers' DSs talking directly to one another, Exchange first place directory objects in mail messages and then passes them to the MTA for deliver to the remote site.
Directory replication between sites is not automatic: The administrator configures it manually. Replication is a two-step process:
- Configure a messaging connector between the sites
- Configure a directory replication connector
Exchange needs a working messaging connector between sites to transmit messages between them. Think of a messaging connector as a pipe between the two servers in the different sites—like a string between two tin cans. The string is analogous to the connectors, and the cans are like the MTAs.
The four types of messaging connectors are the X.400 Connector, the Remote Access Service (RAS) Connector, the Site Connector, and the Internet Mail Service (IMS). Messaging connectors have both address space and cost values associated with them, and you must configure these properties to make them work properly.
A messaging connector's address space defines a path to the destination post office. Screen 2 shows the address space for the X.400 Connector between the SQUIRT and HECKLE servers. The address space gives the MTA the routing information necessary to transfer directory information between sites. You can view the address space for all the connectors by going to the Configuration display for the Exchange site and then selecting the Site Addressing property page.
Messaging connectors also have a cost value associated with them. Typically, the administrator assigns a cost value (an arbitrary number from 1 to 100) based on the monetary cost of the link. For example, if you have a T1 line, a microwave link, and a satellite link (in ascending order of monetary cost), you might assign the lowest cost to the T1 line and the highest cost to the satellite line. The lower the cost value, the higher the probability that Exchange will use that connector. Cost values let an administrator define primary and secondary paths for message transmission. Two paths are useful, because when a link goes down, the MTA can use the backup path to deliver the messages.
The local messaging connector must have some way of telling servers in remote Exchange sites that remote servers can use the local messaging connector to pass directory replication messages. When configuring the X.400 Connector, a RAS Connector, or an IMS between two sites, you need to configure the connector's Connected Sites properties page. This action ensures that both bridgehead servers know they are connecting to Exchange sites and can perform directory replication. Site Connectors don't have this tab because you can use Site Connectors only in an Exchange organization.
After you have installed a valid messaging connector between the servers in their respective sites, you need to configure directory replication connectors so the sites can replicate directory information. To set up the directory replication connector, you designate one server in each site to handle replication between the two sites. One local server functions as a bridgehead server to replicate changes from all the servers in that site to the bridgehead server in the remote site.
To create a new directory replication connector, go to Exchange Administrator and click File, New Other/Directory Replication Connector. Screen 3 shows the directory replication connector configuration parameters. The local site receives directory information from inbound sites, and the local bridgehead server sends directory information to outbound sites.
If you install the directory replication connector when the link is up and both sites are online, you can create the connector in both sites from one place. This method is the fastest and most foolproof. Alternatively, you can use a scheduled messaging connector, but if the link is currently not active, you must manually configure both connectors at their respective servers.
If a site is connected to multiple remote sites, the site can have more than one bridgehead server, but only one server in a site can be responsible for replication to another site. Figure 2 shows that Site 3 has one bridgehead servicing Site 2 and Site 4, whereas Site 2 uses two servers as bridgeheads (one bridgehead to connect to Site 1 and another to connect to Site 3).
If you configure all sites for directory replication, the number of directory replication connectors is always one less than the total number of sites, because you can't have two directory replication connectors from one site configured into two known (from the site's perspective) replicated sites.
In Figure 2, Site 3 pulls the directory objects from Site 4, then in turn Site 2 pulls directory objects from Site 3 and knows about objects in Site 3 and Site 4. When Site 1 pulls, it finds out about all three sites; Site 1 knows about the directory objects in Site 4 without having a directory replication connector directly configured between them. Site 1 and Site 4 have a transitive connection. If you try to configure a directory replication connector between Site 1 and Site 4 and Exchange is aware of the other directory replication connectors, Exchange won't let you configure the new connector. If you install all the directory replication connectors before Exchange knows about all the replication paths, directory replication won't initialize.
Intersite replication occurs every 3 hours by default. If you want to change this schedule, you can configure the interval manually from the Schedule tab of the directory replication connector. However, if you are using a scheduled messaging connector (RAS or X.400) for directory messages, ensure that your connectors' scheduled times match. If they don't, you might have directory service messages queue up in your MTA waiting for the next scheduled activation of the connector. This process can create unacceptable delays or, worse yet, undeliverable messages.
Routing Directory Replication Messages
Unlike the messaging connector property sheets, the directory replication connector property sheet has no address space (it has no cost value associated with it, either). This distinction is important, because without an address space, the directory replication connector can't transmit messages of any sort.
The messaging connector acts as the pipe; the directory replication connector just defines the bridgehead servers that will be receiving the directory messages. The MTA uses the address of the messaging connector as the path for the directory messages. Hence, the physical path the directory messages take can be any valid messaging route for reaching the destination bridgehead server.
In Figure 3, all one-headed arrows represent messaging connectors. Directory messages don't necessarily follow the physical path that the directory replication connector defined.
Exchange bases routing on total cost of all the messaging connectors added together, so the route can be an indirect path instead of one hop between bridgeheads. In Figure 3, the directory messages have three potential routes:
Option A: A direct path from Site 2 to Site 1, with a cost value of 9
Option B: From Site 2 to Site 5 to Site 4 to Site 1, with a cost value of 8
Option C: From Site 2 to Site 5 to Site 3 to Site 4 to Site 1, with a cost value of 7
During routing selection, the MTA selects the best connectors to use. Usually, the MTA selects the path with the lowest aggregate cost—the most indirect route (Option C in Figure 3). This example illustrates why mail administrators need to spend time planning cost values for their messaging connectors to ensure that the MTA will select the best route.
Putting It All Together
Here's how replication works when you have two sites with three servers per site. Figure 4 shows Site 1 and Site 2 configured with an X.400 messaging connector with a cost of 2 and a Site Connector with a cost of 1 between the sites; Server A and Server X are bridgehead servers. In addition, you have installed a directory replication connector between the sites.
Bridgehead Server A in Site 1 requests the directory updates from Bridgehead Server X in Site 2. The DS in the remote site compresses any new, deleted, or modified objects from all the servers in its site and submits it to the MTA. The MTA scans its routing table to determine which messaging connectors can route the message. Both messaging connectors pass this test. However, because the Site Connector has a lower cost value, the MTA selects it as the preferred connector. Next, the MTA creates an association between the two bridgehead servers and transfers the directory messages to Server A.
After Server A has received the messages, its DS integrates the directory objects into its hierarchy. For example, new mailboxes appear with any new public folders from the remote site, and any changes to connectors will also be visible in Exchange Administrator.
Next, intrasite replication automatically starts within 5 minutes and begins to update all the other server directories within Site 1 (i.e., Server B and Server C) until all objects are current within Exchange Administrator. The result is that all servers in Site 1 are now aware of Site 2. See the sidebar, "Troubleshooting Directory Replication," for some suggestions about solving some common problems administrators encounter with directory replication.
Sharing Information
Directory replication lets every server know about every other server so no Exchange server has to be a freestanding island of information. Exchange offers the ultimate flexibility in bringing as much information as possible to the client and server. And isn't that what messaging is all about?
