Previous Page TOC Next Page



— 15 —
Configuring Directory Replication


by Kimmo Bergius

A Microsoft Exchange organization is a collection of servers and sites that share the same directory. A Microsoft Exchange directory is an X.500-based database that contains information about the objects within an Exchange organization. All of the servers within a site and within an organization contain practically the same objects and information. All the directories are equal, with none of them being the master directory. The Exchange directory architecture is based on a multiple master directory model.

The service that maintains the directory is called the Directory Service (DS). This service is also responsible for replicating changes to other servers.

In order to update and maintain all the directories within an organization at the same level, Exchange utilizes a feature called directory replication. Replication means that changes made to one of the directories will be replicated—that is, copied to other servers. Directory replication is done using two different methods within an Exchange organization: the first method is used within a site and the second between sites. Replication within a site is called intrasite replication and replication between sites is called intersite replication.

When you have installed the first server into a site, directory replication to the other servers within a site is configured automatically during the setup of the second and subsequent servers in the same site. Directory replication between two sites has to be configured manually by the administrator after the messaging connector connecting the two sites has been configured (see Chapter 14, "Connecting to Other Exchange Sites").

Directory Replication Within a Site


The Directory Service (DS) takes care of directory replication between servers in a single site. The DS on one server uses remote procedure calls (RPCs) to communicate directly with the DS on another server.

Directory replication between two servers in the same site is configured automatically when you install a new server to an existing site. The automatic configuration is done during the installation program and is based on the name of an existing server that the administrator supplies during the installation (see Figure 15.1).

Figure 15.1. Entering information about the existing server.



There are two main reasons why the installation might fail:

  1. The user supplies incorrect information for the Service Account. This will prevent the startup of the local Exchange services and will also prevent the DS from connecting to the existing server if you are installing a server to an existing site.

  2. Server TCP/IP settings are incorrect (you have not specified the correct information in the Network program under the Control Panel) or the information contained in the DNS server is incorrect.



If setup fails, please confirm first that you have specified the correct information for the Service Account, and then that the TCP/IP settings in the local server and on the DNS server are correct.

After the installation program has finished copying the necessary files onto the server, it will start the core services. The DS on the new server connects to the DS on the existing server and adds itself to the existing server's directory. Then the DS downloads a partial copy of the contents of the directory database from the existing server. This partial copy contains all other objects except the recipients. The recipient information is not downloaded because it can take a considerable amount of time and the installing administrator probably would not like to wait for hours for the installation to be completed. A complete copy of the directory is replicated to the new server when it is started for the first time after installation.

Knowledge Consistency Check (KCC)


All the servers within a site maintain a list of servers that they should replicate information to (REPS-TO) and a list of servers they should receive replicated information from (REPS-FROM). These lists are used during the replication process to verify that the updated directory information is sent to all the servers within the site. All of the servers should maintain an up- to- date list of the servers within a site. To check the validity of the lists, a server uses a function called Knowledge Consistency Check. There are actually two different processes within the KCC:; one used to check knowledge on servers in the local site (intrasite KCC) and the other to check knowledge of other sites (intersite KCC;, see "Directory Replication Between Sites" later in this chapter).

During a KCC, the local server checks the lists for servers within its own site that it is aware of and then connects to the other servers one by one. After a connection to a remote server has been established, the local server checks that its own REPS-TO and REPS-FROM lists contain the same servers as the lists on the remote server. If the lists do not match, the local server adds the new information into its own lists. Then the local server will establish a connection to the next server it is aware of and so on, until it has checked the REPS-FROM and REPS-TO lists against the lists on all other servers within the site. When the lists are Up-to-date they can be used as server lists for directory replication, and thus confirm that all updates in the directory will be replicated to all servers within the site.

By default, the KCC is run once every day, but you can run it manually by selecting Check Now in the Directory Service property window under the server container (see Figure 15.2). You should run the KCC manually only if you want to speed up the process of identifying new servers within the site or if you suspect that something has gone wrong with the normal directory replication.

