Windows Server 2008 : Understanding AD DS Replication in Depth

1/31/2011 4:04:54 PM
Windows Server 2008 R2 improvements in AD DS replication are directly drawn from lessons learned in Windows 2000, Windows Server 2003, and Windows Server 2008. Read-Only Domain Controllers (RODCs) can be created in remote sites to reduce replication and increase security. Replication compression can now be disabled in well-connected sites, enabling designers to sacrifice bandwidth for processor utilization in domain controllers (DCs). In addition, concepts such as DC promotion from media allow global catalog servers to be created from CDs or other media, which greatly increases DC placement flexibility. Other improvements, such as universal group caching on domain controllers, allow remote domain controllers to function as global catalog servers by caching frequently used universal group membership locally.

Many of these improvements to AD DS replication were introduced with Windows Server 2008 and, although there are few new replication-specific improvements in Windows Server 2008 R2, this latest version cements these new features and fixes design limitations that have thwarted replication plans in the past. Problems with replication design can potentially cripple a network; therefore, it is wise to put some serious thought into the proper layout and design of an effective replication scheme.

Understanding the Role of Replication in AD DS

All enterprise directory environments must include mechanisms to synchronize and update directory information across the entire directory structure. In Windows Server 2008 R2 AD DS, this means that every domain controller must be updated with the most recent information so that users can log on, access resources, and interact with the directory accurately.

AD DS differs from many directory services implementations in that the replication of directory information is accomplished independently from the actual logical directory design. The concept of AD DS sites is completely independent from the logical structure of AD DS forests, trees, and domains. In fact, a single site in AD DS can actually host domain controllers from different domains or different trees within the same forest. This allows for the creation of a replication topology based on a wide area network (WAN) structure, while the directory topology can mirror the organization’s structure.

Outlining Multimaster Topology Concepts

AD DS was specifically written to allow for the creation, modification, and deletion of directory information from multiple domain controllers. This concept, known as multimaster replication, allows no one domain controller to be authoritative. If any domain controllers go out of service, any one of the rest of the writable domain controllers can make changes to directory information. Those changes are then replicated across the domain infrastructure. Of course, there needs to be some level of control on this type of replication so that only the most recent changes take precedence. This type of control is realized in AD DS through the concept of Update Sequence Numbers (USNs).

Explaining Update Sequence Numbers (USNs)

All enterprise directory services implementations require a mechanism to handle the incremental storage of changes made to directory objects. In other words, whenever a password is changed, that information must be accurately passed to all domain controllers in the domain. This mechanism must also be able to apply only those changes that occurred at the most recent intervals.

Many directory services implementations relied on exact time synchronization on all domain controllers to synchronize information. However, keeping the clocks of multiple servers in sync has been proven to be extremely difficult, and even slight variations in time could affect replication results.

Thus was born the concept of the Update Sequence Number. AD DS utilizes USNs to provide for accurate application of directory changes. A USN is a 64-bit number that is maintained by each domain controller in AD DS. The USN is sequentially advanced upon each change that is made to the directory on that specific server. Each additional domain controller also contains a copy of the last-known USN from its peers. Updates are subsequently made to be more straightforward. For example, when requesting a replication update from Server2, Server1 will reference its internal table for the most recent USN that it received from Server2 and request only those changes that were made since that specific number. The simplicity of this design also ensures accuracy of replication across the domain environment.

The integrity of replication is ensured with USNs because the USN number is updated only upon confirmation that the change has been written to the specific domain controller. This way, if a server failure interrupts the replication cycle, the server in question will still seek an update based on its USN number, ensuring the integrity of the transaction.

Describing Replication Collisions

The concept of USNs does not completely eliminate the role of proper time synchronization in AD DS. It is still important to maintain accurate time across a domain environment because of the possibility of replication collisions. A replication collision is an inaccuracy in replicated information that takes place because of changes that are enacted on the same object, but before that change has been replicated to all domain controllers. For example, if an administrator resets a user’s password on Server1, and another administrator resets the same user’s password on Server2 before Server1 has had a chance to replicate that change, a replication collision will occur. Replication collisions are resolved through the use of property version numbers.

Understanding Property Version Numbers

