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: http://technet.microsoft.com/en-us/library/cc755994(WS.10).aspx â€“ 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â€):
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).
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:
What you probably donâ€™t know is how great the export-to-csv-function in repadmin is. A quick
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 http://technet.microsoft.com/en-us/library/dd736189(WS.10).aspx
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.