Figure 15.2. Running the Knowledge Consistency Check manually.

Directory Replication Within a Site


When you make a change to the directory on one server, that particular server (server A) is responsible for replicating the change to the other servers within the site. After the change has been committed to the directory, server A waits for a certain period of time, called the directory latency time, before it starts replicating the change to the other servers. This delay will force the DS to wait for any other updates and then replicate them all at the same time. The latency time is defined in the registry, and can be changed using the NT Registry Editor, but generally there is no reason to change the time.



Because of the replication latency time, updates to a particular server will not be effective in other servers right away. You should be aware of this and allow some time for directory replication to work, before starting to wonder why replication or the system in general does not work properly. An Exchange administrator's most valuable asset is a lot of patience!

After the latency time has expired, server A checks the REPS-TO list and establishes a connection to the first server on the list (server B) to inform that a change has occurred in the directory on server A. After this, server A waits for a specified time, called the replicator notify pause, before informing the next server of the change to give server B enough time to get the updates from server A.

When server B is informed by server A that a change has occurred in server A's directory, it will check in its own directory for the latest change it has received from server A. This check is done using update sequence numbers (USN). Each object in the directory has a USN and each server also has a USN. When you change an object in the local directory, the change will set the object's USN to a number that is the server's USN + 1, and then increment the server's USN by one. Additionally, each server in the site maintains a list of all other servers and the corresponding USN's, that were valid during the last directory replication from the particular server.

When server A informs server B of changes in its local directory, it will also send server B its own server USN. Server B will then compare this to the list it maintains on other servers in the site, and will request from server A all objects that have a USN bigger than the one saved in its own list. The request is sent to server A; the DS on server A establishes a connection to the DS on server B, uploads the requested information, and updates its own USN on the list on server B. Now all objects on server A with a USN equal to or smaller than the server USN have been replicated to server B.

Figure 15.3. Replication within a site.

When you delete an object from the directory the directory creates a tombstone out of the deleted object. A tombstone is a special object in the directory containing information on the deleted object. The tombstone object has a normal USN and is replicated like any other object. When another server receives the tombstone object, it will delete the object contained in the tombstone from its own directory.

All these complicated functions ensure that the directories on all of the servers within a site are kept up-to-date. The functions also ensure fault tolerance. When new servers are added to the site, one of the existing servers is informed about the new server, which starts directory replication immediately to the new server. Through the Knowledge Consistency Check knowledge of the new server will be propagated to other servers within the site. Furthermore, the USN's ensure that all updates will be replicated to all servers within the site. Even if a server is down for a long period of time, it will receive all updated information as soon as it comes back up.

Directory Service Site Configuration


One of the first things you should configure after you have installed the first server into a new site is the DS Site Configuration. This object can be found under the site's Configuration container, and it contains two settings that affect directory replication; the Tombstone lifetime and Garbage collection interval (see Figure 15.4).

Figure 15.4. The DS Site Configuration Properties window.

Tombstone lifetime defines the time that tombstone objects (deleted objects) are kept in the directory. By default the time is 30 days. You should define a time long enough so that the tombstone object (and thus the deletion of an object) can be replicated to all servers within the organization. When a particular tombstone object expires, it is deleted from the directory during a function called the Garbage collection.

During Garbage collection, the Directory service deletes all expired tombstone objects from the directory and then defragments the directory database (also known as the online defragmentation of the database). This defragmentation frees all space used by the expired tombstones and marks the space free to be used by other objects. The online defragmentation does not decrease the size of the database file. You can also manually run an offline defragmentation on the database files, which will free the space and also decrease the size of the database files (see chapter 20, "Maintaining Exchange").

Configuration of Directory Replication Within a Site


Even though directory replication within a site is configured and run automatically, there are a few settings affecting replication that you should be aware of. Most of these settings can't be set through the administration program, but rather are set in the NT Registry.



