Report and Edit AD Site Links From PowerShell (Turbo Your AD Replication)

AD Replication in TRON terms

“The Grid. A digital frontier. I tried to picture clusters of information as they moved through the computer. What did they look like? Ships, motorcycles? Were the circuits like freeways? I kept dreaming of a world I thought I'd never see. And then, one day... I got in!” (Kevin Flynn, Tron Legacy)

Imagine Kevin Flynn as an AD admin. He would speak of AD replication, sites, and site links in terms of virtual vehicles. We could imagine high speed intra-site replication as light cycles and long-haul WAN link replication as a solar sailer. Back in Kevin’s day link speeds were nowhere near the bandwidth we have now.

Back then

Some of us implemented Active Directory shortly after release in the year 2000. Back then we had truly slow links. While those still exist in pockets today, most of our bandwidth has been seriously upgraded. Microsoft’s replication best practices have been upgraded as well.  Here is a somewhat dated article guiding you to “calculate a relative cost factor by dividing 1024 by the log of the available bandwidth as measured in Kbps”. Really? Some folks took this very seriously. Others of us didn’t like math and used round numbers like 100 for site link costs. And that is what we prefer in the field today. Link speeds for AD are really more about available bandwidth than total bandwidth anyway.

Fast forward to today

Active Directory site links have three key attributes governing efficiency: schedule, cost, and interval. They also have a feature called “change notification” that is not exposed in the GUI. The table below summarizes defaults versus today’s recommended practices:

	Default	Recommendation
Schedule	24 x 7	24 x 7
Cost	100	100 *
Interval	180 minutes	15 minutes
Change Notification	Disabled	Enabled *

* Tweaked as appropriate.

Many companies have upgraded bandwidth without updating AD replication topology. If it has been a while since you reviewed your AD site link topology, then today is the day. For starters, you can download the recently-updated Microsoft Active Directory Topology Diagrammer. This free tool will draw a Visio diagram of your sites and links. I use this all of the time as an audit tool to make sure that the site topology actually implemented matches the intended design.

Enter PowerShell

Next you can use the PowerShell one-liner below to create a quick report of your site links and relevant settings (after typing Import-Module ActiveDirectory):

Get-ADObject -Filter 'objectClass -eq "siteLink"' -Searchbase (Get-ADRootDSE).ConfigurationNamingContext -Property Options, Cost, ReplInterval, SiteList, Schedule | Select-Object Name, @{Name="SiteCount";Expression={$_.SiteList.Count}}, Cost, ReplInterval, @{Name="Schedule";Expression={If($_.Schedule){If(($_.Schedule -Join " ").Contains("240")){"NonDefault"}Else{"24x7"}}Else{"24x7"}}}, Options | Format-Table * -AutoSize

Author’s note: This one-liner got a little out of hand, because I had to account for the Schedule attribute either being blank (24x7) or non-blank (custom). However, if you set the schedule back to 24x7 after it was custom, then you have a non-blank value indicating 24x7. A quick way to distinguish the two non-blank values is that the number 240 will be present in the data if replication has been disabled for any block on the schedule.

Sample report output:

Name SiteCount Cost ReplInterval Schedule Options
---- --------- ---- ------------ -------- -------
Hub-Branch1 2 100 15 24x7
Hub-Branch2 2 100 15 24x7 5
Hub-Branch3 2 150 45 NonDefault
Hub-DR 2 50 15 24x7 1

As you look at the output do you find any oddball costs? Are any intervals over 15 minutes? Is the Options attribute blank or 1? Are any site counts not equal to 2? Are any schedules non-default? Any surprises? It may be time to turbo your site link settings from solar sailer to light cycle.

Here is what I would check for in this output:

Name	Is there a consistent naming convention? Suggestion: “HubName-SpokeName”.
SiteCount	We recommend that most site links should only contain two sites. Consider splitting multi-site-links into individual two-site links. It won’t hurt anything to have more than two in a link, but that should be the exception. If you see a SiteCount of 1, then that is likely an orphaned site link that can be deleted.
Cost	Use round numbers like 50, 100, 150, 200 for costs to make the math easier at a glance. Use the default site link cost of 100 for most links, and then tweak it down to 50 between hub sites and up to 150 for those really slow links.
ReplInterval	180 is the default. 15 is the recommendation. Contrary to popular opinion you actually want to use lower intervals on slow links for several reasons. The amount of data transfer is the same, and long intervals cause a larger bandwidth spike. If a replication cycle fails, then a short interval means that the site won’t have to wait so long for the next retry.
Schedule	These days I rarely find companies using custom schedules. Consider using the 24x7 schedule unless you have a compelling network justification.
Options	This value will likely be either blank or "1" or "5". If it is blank, then change notification is not enabled. If "1" or an odd number then it is enabled. Consider using change notification if you have plenty of available bandwidth for the sitelink.

