Active Directory Replication: Change Notification & You
**UPDATE: One of our readers has kindly pointed out the correct intra-site replication interval of 15 seconds - Jimmy**
'Normal" Active Directory replication occurs almost immediately between replication partners in the same site (15 seconds after the change is made). 'Normal Replication' between different sites (say Canberra and Dallas) occurs per schedule with the smallest configurable value being 15 minutes. This post discusses an option to enable replication between sites to occur almost immediately as if the replication partners shared the same site.
I’m sitting with an Active Directory replication expert this week as part of my internship in the Texas escalation team.
One of the things they get you to do on your way to becoming a Subject Matter Expert (SME) for a component is to work through the deep training on each of the knowledge levels associated with that component. One of the Level 200 tasks the AD replication SME’s get is to "document a replication component".
The idea is that when you write it down it commits to your memory better than it would by just reading it. I definitely find that when I just read something unless I use it soon it will go in one ear and out the other. So this is definitely worth a shot. I was given “Inter-site Change Notification” as my item to document, so here we go:
* We won’t go into the ins and outs of general level 100 active directory replication – its covered well on TechNet already, but keep in mind that normal replication within a site starts 15 seconds after a change is made to the directory. (Windows 2000 was 300 seconds, but we don’t talk about Windows 2000 anymore). Outside of a site, replication is per-schedule. The smallest value you can choose for your inter-site replication schedule is 15 minutes. All of the details of this are well documented in the TechNet library: https://technet.microsoft.com/en-us/library/cc961788.aspx
Is it possible to have your changes replicate quicker than every 15 minutes between sites?
Yes. Manually speaking you can use Repadmin.exe (with the /replicate switch). Or you can use the sites and services console (“Replicate
Now”).
Errm… Automatically?
Also yes. You can use a feature called “Inter-site Change Notification”. Inter-site change notification tells the replication engine to treat the link as if it was in the same site. That is, notify the replication partners of the change rather than wait for the replication interval to pass (minimum of 15 minutes).
In my lab, I will enable this feature between the Texas and Canberra sites. (I should have chosen better names, enabling this feature between Texas and Canberra might not be the best choice given the probable latency on the link. The feature is designed for low latency links where extra replication data is not an issue – in my lab; they are on the same switch).
My lab looks like this:
To enable change notification between sites:
1. In ADSI Edit, expand the Configuration container.
2. Navigate to the Inter-Site Transports container, and select CN=IP. (You cannot enable change notification for SMTP links.)
3. Right-click the site link object for the sites for which you want to enable change notification, and then click Properties.
4. In the Select a property to view box, select options.
5. In the Edit Attribute box, if the Value(s) box shows <not set> , type 1 in the Edit Attribute box. If the Value(s) box contains a value, you must derive the new value by using a Boolean BITWISE-OR calculation on the old value, as follows: old_value BITWISE-OR 1. For example, if the value in the Value(s) box is 2, calculate 0010 OR 0001 to equal 0011. Type the integer value of the result in the Edit Attribute box; for this example, the value is 3.
6. Click OK.
There is also a script available on the TechNet script gallery: https://gallery.technet.microsoft.com/scriptcenter/61cb88bb-8c61-477f-834e-79ed0c153669
Enabling change notifications across site links propagates all change notifications. With change notification between sites set, changes propagate to the remote site with the same frequency that they are propagated within the source site, including changes that warrant urgent replication.
So when should I do this?
The answer is: it depends. Start with the obvious, that is – when you need replication to occur between sites according to change notification rather than schedule (15 minutes minimum). When you are considering this point, you have to also consider if the sites should just be merged together. Often the answer is no, because the sites represent logical separation and other applications depend on this separation, but it is something to consider. You wouldn’t want to enable this on links that are not connected well, or have high latency – lots of replication attempts means more chance of failure, more chance of failure potentially means more time the kcc is changing replication connection objects and trying to work around failures. Also, you lose the compression that is usually applied to your inter-site replication on that link, so there are more bits crossing the link. Generally speaking you would like to have LAN-like connections between sites before you use this. Low latency is the key.
How can I tell?
If you don’t know if change notification is on, you can see it per link using ADSIEdit as described above. The GUI actually translates the bits in the options attribute and you should see USE_NOTIFY as the value, or {SOMETHING_ELSE} | USE_NOTIFY if multiple values have been added with a bitwise operation.
Can you show me the packets so I can see how this works?
Sure. But to be honest, you will know if it’s working when changes are replicated as soon as you make them to the other site. Normal behaviour is to replicate on the cycle (15 minutes minimum interval).
If you are using Netmon, the change notification will look just like it does between servers in the same site. This snip shows the change notification between DC2 and DC3 (different sites):
And in the same site (DC1 and DC2):
Important Tip:
Change notification will fail with manual connection objects. That is, if you connection objects are not created by the KCC as below:
I learned this the hard way while attempting to force predictable replication for a netmon trace.
I hope this has been useful to someone. I have to admit, learning a component this way makes it really stick and forces you to think about all the if’s and but’s around the topic. I like it.