Inter-Site Replication | Active Directory By the Numbers: Windows Server 2003

Tutorial: Configuring Domain Replication Across IP Subnets (Active Directory Sites)

The process of manually configuring Active Directory replication is as follows :

Place the domain controllers on separate IP subnets (which we have already done in the Tutorial Prep above)
Create Sites in which to place each domain controller
Create Site Links to connect each site for replication
Create subnets in which to bind each site
Set the replication cost for each site link
Set the replication time interval for replication

It sounds simple enough, and it really is. So let's get started.

To create the sites in which our domain controllers will reside, open Active Directory Sites and Services , located on Start ˆ’ > Administrative Tools . The window that appears is very similar to Active Directory Users and Computers.
In the left pane, right-click the folder labeled Sites , and choose New Site .
The New Object - Site window appears. In the name field, type guineasite . In the bottom pane of the window, click the item labeled DefaultIPSiteLink . We do this because we have not yet created any site links. Windows creates a default site link and names it DefaultIPSiteLink. Later we will create our own site links and use them instead of the default. Click OK twice when finished:
Using the steps 1 through 3, create two more sites and name them denversite and austinsite .

We now need to link these sites so that they replicate to one another. We do this with site links .
Back in Active Directory Sites and Services, expand the Sites folder on the left pane of the window. Notice that our new sites for guinea, denver, and austin are present. Expand the Inter-Site Transports folder, and click the IP folder. The default site link DefaultIPSiteLink appears in the right window pane.
Right-click the IP folder in the left pane and choose New Site Link . The New Object - Site Link window appears. This window allows us to link two or more sites for replication. Using this diagram

we see that we need to create links between guinea and denver , between denver and austin and between austin and guinea .
Create the link between guinea and denver first. In the left pane of the window, click once on the item labeled denversite and click the Add button. This moves our denver site into position to be added to our new site link. Now do the same for the guineasite item. In the Name field, type a name of guinea <-> denver .

When finished, you should see a screen similar to the screenshot shown below. Click OK .

Create another site link between denver and austin and name it denver <-> austin , adding the denversite and austinsite site links. Finish things up by creating a third site link called austin <-> guinea and add the guineasite and austinsite links.
We now need to create the IP subnets in which to deposit our sites. In the left pane of Active Directory Sites and Services, right-click the folder labeled Subnets and click New Subnet . This brings up the New Object - Subnet window.

Recall that our guinea.pig domain controller is located in the 192.168.1.0 subnet, denver is located in 192.168.100.0, and austin tops the list out in 192.168.5.0. We must place our sites into subnet objects that we create here.
In the address field, enter 192.168.1.0 , and enter 255.255.255.0 in the mask field. Since our guinea domain belongs in this subnet, click guineasite at the bottom of the window and choose OK .
Create two more subnets and add denversite to the 192.168.100.0 subnet and austinsite to the 192.168.5.0 subnet .

We must now move the domain controllers from the guinea, denver, and austin domains into their proper sites for replication. By default, all domain controllers are placed in the Default-First-Site-Name container.
In Active Directory Sites and Services, expand all site containers (i.e., austinsite , default-first-site-name , denversite , and guineasite ). Notice that each site contains a folder labeled Servers . It is in these Server folders that we shall place each domain controller.
Double-click the Servers folder inside the Default-First-Site-Name site container to expand it. Notice that it contains all three domain controllers in our forest. Notice also that the domain controllers appear not only in the left window pane, but also in the right window pane.
Drag each domain controller, one at a time, to its proper Servers folder inside each site. For example, drag the guinea.pig domain controller to guineasite ˆ’ > Servers folder, the denver domain controller to the denversite ˆ’ > Servers folder, and the austin domain controller to the austinsite ˆ’ > Servers folder as shown here:

Last but not least, we must set the cost for each site link and the intervals for replication.
Expand the folder labeled Inter-Site Transports and click the folder labeled IP . The list of site links appears in the right column of the window. Referring back to figure 5-3, our costs for replication are as follows:
- guinea <-> denver = cost of 80
- denver <-> austin = cost of 40
- austin <-> guinea = cost of 20
For this exercise, we wish to set the replication interval between domain controllers to 15 minutes. In a real-world setting, this may be a bit excessive, and will generate excessive network traffic across your network. You might want to set the replication interval to every one or two hours. Also, we wish to set limits on when the replication can take place. For example, we might not want replication to occur during the busiest hours of the day from 8am to 12pm, as this might tend to hamper network performance.
Right-click the guinea <-> denver site link and choose Properties . Toward the bottom of the window, set the cost to 80. Next to the Replicate every field, enter 15 minutes:
Click the Change schedule button and set the hours of 8am to 12pm to Replication not available . This prevents replication from occurring during these busy times of the day. Click OK :
Repeat this procedure for the other two site links, ignoring the defaultIPsitelink.