If you are not sure how to change the settings in the NT Registry or are unsure about the effects of a particular change, do not change the settings. A faulty setting can prevent NT or one of the Exchange services from starting.

All the Registry keys that affect the Directory Service and replication are located under the following subtree (see Figure 15.5):


HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDS\

Figure 15.5. Directory Service parameters in the registry.

In general, you do not need to change the values of the registry keys. You can, however, use them to locate the directory files and fine-tune your environment.

Directory Replication Between Sites


Replication between two sites is different from replication within a single site. The Directory Service on one server does not communicate directly with the DS on another server. Instead, the replication information is passed between the sites as normal e-mail messages by a messaging connector. You need to configure a directory replication connector between two sites to take care of creating the replication messages and passing them over to the messaging connector and on to the other site. Furthermore, you can define a schedule for replication, which cannot be done for replication within a site.



Before you configure a directory replication connector between two sites, you have to configure a messaging connector (see Chapter 14) and make sure that the connector works, i.e. that you can send normal e-mail messages over the connector. You can check the operation of a messaging connector by sending mail to a user in the other site using the user's full X.400 address. Once the messaging connector works you can go on to defining the replication connector.


Replication Bridgehead Server


The servers within a site do not replicate their own changes to all the other servers in the other sites in the organization. When you configure the replication connector between two sites, you also select one of the servers in each of the sites to take care of replication between the sites. These servers are called directory replication bridgehead servers. All other servers within a site replicate the changes to objects in their directories to the bridgehead server normally using the method for intrasite replication. The local bridgehead server is responsible for replicating the information to the specified replication bridgehead server in the remote site. Only one server in a site can be responsible for replication to another site. There can be multiple bridgehead servers within a site, if the site is connected to multiple remote sites. One server can, however, be responsible for directory replication to several different sites.

Contrary to messaging connectors, you cannot have two directory replication connectors between two sites. Furthermore, the directory replication connections are transitive, which means that you do not and can not have two different replication paths between two sites. Consider an example of three sites: A, B, and C. You define a replication connector between A and B and A and C. After this you cannot configure a further replication connector between sites C and B, because there already exists a replication path from B to C via A (see Figure 15.6).

Figure 15.6. Directory replication links between sites.

At a quick glance this would seem like a bad thing, considering fault tolerance. The replication connectors are, however, just a definition that defines which server is responsible for creating the replication messages and to which server in the remote site they are sent to. The directory replication information is sent as messages using the normal messaging connectors between the sites, of which there can be several. This provides fault tolerance and on the other hand simplifies configuration, because the defined message transport paths are used for all communication between sites—even directory information. The route for a replication message is chosen exactly the same way as the route for a normal, interpersonal mail message.

Replication Connector Topology


The basic rule applied to configuring messaging connectors can also be applied to configuring directory replication connectors: you should try to minimize the amount of hops that replicated directory information has to make from any source to any destination. The directory replication connector topology in an organization does not have to be exactly the same as the messaging connector topology, but usually this makes life a lot easier. For example, you could configure a directory replication connector between two sites, even though these sites have not been directly connected using any messaging connector. This would, however, mean that the directory replication messages between these two sites (as well as normal message traffic) would travel via a third site.

Consider the following example: You have an organization with four sites, A through D (see Figure 15.7). The ideal configuration for directory replication information would be to choose one of the sites—for example site A—to act as a "hub" for directory replication. This means that you would define three directory replication connectors: A to B, A to C, and A to D. In this configuration, any replicated directory information would have to travel over two hops at the most.

Figure 15.7. Directory replication links between four sites.

