Inspecting AD replication facilities with LDAP searches

I’ve come to think about what the most challenging things for AD admins out there are. There are highly sophisticated problems like RODC mass deployment, Schema enhancements with own attributes and object classes and AD/Exchange migrations – no question, those are tough topics. I was thinking about more day-to-day challenges you might encounter and tried to remember the topics I had a hard time with. One of those was AD replication. Understanding the AD replication process, the vectors and metrics is one thing. Understanding and checking replication intra and inter site is another. Although both go along together, you don’t necessarily need to know the numeric calculation behind the logical representation you might be interested in as an AD admin.

So in this post, I’m going to look at the facilities that we need for rep to work correctly and how you can check on them (both in the UI as well as on the CMD line and LDAP “scripting”). I’ll not explain what every facility is there for – for that, there’s a wonderful whitepaper on TechNet I recommend you read and pin to your wall: – if you read it and still don’t get the pieces that make AD’s rep topology, you probably haven’t read it carefully.


Inter site rep is made of sites that are connected through site links. The UI for this is dssite.msc (Active Directory Sites and Services) you should be familiar with. In “Sites”, there are your sites listed and in “Inter-Site Transports”-“IP”, the site links that connect the sites. You need to look up the site link, check what sites are involved in the replication over this link and, after that, look at the sites and see what DCs they host. From an cmd/LDAP perspective, you’d search for “siteLink” objects and let your favorite browser (I use ADfind here) output some interesting attributes (“name”, “cost”, “siteList”, “replInterval”):

adfind -config -f “objectClass=siteLink” -nodn name cost siteList replInterval

Make sure you target the “Configuration” partition when you search – the whole configuration of sites and services is stored there. That makes sense, because all DCs in the forest need to be aware of the replication topology – they share the Schema and the Configuration they need to replicate as well as Global Catalog info. My output looks like this:

and matches the dssite.msc output. Great! Now let’s find the DCs for a given site (I use the “Default-First-Site-Name” site):

adfind -b “CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=intern,DC=frickelsoft,DC=net” -f “objectClass=server” -nodn name

I used the Default-First-Site-Name in the “Sites” Container in the Config partition as the base for my search and let ADFind look for server-Class objects. Browsing in ADSIEdit led me there. Can we combine the two statements above? Yeah, ADfind can:

adfind -config -f “objectClass=siteLink” sitelist -list | adfind -s subtree -f “objectClass=server” name

leads us to all DCs in all our sites. That may not be too interesting here but given the fact that we *could* put other filters to our first search term before the pipe limits the outputs on our DCs:

adfind -config -f “&(objectClass=siteLink)(cost<=100)” sitelist -list | adfind -s subtree -f “objectClass=server” name

So that query first filters for site links that have a cost less than 100 (= faster lines), computes a list of sites that belong to these site links and pipes out all DCs that are in there. Cool thing!
Okay, now let’s look further into our topology. We know that we have so-called ISTGs in our domain, Inter-Site Topology Generators, that is one DC per site. This DC calculates the rep topology and elects one or more DCs that handle inter-site replication. That can be one DC for all NCs (if there’s only one domain, then Domain, Schema and Config can be transferred all at once) or multiple DCs if there are multiple domains and GC partitions to be replicated among sites. Those elected DCs are called “bridgehead servers”. You heard that before. You can also specify custom bridgehead servers if you like – that’s on a DC’s properties in “Sites and Services”. On the “General” tab, there are two boxes, “Transports available for…” and “This server is a preferred bridgehead server…” you can move the transports around. If you select a transport for the DC, you make it a “preferred bridgehead”. ISTG won’t touch that then. A problem with custom bridgehead server is that, if they fail, you don’t have a fail over automatically. Though you can specify multiple bridgehead servers, if all of them fail, ISTG won’t come help you out by electing another one, it’ll simply ignore that fact and … rep might be broken for an NC to a site. (I’ll have another post on that, I think).

In order to find our ISTG, we need to get an attribute of our site’s NTDS Settings object which is called “interSiteTopologyGenerator“.

Pretty clever name:

adfind -config -f “(cn=NTDS Site Settings)” interSiteTopologyGenerator –nodn

That’ll give us our ISTGs for our sites. Easier though is using the REPADMIN tool that is loaded on every DC from Server 2003 on. The command is “repadmin /istg” and displays the ISTGs for all sites given.
Next, we’d probably want to find our bridgehead servers that are defined. There’s another repadmin command we can use, it’s “repadmin /bridgeheads”.

That lists all the bridgeheads and their NCs. You can check what with ADSIEdit, if there are any preferred Bridgehead Servers defined. For that, you browse to the “CN=IP,CN=Inter-Site Transports,CN=Sites,CN=ConfigurationDC=domain,DC=tld” object and inspect its bridgeheadServerListBL attribute. The list shows you the preferred Bridgehead Servers that you chose. Don’t worry if the attribute isn’t there, it is a linked attribute and ADSIEdit might not show it. You can click “Filter” and choose Backlinks to be displayed. If the attribute is <Not set> then ISTG picks the Bridgehead for you and there’s none set manually (which most of the time is a good thing). If you need the bridgeheads, you should get them from “repadmin /bridgeheads /verbose”.

Checking replication health is essential. You probably know how to use the EventViewer for this and repadmin:
“repadmin /showrepl”.
What you probably don’t know is how great the export-to-csv-function in repadmin is. A quick

Repadmin/showrepl * /csv > myCSV.csv

exports the data to CSV. You can import that in your favorite calc app (Excel is mine) and get a beautiful output like this:

Errors in rep configuration sometimes aren’t easy to see from the /showrepl output alone so an Excel export is a good thing. Looking at my export, I should probably look after EXTRA-DC and see why it fails to replicate in changes of _all_ NCs. Hum…

Looking at your replication topology again, you might be interested in whether BASL is enabled or not. BASL is “Bridge all site links” and basically tells the KCC whether the network is fully routed or not. If all DCs can reach any other DC, BASL should be enabled. If not, you should think about disabling BASL and creating custom site link bridges where needed. See

To get to know whether BASL is enabled or not, you right-click your “IP” node under “Inter-Site Transports” again and choose “Properties”. There’s the checkbox. In order to script/LDAP-ask that, you’ll again need to bind to the IP object:

adfind -s base -b “CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=intern,DC=frickelsoft,DC=net” options

The value for “options” it puts out is a bitmask for the two check boxes on the UI. Bit 0 is “Ignore Schedule” and Bit 1 is “Bridge all site links”. So when clearing or setting the checkbox, Bit 1 of the options bitmask is set/unset which results in a value change of “2”. Clearing the checkbox (=disable “Bridge all site links”) sets the bit (= option attribute value increases by “2”). Setting the checkbox (=enable “Bridge all site links”) clears the bit (=option attribute value is decreased by “2”).

Heck, that was a load of commands and replication settings we’ve run through. We better take a break and focus on something more readable next time.

No Comment