Hi everyone

Here is the second part of our AD DS Replication article. In first part, I talked about the techniques and mechanisms that are used in AD DS replication process. In this part, I will illustrate how an AD DS replication occurs after Active Directory modifications on an example scenario. Our example scenario includes the following topology and events:

Active Directory Topology:

-          Three Active Directory Domain Controller in one site (Figure 1)

-          All three DCs are replication partners with each other

Figure 1: Active Directory topology

The events that occur:

-          New user creation on DC01

-          DC01 replicates its new info to DC02 and DC03

-          DC02 replicates its new info to DC01 and DC03

First of all, I create a new user account on DC01 server. Assume that the current USN value for DC01 before user creation is 2000 and by adding the new user account teo to the domain, it increases to 2001. 2001 is also the USN value for newly created object and it’s attributes. Table 1 represents USN values of the new user account and it’s Office Location attribute.

Table 1: USN value for the new user on DC01

After new user creation on DC01, this server sends the new update to it’s replication partners; DC02 and DC03.DC02 and DC03 can receive this update because highwater mark value of the source machine is greater than the one it knows. Table 2 and Table 3 represent the USN values for the new user account on replicated servers. Please pay attention to the USN values here. The servers give their own value to the same account after they import the update (again we assume that the current USN values of DC02 and DC03 before replication are 4000 and 6000 respectively. Also we assume that all DCs know each other’s USN value as 0 – high watermark value for replication partner). Figure 2 also illustrates the step-by-step processes occurred during replication.

Table 2: USN value of the new user on DC02 after replication

Table 3: USN value of the new user on DC03 after replication

Figure 2: Step-by-step replication process

As DC01 updates the database of it’s replication partners; DC02 and DC03, they will try to update their replication partners also. As you know, DC01 and DC02 are replication partners of DC03, and DC01 and DC03 are replication partners of DC02. So what happen when DC02 tries to replicate to it’s replication partner DC03? When DC02 sends the update information that it has to the other servers, it informs the replication partners about user account it learned from DC01 by the previous replication. But DC03 is also aware of this update (cause it learned the update from DC01 also). So how domain controllers decide which updates they are going to replicate with each other?  How they prevent from unnecessary bandwith usage?

Here comes the up-to-dateness vector (UTDV) table to aid. It is a table that all domain controllers are holding the highest originating USN values for their replication partner’s. This table is sent to replication partner before the actual replication process starts. Therefore, destination server is aware of which updates the source server has. Let me clarify this.

On our example, DC02 tries to replicate changes to DC03 but DC03 also knows this change. Before the replication data is sent to destination server (DC03), DC03 sends up-to-dateness vector information it has to DC02 (during replication request after DC02 informs DC03 about the update). Table 4 represents this UTDV table.

Table 4: UDTV table on DC03

Step-by-step, the process is like below:

1-      DC02 informs DC03 about a new update it has

2-      DC03 requests the update and sends it’s UDTV table to DC02

3-      DC02 looks at the table and decides whether to replicate or not

In our example, DC03 says that it has a value 2001 for DC01. DC02 also has 2001 value for DC01, which is the originating server for update. Therefore it won’t send the update to DC03 because it realizes that the same update is also known by DC03. This process is also known as propagation dampening. The same situation is valid for a replication attempt of DC03 to DC01.

So this is the end of this article. We update the Active Directory database on one of our domain controller. It replicated the update to it’s replication partners. When replication partners tried to replicate the same update to each other again, propagation dampening mechanism blocked the unnecessary replication. See you next time.

Related Posts

1. Active Directory Replication – 1
2. Fsmoroleowner problem during 2003-2008 Active Directory transition
3. Installation and Configuration of Active Directory Certificate Services on Windows Server 2008 R2 – 2