Before configuring the directory replication connectors within an organization, you should always consider the way the messaging connectors are configured. Consider again the example in Figure 15.7. What if the sites are connected into a chain using site connectors, A to B to C to D? If you configured the replication connectors in the already mentioned way (A to B, A to C, and A to D), the replication of a change in a server in site D to a server in site C would mean that the bridgehead server on site D would create a directory replication message and send it first to site A. The message would travel over three messaging connector hops. Then the bridgehead server on site A would then create another replication message and send it to the bridgehead server on site C, and the message would travel over a further two messaging connector hops (see Figure 15.8, example 1). Thus, the replication process would load the system unnecessarily.

If you instead defined the replication connectors similarly to the messaging connectors, A to B, B to C, and C to D (see Figure 15.8, example 2), the furthest a replication message would have to travel is three messaging connector hops (from D to A). Directory replication would not load the system as much as in example 1. The directory replication schedule for the different bridgehead servers is critical in this configuration (see "Directory Replication Connector Schedule" later in this chapter).

Figure 15.8. Directory replication links and messaging connectors.

To summarize, there are two rules to designing a directory replication topology:

  1. Minimize the amount of hops directory replication messages have to be transported over.

  2. Consider the underlying messaging-connector topology.


Connected Sites


If the messaging connector used to connect the two sites is an X.400 Connector, Dynamic RAS Connector, or the Internet Mail Connector (for more details on the different connectors, see Chapter 14), you will have to define the remote site in the connector's Connected Sites property page. Otherwise the replication connector will not be able to use the messaging connector to transport the replication messages. Only the site directly at the other end of the messaging connector has to be defined on the Connected Sites page (see Figure 15.9). The DS will get information on all other sites within the organization through the Knowledge Consistency Check. You do not have to define the connected sites for the site connector, where this information is configured automatically.

Figure 15.9. The Connected Sites property page.

Configuring the Directory Replication Connector


Configure the Directory Replication Connector between two sites by doing the following steps:

  1. Select New Other from the File menu, and then Directory Replication Connector. If you are not in the Directory Replication container under the site configuration container, the Administrator program will ask whether you want to switch to this container. Select Yes.

  2. The New Directory Replication Connector window appears (see Figure 15.10). This window lists the sites for which you can configure a new directory replication connector. Type the name of the server that is to be used as the replication bridgehead server in the remote site.

  3. Figure 15.10. The New Directory Replication Connector window.

  4. If you have an RPC-capable connection to the server in the remote site (for example, you are using a site connector) and your user ID has administration rights on the remote server, you can choose to configure a replication connector to both servers at the same time. In such a case first select Yes, the remote site is available on this network, and then configure both sites. The Directory Replication Connector Properties window appears (see Figure 15.11).

  5. Figure 15.11. The Directory Replication Connector Properties window.

  6. The program will show a default directory and display name in the appropriate fields. You can change these names if you wish. Use a name that will identify the remote site the replication connector is connected to.

  7. Go to the Schedule property page and change the replication schedule if necessary (see "Directory Replication Connector Schedule" later in this chapter). The default is that replication will occur every three hours.

  8. Choose OK.

If you chose to configure both sites in step 3, the Directory Replication Connector is now ready for use and directory replication between the two sites should start. If you didn't choose to configure both sites, you will have to perform steps 1 through 6 in the remote site as well, before the replication connector is properly configured.

Directory Replication Connector Schedule


Unlike directory replication within a site, replication between two sites can be scheduled. The schedule is defined using the Schedule property page (see Figure 15.12) on the Directory Replication Connector property window (the Directory Replication Connector object is located in the Directory Replication container under the Site Configuration container).



Delivery of the replication messages is dependent on the schedule of the replication connector and the schedule of the messaging connector transporting the replication messages. In a multisite organization, the messaging connector schedules should be considered when designing the replication schedules.

Figure 15.12. The Schedule property page.

You should consider the organization as a whole when defining the directory replication connector schedules. Consider the examples in Figure 15.8, example 2, an Exchange organization with four sites. If you schedule each of the directory replication connectors to replicate the information once a day, it might take three days to replicate a change to all sites within the organization. Of course, this configuration and delay in replicating the changes is perfectly OK, as long as all of the administrators are aware of the delay.

