You’ve seen that AD domain controllers work in a multi-master fashion. This means that you can make changes, like modifying a user account or changing group membership on any domain controller. If that’s all that happens, you’ll be left with multiple versions of the same user account or groups that “think” that they have different membership lists depending on which domain controller you’re looking at. This is a recipe for chaos.
Try it Now: Test data is identical across domain controllersCheck the same user account on different domain controllers. Is the information identical? Can you see anything different between the two versions? Make the same check for the membership list of a group.
Hopefully you’ve found that the data associated with users, groups, and other objects is the same across domain controllers. You’ll find some minor differences in the information held for an individual object on each domain controller, but this has to do with keeping track of the object, such as the Update Sequence Number [USN].
Active Directory needs a process to ensure that when an object is changed on one domain controller, that change is communicated to all other relevant domain controllers. This process is called replication.
In this chapter we’ll look at how replication works, configuring replication, testing that it’s working correctly using Repadmin and PowerShell, and forcing replication using Repadmin and ADSS. Finally, we’ll conclude the chapter with a lab.
17.1. How replication works
17.2. Configuring replication
17.3. Testing and forcing replication
17.4. LAB
17.5. Ideas for on your own
This chapter is from the book
Understanding AD DS Replication
Replication in AD DS is a critical function that is necessary to fulfill the functionality of a multimaster environment. The ability to make changes on any DC in a forest and then have those changes replicate to the other DCs is key. Consequently, a robust method of distributing this information was a major consideration for the development team at Microsoft. AD DS replication is independent of the forest, tree, or domain structure, and it is this flexibility that is central to AD’s success.
Sites, Site Links, and Site Link Bridgeheads
For purposes of replication, AD DS logically organizes groups of servers into a concept known as sites. Generally speaking, a single site should be composed of servers that are connected to each other via high-speed connections. The links that are established to connect two or more locations connected potentially through slower-speed connections are known as site links. Sites are created with site links connecting the locations together to enable the administrator to specify the bandwidth used to replicate information between sites.
Instead of having information replicated immediately between servers within a high-speed connected site, the administrator can specify to replicate information between two sites only once per night or at a time when network demands are low, allowing more bandwidth availability to replicate AD DS information.
Servers that funnel intersite replication through themselves are known as site link bridgeheads.
Figure 4.8 shows a potential Windows Server 2016 AD DS site structure. Site links exist between offices, and a DC in each site acts as the site link bridgehead. The site structure is completely modifiable and should roughly follow the WAN structure of an organization. By default, only a single site is created in AD DS, and administrators must manually create additional sites to be able to optimize replication. You can find more information about these concepts in Chapter 7.
Understanding Originating Writes
Replication of objects between DCs is accomplished through the use of a property known as originating writes. As changes are made to an object, this property is incrementally increased in value. A DC compares its own version of this value with the one received during a replication request. If it is lower, the change is applied; if not, it is discarded. This simple approach to replication is also extremely reliable and efficient and allows for effective object synchronization. For more information about replication, including a detailed analysis of originating writes and its other key components, see Chapter 7.
Using PowerShell Replication Commandlets in Windows Server 2016
Windows Server 2016 supports PowerShell commandlets that are meant to act as a replacement for legacy tools such as repadmin, which were previously used to control AD DS replication. These commandlets, described in detail in Chapter 7, allow for fully automated replication administration and the creation of automated scripts for managing replication between DCs.