About some of the nuances of configuring AD cross-site replication or “Not all Microsoft articles are equally useful”
One fine spring morning, when fresh mail had already been read and the cup of tea had not yet ended, I came across an article on the Ask the Directory Services Team blog titled Configuring Change Notification on a MANUALLY created Replication partner . In it, Microsoft employee Jonathan Stevens describes a way to teach your domain controllers to quickly replicate changes in AD between sites (under certain conditions).
“Cool! - I thought then - I have to try. ”
In the certification courses on AD and in numerous articles we are informed that there are two types of replication: intrasite and intersite.
NBI hope everyone understands that we are talking about AD directory replication, which has nothing to do with Sysvol folder replication. And yet, if you have never heard of USN, KCC, Up-to-dateness Vector and othernasty terms, then you can not read further, it will be incomprehensible.
Intrasite replication occurs “almost instantly” (in fact 5 seconds), intersite replication - “according to the schedule”, which is usually set in the SiteLink properties. The drawback 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 tells us in the Advanced Replication Management article.published at technet.microsoft.com. It turns out that changing a specific bit in the Options attribute of the corresponding SiteLink allows you to enable the Notification mode for AD cross-site replication. And the notification mode also determines the difference between the two types of replication. Great, we will have "instant" replication for all controllers!
And here is the nifiga! Unfortunately, there is one significant limitation in the method described on Technet: notification of changes only starts to work if the AD DS connection was created automatically by KCC. Such AD DS connections are named This is if you suddenly did not know :). If for some reason your organization does not trust KCC and creates connections manually, then alas, oh, in that article we were asked to be content with a 15-minute replication interval.
Now back to the article by Jonathan Stevens. In it, he describes the reason for this restriction and a way around it. I will not duplicate the information here, if it is interesting, I provided a link to the article at the very beginning.
So, we have instructions,playful enthusiastic pens and some free time. Let's try it!
We collect a polygon from two virtual domain controllers running Windows Server 2012 Datacenter Edition.
The forest and domain level of Windows Server 2012. Both controllers are DNS servers and global catalog servers located on the same network segment.
We distribute the controllers to different sites:
After that, manually create duplicate AD DS Connections, push replication, and then delete the automatically generated connections.
Note! I strongly recommend replacing the connections in this order so that at least one pair of AD DS Connections exists between the controllers at any given time, otherwise replication may fail, at least for a while. For reliability, manually push replication after each change.
On the ReplTest-DC2 controller in the PowerShell window, run the script:
It will allow us in real time (once per second) to monitor the Up-To-Dateness vector change of the ReplTest-DC2 controller, highlighting from it a line related 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 manually initiated.
So, we made sure that replication works. We proceed directly to the verification of Jonathan's article.
Set the fourth bit of the Options attribute to one for the manually created AD DS Connection (for the sake of accuracy, I did this for both connections: from ReplTest-DC1 and from ReplTest-DC2).
Do not forget to push replication.
After that, edit the arbitrary attribute of an arbitrary object on ReplTest-DC1. For example, I changed the Description field of a recently created user.
We look at the state of replication on ReplTest-DC2:
Zero reaction! USN does not change!
We are waiting for five seconds ... nothing is changing, we are waiting for five minutes ... it is not changing again!
We are trying to perform a mirror operation: we make changes to AD on ReplTest-DC2 and track changes to ReplTest-DC1. The same result.
Several hours of various tests did not change the picture.
I admit, I expected this, because even then, on a beautiful spring morning, I had already done the same steps for the 2008 controllers.
This is sad, but at the moment I am forced to state:
“The method for enabling notifications for manually created AD DS Connections in the article by Jonathan Stevens does not work.”
Perhaps the article omitted some step or there are additional requirements, but the result is discouraging. I used to believe the articles of the AD DS team.
If respected colleagues have comments on the test or their results differ from mine, then please indicate in the commentswho the radish was, and if so, in what place.
I hope that together we get to the truth.
“Cool! - I thought then - I have to try. ”
In the certification courses on AD and in numerous articles we are informed that there are two types of replication: intrasite and intersite.
NBI hope everyone understands that we are talking about AD directory replication, which has nothing to do with Sysvol folder replication. And yet, if you have never heard of USN, KCC, Up-to-dateness Vector and other
Intrasite replication occurs “almost instantly” (in fact 5 seconds), intersite replication - “according to the schedule”, which is usually set in the SiteLink properties. The drawback 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 tells us in the Advanced Replication Management article.published at technet.microsoft.com. It turns out that changing a specific bit in the Options attribute of the corresponding SiteLink allows you to enable the Notification mode for AD cross-site replication. And the notification mode also determines the difference between the two types of replication. Great, we will have "instant" replication for all controllers!
Now back to the article by Jonathan Stevens. In it, he describes the reason for this restriction and a way around it. I will not duplicate the information here, if it is interesting, I provided a link to the article at the very beginning.
So, we have instructions,
We collect a polygon from two virtual domain controllers running Windows Server 2012 Datacenter Edition.
The forest and domain level of Windows Server 2012. Both controllers are DNS servers and global catalog servers located on the same network segment.
We distribute the controllers to different sites:
After that, manually create duplicate AD DS Connections, push replication, and then delete the automatically generated connections.
Note! I strongly recommend replacing the connections in this order so that at least one pair of AD DS Connections exists between the controllers at any given time, otherwise replication may fail, at least for a while. For reliability, manually push replication after each change.
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 in real time (once per second) to monitor the Up-To-Dateness vector change of the ReplTest-DC2 controller, highlighting from it a line related 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 manually initiated.
So, we made sure that replication works. We proceed directly to the verification of Jonathan's article.
Set the fourth bit of the Options attribute to one for the manually created AD DS Connection (for the sake of accuracy, I did this for both connections: from ReplTest-DC1 and from ReplTest-DC2).
Do not forget to push replication.
After that, edit the arbitrary attribute of an arbitrary object on ReplTest-DC1. For example, I changed the Description field of a recently created user.
We look at the state of replication on ReplTest-DC2:
Zero reaction! USN does not change!
We are waiting for five seconds ... nothing is changing, we are waiting for five minutes ... it is not changing again!
We are trying to perform a mirror operation: we make changes to AD on ReplTest-DC2 and track changes to ReplTest-DC1. The same result.
Several hours of various tests did not change the picture.
I admit, I expected this, because even then, on a beautiful spring morning, I had already done the same steps for the 2008 controllers.
This is sad, but at the moment I am forced to state:
“The method for enabling notifications for manually created AD DS Connections in the article by Jonathan Stevens does not work.”
Perhaps the article omitted some step or there are additional requirements, but the result is discouraging. I used to believe the articles of the AD DS team.
If respected colleagues have comments on the test or their results differ from mine, then please indicate in the comments
I hope that together we get to the truth.