We have now set up the infrastructure for our domain controllers to replicate to and from one another. We must now test to ensure that replication is working properly. In order to do this, we must install the Windows support tools. Install these on each domain controller by running the supptools installer which is located on the Windows Server 2003 installer CD in the support\tools folder.

Tutorial: Monitoring Replication Between Domain Controllers

There are three main ways to monitor replication between domain controllers.

Watching each domain controller to ensure that changes made to the directory are actually replicated ( Note: this is probably not the best option, especially if domain controllers are separated by geography ).
Observing the Event Viewer
Using the repadmin and dcdiag support tools

On all three domain controllers, reset the replication schedule back so that replication may take place during all hours. After all, we wouldn't want you to run into problems if you're performing this tutorial between the hours of 8am and 12pm.
Shut down the denver and austin domain controllers and wait for the replication interval to expire. In our case, this is 15 minutes.
Log into the guinea.pig domain controller as administrator and open a command prompt (located on Start ˆ’ > All Programs ˆ’ > Accessories ).
We shall use the repadmin command line tool to check for failures between replication partners . For example, guinea.pig's domain controller, DC01, is partnered to replicate with denver's domain controller, DC02, and austin's domain controller, DC03. Enter the following text and hit Enter :

repadmin /showreps dc01.guinea.pig

In the resulting text, check for any failures in replication. For example, the following indicates that the replication links between guinea.pig and denver.guinea.pig, and guinea.pig/austin.guinea.pig, have some serious problems:

 Source: denversite\DC02 ******* 6 CONSECUTIVE FAILURES since 2003-08-29 21:54:22 Last error: 1722 (0x6ba):         The RPC server is unavailable. Source: austinsite\DC03 ******* 6 CONSECUTIVE FAILURES since 2003-08-29 21:54:22 Last error: 1722 (0x6ba):         The RPC server is unavailable.

We now use the dcdiag command line tool to check for replication problems between replication partners. Enter the following in the command prompt and hit Enter :

dcdiag /test:replications

The resulting test may take a few seconds, since two of our domain controllers are offline. When the test finishes, check for errors similar to those in this example:

 Testing server: guineasite\DC01    Starting test: Replications      [Replications Check,DC01] A recent replication attempt failed:       From DC03 to DC01       Naming Context: DC=ForestDnsZones,DC=guinea,DC=pig     The replication generated an error (1722):     The RPC server is unavailable.     The failure occurred at 2003-08-30 18:18:04.     The last success occurred at 2003-08-29 21:54:22.     1 failures have occurred since the last success.     [DC03] DsBindWithSpnEx() failed with error 1722,     The RPC server is unavailable..     The source remains down. Please check the machine.   [Replications Check, DC01] A recent replication attempt failed:     From DC02 to DC01     Naming Context: DC=ForestDnsZones,DC=guinea,DC=pig     The replication generated an error (1722):     The RPC server is unavailable.     The failure occurred at 2003-08-30 18:18:24.     The last success occurred at 2003-08-29 21:54:22.     1 failures have occurred since the last success.     [DC02] DsBindWithSpnEx() failed with error 1722,     The RPC server is unavailable..     The source remains down. Please check the machine.

Both of the examples in steps 5 and 6 show that there is a problem with the Remote Procedure Call (RPC), which is the default process used by domain controllers to replicate information to and from one another.

Notice also the errors that dcdiag produces informing us that " The source remains down. Please check the machine " This also tells us that the domain controller in question is down or having a problem.

Now open the Event Viewer (located on Start ˆ’ > Administrative Tools ) and click the item labeled Directory Service on the left pane of the window. The Directory Service can contain status entries dealing with Active Directory replication. In our example shown here, we have multiple problems in our directory:

Double-click the Warning entry closest to the top of the list. A new window appears containing text similar to this example:

 Description: The Knowledge Consistency Checker (KCC) was unable to form a complete spanning tree network topology. As a result, the following list of sites cannot be reached from the local site. Sites: CN=denversite, CN=Sites, CN=Configuration, DC=guinea,DC=pig CN=austinsite, CN=Sites, CN=Configuration, DC=guinea,DC=pig

This tells us that the system is unable to replicate data between DC01 and denver, and DC01 and austin. Click OK to dismiss the dialog.

