About some nuances of setting AD intersite replication or "Not all Microsoft articles are equally useful"

One fine spring morning, when the fresh mail had already been read, and the cup of tea had not yet ended, I came across an article in the blog “Ask the Directory Services Team” entitled Configuring Change Notification on a MANUALLY created Replication partner . In it, Microsoft employee Jonathan Stevens describes how to teach your domain controllers to quickly replicate changes in AD between sites (under certain conditions).
“Cool! - I thought then - I should try.

In AD certification courses and in numerous articles, we are told that there are two types of replication: intrasite and intersite.

NB I hope everyone understands that we are talking about AD directory replication, which has nothing to do with the replication of the Sysvol folder. And yet, if you have never heard of USN, KCC, Up-to-dateness Vector and other nasty things, then you can not read further, it will be unclear.

Intersite replication occurs “almost instantaneously” (actually 5 seconds), intersite replication occurs “according to schedule”, which is usually set in the SiteLink properties. The disadvantage of the schedule is that the minimum intersite replication period is 15 minutes (four times per hour) and cannot be reduced by standard means.
')
“Can it be non-standard?” You ask right away. "Maybe" - Microsoft answers us in the article Advanced Replication Management , published on technet.microsoft.com. It turns out that changing a certain bit in the Options attribute of the corresponding SiteLink allows you to turn on Notification of changes that have occurred (Notification) during intersite AD replication. A notification mode determines the difference between the two types of replication. Great, we'll have “instant” replication for all controllers!

Here nifiga! Unfortunately, there is one significant limitation in the method described on Technet: change notifications start working only if the AD DS connection was created automatically by means of the KCC. Such AD DS connections have the name <automatically generated> , this is if you suddenly did not know :). If in your organization KCC for some reason do not trust and create connections manually, then, alas, in that article we were offered to be content with a 15-minute replication interval.

Now back to the article by Jonathan Stevens. In it he describes the reason for such a restriction and the way to circumvent it. I will not duplicate the information here, if interested, then I cited the link to the article at the very beginning.

So, we have instructions, playful hands of enthusiasm and a bit of free time. Let's try!

We assemble a testing ground of two virtual domain controllers running Windows Server 2012 Datacenter Edition.
The level of forest and domain of Windows Server 2012. Both controllers are DNS servers and global catalog servers, located in the same network segment.

We carry controllers across different sites:



After that, we manually create duplicate AD DS Connections, push replication, and then delete the automatically generated connections.



Note! I strongly recommend replacing the connections in the specified order so that at any time there is at least one pair of AD DS Connections between the controllers, otherwise replication may fail, at least for a while. For reliability, after each change, manually push replication.

On the ReplTest-DC2 controller in the PowerShell window, run the script:

while ($true)
{repadmin /showutdvec ReplTest-DC2 "DC=Repltest,DC=local" | ?{$_ -match "ReplTest-DC1"};sleep 1}


It will allow us to track in real time (once per second) the change to the Up-To-Dateness vector of the ReplTest-DC2 controller, extracting from it the line relating to the replication partner named ReplTest-DC1.



Please note that in the highlighted line USN changed from 12575 to 12605. This happened after a test user was created on ReplTest-DC1 and replication was initiated manually.

So, we made sure that replication works. We proceed directly to the verification of Jonathan's article.

We set the fourth bit of the Options attribute to one for the manually created AD DS Connection (for accuracy, I did it for both connections: from ReplTest-DC1 and from ReplTest-DC2).



Do not forget to push replication.

After this, we edit an arbitrary attribute of an arbitrary object on ReplTest-DC1. For example, I changed the Description field of a newly created user.

We look at the replication status on ReplTest-DC2:


Zero reaction! USN does not change!
We are waiting for five seconds ... nothing changes, waiting for five minutes ... again does not change!
We are trying to do a mirror operation: we make changes to AD on ReplTest-DC2 and track the changes on ReplTest-DC1. The same result.

A few hours of various tests did not change the picture.

I admit, I was expecting this, because even then, on a beautiful spring morning, I had already done the same actions for 2008 controllers.

This is sad, but at this moment I have to state:

“The method for enabling notifications for manually created AD DS Connections in the Jonathan Stevens article does not work”

Perhaps there is some step omitted in the article or there are additional requirements, but the result is discouraging. I used to believe the articles of the AD DS team.

If the distinguished colleagues have comments to the test or their results are different from mine, then please indicate in the comments who the radish was wrong and if so, in what place.

I hope that together we will get to the bottom of the truth.