Kick in the turbo

In order to convert your replication Solar Sailer into a Light Cycle you should do two things:

1. Drop all site link intervals to 15 minutes.
2. Enable change notification on all site links.

If you have any intervals over 15 minutes can you really justify them? If not, I would recommend dropping them to the minimum value of 15 minutes. Enabling change notification treats an INTER-site replication connection like an INTRA-site connection. Replication between sites with change notification is almost instant. For example, if your site topology is three hops long, then you can take your AD convergence time from a maximum of 45 minutes down to less than 2 minutes. Then when the helpdesk resets a password or updates a group membership the user doesn’t have to wait 30 minutes for replication! Enable change notification on any links that have good available bandwidth, especially between your hub sites.

Where do I enable change notification?

Like I said earlier you will not find a checkbox for change notification in the site link GUI. Normally you have to navigate through ADSIEDIT or use the Attribute Editor tab in 2008. Site links are stored in the Configuration partition of the AD database here:

CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=contoso,DC=com

Here you will find a list of siteLink class objects. Look at the properties of a site link and you will see an attribute called options. 99.9% of the time this attribute is empty. To really understand what this attribute does you can read the Active Directory Technical Specification (available in HTML or PDF). It is defined here:  7.1.1.2.2.3.3 Site Link Object. You will find that the options attribute is a bit switch with three settings:

• UN (NTDSSITELINK_OPT_USE_NOTIFY, 0x00000001): If present, enables replication notifications … between DCs in different sites in the siteList.
• TS (NTDSSITELINK_OPT_TWOWAY_SYNC, 0x00000002): If present, forces a replication cycle in the opposite direction at the end of a replication cycle between DCs in different sites in the siteList.
• DC (NTDSSITELINK_OPT_DISABLE_COMPRESSION, 0x00000004): If present, disables compression of the implemented server-to-server replication protocol response messages sent between DCs in different sites in the siteList.

To enable change notification we set the options attribute to 1. If there is already a value assigned, then we make it an odd number by adding 1 to it, representing the first bit. This setting takes effect after the next KCC run (within 15 minutes, no reboots or service restarts required). A better recommendation is to set options to 5 (1 + 4); this enabled change notification and disables compression of the traffic. This is better, because the compression activity burns CPU cycles on the bridgeheads. By disabling the compression we reduce the load on the DCs.

Now your DC changes notify the DC bridgehead in the next site on the intrasite notification schedule (15 seconds/3 seconds) instead of waiting 15 minutes. How cool is that!

Author's note: Use care when enabling change notification, especially in large environments. If the bridgeheads in the hub sites have too many connections with change notification it could cause performance issues. Consider limiting change notification to hub-hub and hub-DR site links in those cases.

What if I have 100 site links?

Afterall this is a PowerShell blog, so let’s get to the good part. I’ve taken you down this long-winded path for a big finish with another one-liner. This code uses the power of the pipeline to send a GET into a SET. We can use PowerShell to set the cost, interval, and change notification (or any combination of those attributes) of all site links at once.

Get-ADObject -Filter 'objectClass -eq "siteLink"' -SearchBase (Get-ADRootDSE).ConfigurationNamingContext | Set-ADObject -Replace @{Cost=100;ReplInterval=15;Options=5}

The above line of PowerShell will set all site links to cost of 100, interval of 15, and enable change notification. If you don’t want all of those attributes set, simply remove the attributes and values you don’t want from the end of the line. For example, this version would only change the interval to 15 minutes on all site links:

Get-ADObject -Filter 'objectClass -eq "siteLink"' -SearchBase (Get-ADRootDSE).ConfigurationNamingContext | Set-ADObject -Replace @{ReplInterval=15}

If you want to narrow the impact, then edit the Filter switch to grab a single site link or match a wildcard on the name. Like this:

Get-ADObject -Filter 'objectClass -eq "siteLink" –and name –like "*foo*"' -SearchBase (Get-ADRootDSE).ConfigurationNamingContext | Set-ADObject -Replace @{Options=5}

This one-liner will reset all site link schedules to 24x7:

Get-ADObject -Filter 'objectClass -eq "siteLink" –and schedule -like "*"' -SearchBase (Get-ADRootDSE).ConfigurationNamingContext | Set-ADObject -Clear Schedule

After running these updates go back and use the one-liner at the beginning of the article to validate your changes.

