Theory question on AD replication

Question

Hello,

...spotted it by chance today:

If " Intrasite replication takes advantage of LAN network speeds by providing replication as soon as changes occur," why does the default intrasite connection objects have the default schedule set to "once per hour"?

Regards,
Michael

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc775549(v=ws.10)

Answer 1

Hi @Mikhail Firsov

I wanted to provide a bit more context to the paragraph in the article and reference the MS reference documentation.

The schedule setting is actually used to define the replication schedule that is used to replicated the data between domain controllers in the same AD site. As you can see from below the last sync time of the replication status does align to the replication schedule as defined on the connection object.

With the connection object replication schedule set to 15 minutes the last sync time intervals matches replication schedule

With a replication interval of 30 minutes

and one hour

The last sync time matches the schedule. The last sync time in these screenshots is from the msDS-NCReplCursors attribute from the root naming context, and is the same time reported by the repadmin /showrepl as last attempt.

These are the high level steps that are used for the replication:

1. An attribute is changed and needs to be replicated to the other DCs
2. A replicate update is sent to the all the DCs defined in the RepsTo attributes with the DRS_UPDATE_NOTIFICATION flags.
3. if time>=replication schedule interval, then send replication update to the DCs defined in the RepsTo attributes with the DRS_ASYNC_OP, and target DCs will update their replication cursors

In the steps above, step 2 is only completed if the DCs defined in the RepsTo are in the same AD Site or the AD Site Link has notify-pull replication is enabled.

This is the article to the details for scheduled and event driven replication events and the logic used for the replication.

While Richard's article refers to the schedule as a backup, it's more the normal process and notification based replication is an enhancement to the process.

The both the DRS_UPDATE_NOTIFICATION and DRS_ASYNC_OP replication changes are sent with the latest USN to the RepsTo DCs and they in turn pull all the changes up to the USN from the source DC, so a DC in the same AD site should have received all the previous updates when the replication change with the DRS_ASYNC_OP option set is received. But as Richard states, this provide a fall back method if the previous replication notification wasn't received, but the next object change will provide the same opportunity for replication to catch up.

I hope that helps.

Gary.

Other references:

MS-ADTS
3. 1.1.5.1.6 Replication Notification
6. 1.1.2.2.1.2.1.2 Connection Object
MS-DRS
5. 41 DRS_OPTIONS
5. 171 REPS_TO
5. 165 REPLTIMES
5. 166 replUpToDateVector, ReplUpToDateVector

Answer 2

Hi GaryReynolds,

Thank you so much for the detailed explanation!!!

Nevertheless, some points still confuse me a bit:

1) Aligning the replication events with the connection object's schedule depicted above along with the following assertion "But as Richard states, this provide a fall back method if the previous replication notification wasn't received" means the BACKUP method is always in use and

2) In any case, using the connection object's schedule contradicts the "Intrasite replication takes advantage of LAN network speeds by providing replication as soon as changes occur" - the method you have described and this assertion can not be correct at the same time :(

Regards,
Michael

P.S. Which program did you use in your screenshots?

Answer 3

Hi Micheal,

1) Aligning the replication events with the connection object's schedule depicted above along with the following assertion "But as Richard states, this provide a fall back method if the previous replication notification wasn't received" means the BACKUP method is always in use and

Yes, but I'm sure I wouldn't call it a backup, as the transport mechanism used by the notification and scheduled replication updates is the same (TCP/IP) and each replication change will replicate all changes since the last replication. The only difference I can think of, and I haven't found anything to confirm this, is that the schedule replicate task may retry until the replication is successful, or at least report errors in msDS-NCReplCursors attribute. Which are displayed as errors in repadmin /showrepl, which notification updates might not, but I haven't confirmed.

2) In any case, using the connection object's schedule contradicts the "Intrasite replication takes advantage of LAN network speeds by providing replication as soon as changes occur" - the method you have described and this assertion can not be correct at the same time :(

Yes and no, you can use the schedule to change how often the scheduled replication will occur, and see the replication details in repadmin. The other difference between intrasite and intersite replication is that intersite replication is compressed and encrypted, which is designed to reduce network bandwidth at the cost of DC performance, this probably what is means by taking advantage of LAN speeds.

Gary.

The tools is Nettools

Answer 4

Here's the test to check if the following assertion is correct: "Intrasite replication ... as soon as changes occur":

There are two domain controllers - DC01 and DC02. I will first check replication status on DC02, make an ordinary change (not an urgent one, such as the password change!) on DC01 and check whether this change will be replicated to DC02 BEFORE the next scheduled replication attempt to be made.

1) Finding out the next scheduled replication on DC02:

Since the earliest previous replication occured at 10:56 the next replication attempt should be made no earlier than at 11:56 (the schedule is once per hour):

2) I'm going to change the Description field for the pc computer account Test130: now - at 11:47/11:48 - it's empty on both DCs.

3) I change the Description field on DC01 at 11:48 and check this field on DC02

As you see this change has been replicated immediately, without awaitng for the next scheduled replication at 11:56.

4) I once again check the replication status on DC02 at 11:52 ...:

...and see that three partitions have been replicated at 11:48/49 from DC01 to DC02 so

1) the assertion ("Intrasite replication ... as soon as changes occur" ) proved correct

2) the "once per hour" replication does also work, for example the forth partition replicated at 12:57 when its previous connection was at 11:57, although the three partitions above it were once again changed before their new replication time (should be 12:49 and 12:48:)

...so here's my conclusion: any AD changes do really replicate "as soon as changes occur", but if there were no changes at all, KCC will try to replicate according the schedule anyway, probably on the assumption that there could be any errors that had prevented the changes from replicating during the previous replication attempt.

Regards,
Michael

Answer 5

Thank you once again,GaryReynolds!