Advanced AD Inter-Site Replication

Many of us have physical locations that are connected by high-speed connections, but we have elected to still represent these sites as separate AD Sites for other reasons: segmentation of authentication traffic, global catalog load balancing, DFS Root location, disaster recovery, etc. Unfortunately, now that the DCs are in separate AD sites, replication is relegated to the timed replication cycle rather than the change notification cycle used within the same site, or are they?

Before we discuss how to change one's Inter-Site links, let us review the 2 primary mechanisms used for replication within Active Directory: Timed Replication and Change Notification Replication.
The default replication mechanism for Intra-Site connections, DCs within the same AD Site, is Change Notification Replication. This is a mechanism where each Domain Controller communicates directly to the others in its site immediately notifying each other that they have changes. This allows for fast convergence of changes within a site, but takes a fair amount of communication to accomplish.
The default replication mechanism for Inter-Site connections, that is connections between DCs in different sites, is a timed replication cycle that can occurs at best four times per hour. This can lead to change convergence times on the order of 30 minutes in a typical mesh type replication configuration; and even longer if you have been forced to configure your replication in a tree fashion due to either DC/Site count or unruly WAN links. This mechanism is easy to configure, easy to maintain/explain, and reasonably efficient over slow WAN links. Unfortunately, it can also lead to unacceptable security lags and service delivery.
This is because changes need to replicate out from where they are made to all other sites. While the change is "in transit", one cannot guarantee which way AD will respond until the change has been replicated to all DCs. This transit time is called the convergence time. As one would expect, changes will go into effect pretty quickly in the original site due to the change notification replication. Changes to DCs in other sites however, will take significantly longer to reach other AD sites due to the default timed nature of replication across Inter-Site links. While many times this has no effect on overall service, there are times this can be unacceptable.
If your organization is like most others and you have a centralized service desk and/or AD management team, the real timing of changes may have a significant impact on the steps necessary and hence the overall service. For example, when you get that call from HR that an account needs to be disabled for disciplinary reasons and a technician makes the change to disable the account. If the technician is "forward thinking" and connects to the DC in the site where the end-user is located, the change is effective locally very quickly preventing access from workstations locally. However, we all live in a very connected world. If the user is in a site in a different site from their Exchange Mailbox server (not that uncommon today), the same user will still have access to their mailbox contents until the change reaches the domain controllers in the site with the Exchange Mailbox and CAS servers; potentially a major security issue.
With the cost effective availability of Ethernet speed links between locations today, there may be a business case to eliminate timed AD replication in significant portions of your environment. While this can be accomplished by simply spanning AD Sites across multiple physical locations, this may not have the desired results due to DFS root locators, GC access speeds, and a number of other issues. Ideally, one should be able to enable change notification replication on select AD Site connectors.
Luckily this is possible, if poorly communicated and documented. Change notification is possible on any IP Link. SMTP Links do not support Change Notification. To enable change notification on an IP site link

1. Launch ADSI Edit by running adsiedit.msc
2. In ADSI Edit, expand the Configuration Container icon and then expand CN=Configuration, DC= ForestRootDomainName and CN=Sites.
3. Expand the CN=Inter-Site Transports container, and then click CN=IP.
4. In the details pane, right-click the site link object whose options attribute you want to change, and then click Properties.
5. In the Select a property to view box, click options.
6. If the Value(s) box displays <not set>, in the Edit Attribute box, type 1 for the value (bit 0=1). See note below.
7. Click Set and then click OK.

Note: If the Value(s) box contains a value, you must derive the new value by using a Boolean BITWISE-OR calculation of the existing value and the value that enables the replication change you are making. Then convert that value to an integer. Therefore, if a value is set, convert the integer value to a binary value and OR that value with the value 0001. Then convert the results back to an integer and type the value in the Edit Attribute box.
For example, if the existing decimal value is 4, that value is equal to 0100 in the binary system. The value that enables change notification is 1, or 0001 in binary. The OR operation combines 0 OR 0 = 0, 0 OR 1 = 1, 1 OR 0 = 1, 1 OR 1 = 1. Therefore, the following OR calculation computes the binary value:
0100 (existing value)
0001 (value that enables change notification)
0101 (adds enable change notification to the existing setting) The binary value 0101 converts to the digital value 5. For information about binary calculations and converting binary values to digital values, see Windows 2000 Server Help.


Due to the increased communications needs of Change Notification replication, one should not simply enable change notification on all links. Latency and available bandwidth needs to be reviewed prior to making this type of change. As a general rule of thumb, I wouldn't consider doing this across any link with more than 50ms of latency, so intercontinental links are pretty much out of the question regardless of bandwidth. I have never seen any absolute recommendations about the minimum amount of bandwidth needed to support a change notification environment, but the rule of thumb has been 5Mbps total bandwidth AND 1Mbps average free bandwidth before even considering change notification replication. Even if your environment meets that minimum, be prepared to reverse the configuration should overall network performance be adversely affected.
Even with change notification, one still needs to be judicious about the proper assignment of server connections within the ntDS config of each server in Sites and Services; probably even more so. This is because the fewer servers that each server needs to notify, the faster each server will complete their replication cycle and the fewer system resources will be consumed. One can think of each server connection as a link in a chain. The longest chain needed (spanning tree depth) to get a change from point A to point B will drive the convergence time in your environment. The trick is keeping both connections per server and total communications chain length low for optimal replication performance.
Even if you are lucky enough to have a WAN that can support change notification from end-to-end, do not expect instant change convergence. In most production enterprise environments with an expected number of DCs and sites, the convergence time will still likely be on the order of a couple minutes. This is still a significant improvement over the 30-40 minutes one expects in a mesh type replication configuration with scheduled replication.
For a more in depth discussion of AD replication considerations, please see the following article from Microsoft.