Property version numbers are applied as an attribute to all objects within AD DS. These numbers are sequentially updated and time-stamped whenever a change is made to that object. If a replication collision occurs, the property version number with the latest time stamp will be enacted, and the older change will be discarded. In the example from the preceding section, the password change with the latest time stamp will be applied to the user.

This concept subsequently requires accurate time synchronization to be a priority for an AD DS domain—although it is not as critical as in other directory services implementations that rely on it for all replication activity.

Windows Time

Time is an important aspect in AD DS. Kerberos is the native authentication mechanism used by Windows AD DS and bases its ticketing system on an accurate time source. If two machines in the same domain differ by more than five minutes, authentication will break. As such, accurate time must be shared among domain members.

Windows Server 2008 R2 utilizes the Windows Time Service and the domain hierarchy to maintain a consistent source of time among all the domain controllers throughout the domain.

One server, the PDC emulator, is responsible for getting accurate time from a manual trusted source, such as NIST,,, or a GPS clock. This trusted source is known as stratum 0. The PDC emulator is stratum 1. Stratum 2 goes to all other DCs in the same site as the PDC emulator. The bridgehead server in remote sites is stratum 3 and all other DCs in the same remote site are stratum 4.

Member computers will try to get time from the lowest stratum DC in their own site. If that DC is not serving time, they will use the next highest stratum.

Domain computers always honor this system, which explains why the clock will reset to the domain time automatically, even if you change the local clock. Time normally syncs at startup and every 45 minutes thereafter for three consecutive, successful times, and then the interval check period is increased to 8 hours.

It is important that administrators configure and test the manually configured external time source on the PDC emulator.

Describing Connection Objects

Connection objects are automatically generated by the AD DS Knowledge Consistency Checker (KCC) to act as pathways for replication communication. They can be manually established, as well, and essentially provide a replication path between one domain controller and another. If, for example, an organization wants to have all replication pushed to a primary domain controller (PDC) before it is disseminated elsewhere, direct connection objects can be established between the two domain controllers.

Creating a connection object is a straightforward process. After one is created, Windows Server 2008 R2 does not attempt to automatically generate a new one across the same route unless that connection object is deleted. To manually set a connection object to replicate between domain controllers, perform the following steps:

Open Active Directory Sites and Services.

Expand Sites\<Sitename>\Servers\<Servername>\NTDS Settings, where Servername is the source server for the connection object.

Right-click NTDS Settings and choose New Active Directory Domain Services Connection.

Select the target domain controller, and click OK.

Name the connection object, and click OK.

Right-click the newly created connection object, and select Properties to open a properties page for the object. You can then modify the connection object to fit any specific schedule, transport, and so on.


The connection objects that appear as automatically generated were created by the KCC component of AD DS to provide for the most efficient replication pathways. You must, therefore, have a good reason to manually create these pathways because the automatically generated ones usually do the trick.

Understanding Replication Latency

Administrators who are not accustomed to AD DS’s replication topology might become confused when they make a change in AD and find that the change is not replicated immediately across their environment. For example, an administrator might reset a password on a user’s account, only to have that user complain that the new password does not immediately work. The reason for these types of discrepancies simply lies in the fact that not all AD changes are replicated immediately. This concept is known as replication latency. Because the overhead required in replicating change information to all domain controllers immediately is large, the default schedule for replication is not as often as might be desired. Replication of critical information can be forced through the following procedure:

Open Active Directory Sites and Services.

Drill down to Sites\<Sitename>\Servers\<Servername>\ NTDS Settings, where Servername is the server that you are connected to and that the desired change should be replicated from.

Right-click each connection object, and choose Replicate Now.

Another useful tool that can be used to force replication is the repadmin command-line tool. This tool is installed as part of a default Windows Server 2008 R2 domain controller install. After being installed, repadmin can be used to force replication for the entire directory, specific portions of the directory, or to sync domain controllers across site boundaries. If the bandwidth is available, a batch file can be effectively written to force replication between domain controllers, converging the directory as quickly as possible.

The default replication schedule can be modified to fit the needs of your organization. For example, you might decide to change the default schedule of 180 minutes to a schedule as low as every 15 minutes. To make this change, perform the following steps:

Open Active Directory Sites and Services.

Drill down to Sites\Inter-Site Transports\IP.

Right-click the site link that requires schedule changes and choose Properties.

Change the Replicate every field to the new replication interval, as shown in Figure 1.

Figure 1. Setting the intersite replication interval.