How Replication Between Sites Works


The basis of directory replication between sites lies in the intrasite replication within a site. All information regarding the site and the servers it contains is replicated to all of the servers in the site—and thus also to the replication bridgehead server responsible for replication between two sites. The bridgehead server will then replicate all changed objects on to the other site. Replication within a site must work properly so that the bridgehead server has a complete picture of the site, so that all information will be replicated to the remote site as well.

Directory replication between sites works on a pull basis. This means that the replication bridgehead server will request updated information from the remote site based on the defined replication schedule. The replication bridgehead server in the remote site never sends updates to the local site if it has not been asked to do so. The bridgehead servers use Update Sequence Numbers to determine which objects have been updated since the last replication, much in the same way as for intrasite replication.

During the configuration of the directory replication connector, basic information about the remote site will be added to the local directory. The Administrator program will show the name of the remote site and a Configuration container for the site. This information has to exist before any further directory replication can occur. The Configuration container for the remote site will, however, be empty and no actual configuration information for the remote site will exist at the local site.



When you configure a directory replication connector, the name of the remote site should appear in the administrator program within a few minutes. Sometimes it may happen that even after some time, no other configuration information will appear under the configuration container. This generally means that the messaging connector between the two sites is not working properly. If this is the case, check the messaging connector.

You can check where the directory replication messages are stuck by opening the Message Transfer Agent object under your local server name in the Administrator program and then opening the Queues page. The queue list will show all outgoing queues, including the one to the remote site. If the connector to the remote site shows items sent by the DS, the messaging connector does not work properly.


Depending on the schedule defined in the directory replication connector's Schedule property page, the local site might request all updated and new information from the remote site. The replication bridgehead server on the remote site will create a replication message containing the requested information and send it to the local bridgehead server. When the local server receives the replication message, it will be passed on to the local directory service, which will add the information to the server's own directory. Then the information about the remote site will be replicated on to the other servers in the local site, using the normal intrasite-replication method.

Now the local site has basically the same information as the remote site. In a multisite organization, the next step is the Knowledge Consistency Check. The KCC consists of two functions:, the intrasite consistency check, which checks that the local server knows about all the servers within its own site, and the intersite consistency check, which checks whether the information replicated from a remote site contains information about any other sites. If it finds information about a site it is not previously aware of, it will create a replication link to the new site and new site name, and an empty Configuration container will appear in the Administrator program. After this, the local site will start replicating information from the new remote site as well.

The KCC is run automatically only once a day, which might affect the time it takes for new sites and their information to appear in remote sites. You can force the server to run the KCC by opening the Directory Service page under the local server in the Administrator program, and clicking Check Now on the General page. This will run the KCC immediately and add knowledge of all new sites so directory replication can occur.

After the local server has received the directories from the local site for the first time, normal directory replication starts. At scheduled times, the replication connector will request information from other directly connected sites and will receive information on all updated objects.

Configuration Steps in a Multiple Site Environment


This example explains the replication configuration steps in an organization consisting of three sites:, A, B, and C. The sites have been connected so that sites A and B are connected via a site connector and sites A and C are connected using an X.400 connector over an X.400 backbone network. Furthermore, a backup connection has been defined between all the sites using the Dynamic RAS Connector. Because the main messaging connectors are configured so that message traffic flows through site A, this site will also be used as the "hub" for directory replication. All messaging connectors have been configured and tested. The next task is to define two directory-replication connectors.

Figure 15.13. An example configuration.