Conclusion

Hopefully this post has inspired you to revisit your replication topology and site links. You've got the bandwidth. Why not leverage it? Now go take your light cycle for a victory lap.

.end of line

# ><>

Site_Link_One_Liners.p-s-1.txt

Comments

• Anonymous
  September 22, 2011
  You should add options=5, no compress but notify anyway :)

• Anonymous
  September 23, 2011
  Thanks, Rob.  I've updated the post.  I remember our conversation around this setting.  :-D  We've seen performance issues in large environments where change notification is enabled while leaving compression enabled.  5 is better than 1.

• Anonymous
  March 23, 2012
  Do you know what will be the option, to remove all options ? I've try Options=0 which seems to work, but when going to the Attribute Editor, it shows 0 instead of <Not Set>. Any idea ?

• Anonymous
  March 26, 2012
  The comment has been removed

• Anonymous
  May 08, 2012
  Hi. Nice article. Just curious though, if inter-site change notification is enabled, does the replication interval still serve a purpose?

• Anonymous
  May 08, 2012
  Hi Paul, To my knowledge once change notification is enabled the replication interval does not really serve a purpose for AD replication.  While other protocols may reference site links and costs (DFS, for example) I am not aware that they use the interval.  FRS for SYSVOL replication has its own interval.  DFSR, unlike FRS, will pay attention to the change notification and replicate SYSVOL faster. Hope this helps, Ashley

• Anonymous
  March 05, 2014
  With 237 Sites where I needed to change the interval from 30 to 15 minutes this has saved me a lot of mouse clicks. Thank you.

• Anonymous
  April 18, 2014
  Hi Ashley,
  
  First off, GREAT post!
  
  But I have a question regarding one of your statements. You say to enable change notification on any site links that have good available bandwidth. But what's considered good?
  
  We have about 42 site links in my organization with site connections anywhere from 3 mb to 250 mb. Are the lower 3 to 6 mb sites fast enough for change notification, or should I leave this for the sites with 100 mb or higher connections?
  
  Thanks in advance for the reply!
  
  Chris

• Anonymous
  April 22, 2014
  Hi Chris,
  Great question. Three things to consider:
  1. The real story is about available bandwidth. If you have a 3mb link that is wide open and a 100mb link that is saturated... you get the idea.
  2. You should also consider how many DCs are on either side of the link. If you have a 3mb link to a branch office with a single DC, then you are usually OK. If you have a 3mb link with 50 DCs on each side, then you will need to do some benchmarking with the network team to gauge the impact.
  3. Change notification is directly linked to frequency of changes which is usually affected by how many objects you have. If you have 200,000 users, then changes are constantly flowing. If you have 200 users, then the pace of change is much less.
  It really comes down to a conversation with your network team to see how the link is performing before and after the change. Hope this helps.
  Ashley
  @GoateePFE

• Anonymous
  September 26, 2014
  To get an idea of Replication data volumes you can always have a look at the following performance counters (before you speak to your network team :)
  
  DirectoryServices()DRA Inbound Bytes Total Since Boot
  DirectoryServices()DRA Outbound Bytes Total Since Boot
  DirectoryServices()DRA Inbound Bytes Not Compressed (Within Site) Since Boot
  DirectoryServices()DRA Inbound Bytes Compressed (Between Sites, Before Compression) Since Boot
  DirectoryServices()DRA Inbound Bytes Compressed (Between Sites, After Compression) Since Boot
  DirectoryServices()DRA Outbound Bytes Not Compressed (Within Site) Since Boot
  DirectoryServices()DRA Outbound Bytes Compressed (Between Sites, Before Compression) Since Boot
  DirectoryServices()DRA Outbound Bytes Compressed (Between Sites, After Compression) Since Boot
  

• Anonymous
  October 29, 2014
  Welcome! Today’s post includes demo scripts and links from the Microsoft Virtual Academy event: Using PowerShell for Active Directory . We had a great time creating this for you, and I hope you will share it with anyone needing to ramp up their

• Anonymous
  December 21, 2016
  This would be great if it actually worked.

• Anonymous
  January 04, 2017
  The comment has been removed

• Anonymous
  February 15, 2017
  Great article! In your Author's notes you mention limiting change notification in large environments. What would you consider a large environment or "too many connections"? We currently have three hubs. On the largest hub, with 15 spokes, is it okay to have change notification on each spoke? This hub also talks to two other smaller hubs that do not have CN enabled. I'd like to enable it on those links as well. The two other hubs have less than ten spokes each.

  • Anonymous
    February 15, 2017
    The comment has been removed