In my last blog post, I talked about using a REPADMIN command to quickly stop the replication of changes you don’t want to spread around the forest (“The ‘Oops’ Command: Minimizing Object Deletion Damage”). This made me think of a tuning parameter you can use to speed up replication to the far corners of your forest. As with any tuning knob, however, it has its tradeoffs.
The tuning parameter is to enable change notification for intersite links between AD sites. By default, AD updates are replicated between sites on a scheduled basis. This schedule is determined by the replication interval you set on your site links. The default interval is three hours, but most people I’ve ever talked to crank it down to its minimum setting of 15 minutes. As a result, when there’s an AD change at any particular DC – for example, granting a user access to a network resource by adding them to a security group – that change may take some time to affect the user if they’re several sites away from where the change was made.
The large intersite change intervals in Active Directory were designed in the late 90’s, a time when the Internet was still in its infancy. “Going online” was a special effort, Google was barely heard of, and most user connections were via dialup modem. Company WAN connections today have far more bandwidth and are far more robust today. AD’s replication traffic is a tiny mote on the radar compared to employee YouTube surfing through the corporate gateway.
With change notification enabled, an update will replicate across its entire directory partition (domain-wide or forest-wide, depending on the partition) as if it were all one site. Why should you even have sites if you’ve enabled change notification, you may reasonably ask? For two reasons. First, your site topology will still influence how DCs will replicate with one another, in other words how connections objects will be set up between sites. The topology just won’t influence when DCs replicate with one another. Second, Active Directory isn’t the only customer of your site topology. Exchange, DFS Namespaces, System Center, and a host of third party applications depend on the site topology.
The best reason I know to not enable change notification on all your site links is because it takes away the lag time between you noticing an accidental change to AD (such as an OU deletion), and running the “oops” command to stop the change from replicating outside the site containing the originating DC.
Tony Murray, fellow MVP and Keeper Of The ActiveDir Mailing List, has written a nice post on how to enable change notification for intersite links, and what updates are (and aren’t) affected by this change.
Follow Sean on Twitter: @shorinsean
Subscribe to Sean's Windows IT Pro articles: RSS