The directory replication connectors are configured by doing the following steps (all the configuration steps should be performed on the replication bridgehead server on each site):

  1. Define a directory replication connector from site A to site B. Because these sites are connected using an RPC capable link, we can configure the directory replication connector to both sites at the same time. Use the Always option in the replication connector's Schedule property page, so that replication will start immediately. When you look at the configuration on the bridgehead server on site A, it should show the name and an empty configuration container for site B and vice versa, and after a few minutes the rest of the configuration information should appear as well.

    Now site A has a full copy of site B's directory, and vice versa.

  2. Next define a directory replication connector between sites A and C. Because these sites are connected over an X.400 network, you will have to configure the replication connector separately to the bridgehead server in each site. Before you add the replication connector, check that the remote site has been defined in the local site's X.400 Connectors Connected Sites property page. Again, select Always for the schedule for the replication connectors.

    After a few minutes, the remote site name and configuration container should be seen in the Administrator program. After a few more minutes (depending on the X.400 Connector's schedule) the rest of the configuration information should be replicated.

    Now site A has a full copy of site B's directory, and vice versa. The next task is to make B and of C aware of each other.

  3. In site C, open the Directory Service object under the bridgehead server, and select Check Now on the General property page. This will run the KCC on site C. KCC will check the information received from site A and discover a new site—site B. KCC will then add the new site and a configuration container into the Administrator program and start directory replication to site B. After some time, complete information about site B will appear on site C.

  4. Now go back to site B and open the Directory Replication Connector object under the Directory Replication container. Open the Sites page, select site A from the Inbound Sites list, and select Request Now. A dialog box will appear asking for the request type. Select Update only new and modified items. This will request site A to send all new directory information to site B.

  5. After the directory replication has occurred, open the Directory Service object under the bridgehead server on site B and select Check Now on the General property page. This will run the KCC on site B. KCC will check the information received from site A and discover a new site: site C. KCC will then add the new site and a configuration container into the Administrator program and start directory replication to site C. After some time, complete information about site C will appear on site B.

    Now all the sites know about each other, and normal directory replication can start. You can now change the Replication Connector Schedule to the one you want to use normally.

In the preceding steps you used forced directory replication. Of course, you could just set the replication connector's schedule to whatever you want it to be and wait for replication to occur. Also, the KCCs on different sites will be run automatically and thus new replication links be configured. Forcing replication will speed the process and make it easier for the administrator to verify that replication works.

Forcing Directory Replication Between Sites


Normally, directory replication between sites occurs according to a schedule specified in the Directory Replication Connector's property window. You can, however, force directory replication to occur between two sites by opening the Directory Replication Connector's property window and selecting the Sites page (see Figure 15.14). This page will show all sites from which this replication connector should receive information and the sites where replication information should be sent via this site. You can manually request an update on a certain site's information by selecting the site in the Inbound Sites list and by clicking Request Now.

Figure 15.14. The Sites property page.

Removing a Directory Replication Connector


You might have to remove a directory replication connector if, for example, a site is deleted from the organization. The connector can be removed by simply selecting the right connector under the Directory Replication container and selecting Delete from the Edit menu (or by pressing Del).

After you have removed the connector, all information about the sites should be removed as well. This will be done automatically in time, but you can force it by running the KCC manually. After this, you should also run the IS/DS Consistency check that can be found on the General property page in the server's property window.

Summary


All servers within an Exchange organization share the same directory. In order to accomplish this, changes to the directory have to be replicated across the whole organization. This is accomplished by two functions, directory replication within a site and directory replication from site to site. The first function is automatic and requires no configuration from the administrator. The latter function depends on directory replication connectors configured on top of messaging connectors that are discussed in Chapter 14. Configuring a replication connector is relatively simple, and the only thing that the administrator has to consider is the path upon which the replication is done over an organization. The simple rule to accomplish efficient replication is to follow the shortest path possible, much in the same way as for a messaging connector.

The Exchange directory cannot be replicated to another system at present, and it is even impossible to replicate the directory to another Exchange organization. It is, however, possible to replicate part of the directory information, the information on recipients, to a Microsoft Mail system. This can be done using a function called directory synchronization, which is discussed in the following chapter.

Previous Page Page Top TOC Next Page