Click OK to save any schedule changes.

Of course, changing this schedule comes with some caveats, namely watching for increased frequency of high network bandwidth utilization. You should match the trade-off of your organization’s needs with the increased resource consumption levels required.

  •  Programming Excel with VBA and .NET : Knowing the Basics - Classes and Modules
  •  Windows 7 : Indexing Your Computer for Faster Searches (part 3) - Optimizing File Properties for Indexing
  •  Windows 7 : Indexing Your Computer for Faster Searches (part 2) - Specifying Files Types to Include or Exclude
  •  Windows 7 : Indexing Your Computer for Faster Searches (part 1) - Adding or Removing Indexed Locations
  •  Windows Server 2008 : Designing Organizational Unit and Group Structure - Exploring Sample Design Models
  •  Windows Server 2008 : Designing Organizational Unit and Group Structure - Understanding Group Design
  •  Windows Server 2008 : Designing Organizational Unit and Group Structure - Group Policies and OU Design
  •  Windows 7 : Searching Your Computer (part 2) - Search Filters
  •  Windows 7 : Searching Your Computer (part 1)
  •  Windows 7 : Putting Windows Explorer to Work for You
  •  Windows Server 2008: Using OUs to Delegate Administration
  •  Windows Server 2008: Defining AD Groups
  •  Windows Server 2008: Defining Organizational Units in AD DS
  •  Windows 7 :Navigating Your Computer with the Address Bar (part 2) - Using Selected Paths to Quickly Navigate Your Computer
  •  Windows 7 :Navigating Your Computer with the Address Bar (part 1) - Accessing Locations on Your Computer
  •  Windows 7 : Exploring and Searching Your Computer - Exploring Your Documents
  •  Designing a Windows Server 2008 R2 Active Directory : Renaming an AD DS Domain
  •  Designing a Windows Server 2008 R2 Active Directory : Understanding the Placeholder Domain Model
  •  Designing a Windows Server 2008 R2 Active Directory : Understanding the Empty-Root Domain Model
  •  Windows 7: Managing Software Once It’s Installed (part 3) - Viewing and Managing Startup Programs
    Top 10
    Tech Talk: All about Desktop & Laptop Processors
    Migrating from Legacy SharePoint to SharePoint Server 2010 : Planning for an Upgrade to SharePoint 2010
    Windows 7 : Fine-Tuning the Settings for Windows Media Center
    Programming .NET Security : Cryptography Explained (part 1) - Confidentiality
    Accuratus iMage Beatz - Perfect companion for iDevices
    Windows Phone 7 : Working with Controls and Themes - Adding Transition Effects
    Filtering Out Evil with Firewalls (part 2)
    Windows Server 2008: Using OUs to Delegate Administration
    Multi-Server Administration : Policy-Based Management
    Using iCloud in windows
    Most View
    What we expect: Windows 8 Tablets
    IIS 7.0 : Implementing Access Control - NTFS ACL-based Authorization & URL Authorization
    Android Security : Files and Preferences
    Upload a File with FTP
    Transact-SQL in SQL Server 2008 : GROUP BY Clause Enhancements
    Fallen IT Giants
    Windows Phone 7 Development : Understanding Trial and Full Modes (part 1) - Using the IsTrial Method
    Programming .NET Security : Programming XML Signatures (part 2) - Embedding Objects in the Signature
    Silverlight : Capture a Webcam
    IIS 7.0 : Striking a Balance Between Security and Performance - SSL
    SQL Server 2008 : General T-SQL Coding Recommendations (part 1) - Provide Explicit Column Lists & Qualify Object Names with a Schema Name
    iPhone Application Development : Reading and Writing User Defaults (part 2) - Implementing System Settings
    Tablet for offices and being on street
    Maintenance Basics: Delete Internet Files
    iPhone 3D Programming : Adding Depth and Realism - Filling the Wireframe with Triangles
    Choosing a super-zoom camera (part 8) - Panasonic Lumix DMC-TZ18 & Panasonic Lumix DMC-TZ20
    The ASP.NET AJAX Infrastructure : The Script Manager Control
    Windows 7 : Detecting and Resolving Computer Problems (part 2) - Tracking Errors in the Event Logs
    Introducing IBM BPM and ESB : Achieving success through BPM enabled by SOA
    Determine Your Need for Server Core