As you can see by now, intra-site replication and inter-site replication have plenty of differences between them. Within the same site, each server communicates with several neighboring replication partners. Eventually, one random change committed to any of the domain controllers is replicated to all site domain controllers in less than a minute and just a few hops. Contrary to this, inter-site replication is performed through so-called bridgehead servers. There can be only one domain controller that participates as a bridgehead server in each site at any given time, and by default it is selected automatically by the ISTG process.
In cases when the company uses public network segments for replication and firewalls in their network, administrators can override the automatic selection by punching in local IP addresses that are allowed to be reached from outside, and hard-coding dynamic RPC ports that will be used by replication.
Other considerations in selecting a bridgehead server manually should be server "proximity" to the outside world (in terms of internal network hops over routers), overall network link and server hardware fault tolerance, and the horsepower of the server. If your domain controller hardware is not standardized and does not maintain the same performance level, you may want to designate one of your more powerful servers to handle bridgehead replication, considering the traffic compression and excessive CPU load associated with this role.
If you opt to select a preferred bridgehead server manually, be aware that KCC will not be able to recover from a situation if this manually selected bridgehead server goes down. Because of this, it is recommended that you designate at least two preferred bridgehead servers in each site.
The big picture of a replication process that spans two sites may be described as follows:
■ A change is made and is committed to a local domain controller.
■ In 15 seconds, the local domain controller sends a notification to neighboring replication partners in the local site.
■ Replication partners request the information upon receiving the notification, then wait for 15 seconds, and submit their own notifications to their respective replication partners. This reaches all domain controllers within one site in no more than three hops.
■ At some point, this change reaches the domain controller designated as a bridgehead server. It waits for the next replication window and submits a notification to its bridgehead server counterpart in the second site.
■ The second site's bridgehead server pulls the information via a site link, waits for 15 seconds, and sends local notification to its own replication partners in the second site.
■ From this point on, the process of notifications and 15-second cool-offs repeats up to three times, replicating the change to all domain controllers in the second site.
Figure 5-5 depicts this process.
Was this article helpful?
Read how to maintain and repair any desktop and laptop computer. This Ebook has articles with photos and videos that show detailed step by step pc repair and maintenance procedures. There are many links to online videos that explain how you can build, maintain, speed up, clean, and repair your computer yourself. Put the money that you were going to pay the PC Tech in your own pocket.