Double-click the Error closest to the top of the list in the Event Viewer. The window that appears should contain a message similar to this example:

There is insufficient site connectivity information in Active Directory Sites and Services for the KCC to create a spanning tree replication topology. Or, one or more domain controllers with this directory partition are unable to replicate the directory partition information. This is probably due to inaccessible domain controllers.

This message tells us, again, that there is a problem in replicating information.
Bring denver and austin back online and wait the required 15 minutes and re-run the two command line tests. Notice that replication is back to normal.

Get Info

In most of the error messages shown in the preceding examples, you may have noticed references to the KCC . Standing for Knowledge Consistency Checke r, the KCC takes care of replication of data within a site (intra-site replication).

Keep in mind that you may run these command line replication tests on both the denver and austin domain controllers from DC01. Just remember to use their fully qualified domain name. For example, to check the replication status on the denver domain controller using the repadmin command, type:

repadmin /showreps dc02.denver.guinea.pig

For austin, the command is:

repadmin /showreps dc03.austin.guinea.pig

Tutorial: Forcing Replication Between Domain Controllers

Be honest; wasn't it a pain to have to wait 15 minutes before you could test your replication settings? There is a way to force replication between replication partners so that it occurs almost immediately.

Open Active Directory Sites and Services on the guinea.pig domain controller (DC01).
Expand the Sites folder.
Expand the guineasite container, followed by the servers and DC01 folders. Click NTDS Settings once.
On the right window pane are two items, both labeled <automatically generated> . Notice the data in the From Server column. This column contains the names of the domain controllers from which data is replicated to DC01.
Let's say that we wish to force replication between DC01 and DC03. Right-click DC03 and choose the option labeled Replicate Now . After a few seconds, a window appears informing you that your Active Directory connection spans different sites. This is normal, as we have placed our domain controllers into three different sites.
Force replication between DC01 and DC02 by right-clicking DC02 and choosing Replicate Now .

This process may be performed on any of our domain controllers, and is a convenient way to test that replication is actually working without waiting for the normal replication interval.

Adding Additional Global Catalog Hosts

Up to this point, we have created a domain tree containing three domains, each with its own domain controller with one Global Catalog located in the root domain:

One point of interest to keep in mind is the Global Catalog. Remember, we stated earlier that although there can be only one Global Catalog entity in an entire forest, any number of domain controllers can host, or keep a working copy of, the Global Catalog. This is important, especially where network bottlenecks are concerned . Remember that when any client computer logs into a domain, searches for shared folders, or does anything related to objects in the Active Directory, the Global Catalog must be consulted. So what happens when a client requests information from the Global Catalog, but the Global Catalog is located in a different domain or different Active Directory site? The client's request must be routed across domains and/or sites to reach the Global Catalog. And when these requests are made over slower network connections, such as our ISDN connection in the preceding examples, the client may experience delays.

The solution to this problem is to place a copy of the Global Catalog within each domain and/or site. Data between and among the various Global Catalogs is synchronized during normal replication so that each domain controller hosting the Global Catalog stays up-to-date with the most recent directory information:

The advantage here is that each client has a copy of the Global Catalog in its domain and/or site. For example, let's say a user located in the denver domain requests information on a shared folder in the austin domain. In the previous setup, the user 's request would have been routed to the Global Catalog hosted in the guinea.pig domain on domain controller DC01. But when we place a copy of the Global Catalog on denver's domain controller, DC02, the client's request need not be routed out of his own domain, as DC02 is capable of handling the request. This conserves precious bandwidth by reducing network traffic between the two domains.

Tutorial: Replicating the Global Catalog to Other Domain Controllers

Open Active Directory Sites and Services . Expand the Sites folder.
The two domain controllers that we wish to host the Global Catalog are DC02 and DC03 , located in denversite and austinsite , respectively. Expand the denversite container, the servers folder, and finally the DC02 container. Inside DC02 is the NTDS Settings container. Right-click NTDS Settings and choose Properties .
The NTDS Settings Properties dialog box appears. Place a check in the box labeled Global Catalog , as shown below. Click OK when you're finished:
Repeat steps 2 and 3 for DC03 located in austinsite .

The Global Catalog should replicate to DC02 and DC03 within 15 minutes (our replication interval between sites).

Get Info

Do Active Directory Sites need to be located in different domains, as we have shown in our tutorials? Absolutely not! As a matter of fact, it is completely possible for a single domain to span several IP subnets, and therefore sites. And the process of configuring Inter-Site replication as well as adding multiple Global Catalog hosts to each site is the same as what we have learned in our multiple domain model.