DESKTOP

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, time.windows.com, pool.ntp.org, 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:

1.
Open Active Directory Sites and Services.

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

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

4.
Select the target domain controller, and click OK.

5.
Name the connection object, and click OK.

6.
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.

Note

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:

1.
Open Active Directory Sites and Services.

2.
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.

3.
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:

1.
Open Active Directory Sites and Services.

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

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

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

Figure 1. Setting the intersite replication interval.


5.
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.

Other  
  •  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
  •  
    Most View
    Sharepoint 2013 : Using SkyDrive Pro - Accessing your SkyDrive Pro account, Saving files to SkyDrive Pro
    The Great In-App Purchase Rip-Off (Part 1)
    Last Call For Blackberry? (Part 1)
    Tt eSports Level 10M Gaming Mouse - Unlike Any Other
    Eat More Healthy With Calorific
    iphone SDK : Using the ABPersonViewController Class, Using the ABNewPersonViewController Class
    Windows 8 : Understanding product editions, architectures, and hardware requirements
    Windows Vista : Managing Your Contacts
    SQL Server 2008 : Common performance problems (part 1) - Procedure cache bloating
    Learn How To... Remotely Access A PC
    Top 10
    New Camera For You – Nikon 1 AW1
    Phase One IQ250, Hasselblad H5D-50c - Medium-format Media Systems: Bigger Gets Better
    Kaveri APU - AMD A10-7700K
    Fujifilm X-M1 – Review April 2014
    Fujifilm X-T1 : Good To Go
    Dedicated Gaming Monitors BeNQ XL2720Z
    Cooler Master HAF Stacker Case
    NZXT Phantom 530 – Shiny Case
    Hart Audio Evo1 Active Loudspeaker Review (Part 2)
    Hart Audio Evo1 Active Loudspeaker Review (Part 1)