Link-Pairs and Configuring Bridgeheads in ADAM/ADLDS
Published Apr 04 2019 03:15 PM 178 Views
First published on TechNet on Dec 02, 2009

Well, hello there AskDS readers. "Terrible" Tim Springston here with a little cross-posting blog action requested by my BFF Ned Pyle .

Occasionally we come across things that are not so well documented. One of those is the ADAM or Lightweight Directory Services series of steps needed to configure replication topology.

In Active Directory it’s a straightforward thing. You simply load up Active Directory Sites and Services ( DSSite.msc ) and you are given a nice and pretty graphical user interface that you can use to create sites, site links, select bridgehead servers and create replication connections. That’s not the case with ADAM/LDS-there is no snap-in designed to act like DSSite.msc for ADAM/LDS. We’ll chalk that up to being part of the “lightweight” aspect.

So how do you create your site topology if you don’t have that tool? Well, creating sites and site links at least is easy. In ADAMADSIEdit.msc you simply create the new objects and are prompted to fill in the attributes that must be present (these are the “must-contain” items defined for that class of object in the schema).

Selecting a bridgehead server - a server which will take care of inter-site replication between the specified sites in a sitelink - for two given sites is a little more difficult. Without a nice user interface we need to have a better understanding of how a server is shown to be the selected bridgehead server under the hood.

First, let’s go back to the concept of linked pair relationships . In Active Directory we have some attributes whose values have a relationship to an attribute on another type of object. The obvious example of this is the link relationship between the User class object memberof attribute and the Group class object member attribute. If you add UserA to GroupB then there is a link between their respective memberof and member attributes.

Here’s a graphic intended to illustrate that link pair relationship:

Also part of the link pair concept is the idea that there is a forward end of this link as well as a backward end of it. The forward end of the link is the part that, if populated or depopulated results in the backward end also being updated.   In other words, if we remove UserA from being a member of GroupB then that link is gone as well. In DSA.MSC that action would be removing the user from being a member of that group on the group object, and then checking the user objects member list and seeing that, yep, that’s been updated too.  In the case of memberof and member the forward link of this relationship is on the group object.

This linked value relationship is most often discovered by administrators as an unpleasant surprise following a disaster recovery.  Although we have excellent steps that will walk admins through the recovery process so that no problems are seen, if the steps aren’t followed then it’s possible for a user to be replicated inbound (following both that user and a given group’s deletion) before the group of which the user is a member.  Since the forward link of that relationship is not present, the link is removed.  The end result to the users in that circumstance can be email not delivered without distribution group membership or an “access denied” error to an object in the case of security groups.

But let’s refocus on our need to create a bridgehead server. Link-pairs are important in the act of specifying a bridgehead server or servers.  There is a link pair relationship between two attributes and that is how a bridgehead server is identified.

Those attributes are on two different objects. They are the bridgeheadTransportList attribute on the CN=<servename>,CN=Servers,CN=<sitename>,CN=Sites,CN=Configuration,DC=X object and the bridgeheadServerListBL attribute on the CN=<sitelinkname>,CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,CN=X object.

You can view these attributes in ADAMADSIEdit.msc. Here’s a snapshot of brdgeheadServerListBL:

As an interesting data point, we know that these two attributes have a link pair relationship because the MSDN schema definition of them says so-it shows bridgeheadTransportList as linkID 98 and bridgeheadServerListBL as linkID 99.  The even number of the bridgeheadTransportList linkID signifies that it is the forward link of the relationship. As an additional tip, the “BL” in an attribute name typically signifies that it is a back link of a link pair.

Now let’s apply what we have learned about selecting a bridgehead in ADAM/LDS.

Let’s say I have ADAM/LDS sites named LA, KC and NY and I want to specify the bridgehead servers for the LA to KC site link.  We are assuming that you have already created the site link object for LAtoKC which is easily done using ADAMADSIEdit.msc .

  • To select our bridgeheads we simply edit the bridgeheadTransportList attribute on the servers we would like to select to bridgehead servers for this link.
  • Specifically, for the LA site we would edit that attribute using LDP.EXE or ADAMADSIEDIT.MSC on the chosen LA DC’s object (which has a distinguished name like CN=LADC1,CN=Servers,CN=LA,CN=Sites,CN=Configuration,DC=X .
  • In the bridgeheadTransportList attribute you simply paste in the distinguished name of the sitelink object between the two sites.
  • We would likewise do this for a DC in KC as well-pasting the DN of the same sitelink into the bridgeheadTransportList attribute.

In this way we have told ADAM/LDS that these replicas are the selected bridgeheads for intersite replication for that site link.   You can verify that since the distinguished name of the respective DCs in KC and LA will then appear in the bridgeheadServerListBL attribute list on the site link as a result of the linked pair relationship those two attributes have.

Now you’re one step closer to customizing your replication topology sans a custom user interface for the job.

Tim “ Rick Roll ” Springston

Version history
Last update:
‎Apr 04 2019 03:15 PM
Updated by: