Hmm … first the question? How many of readers is aware of Linked Value Replication (LVR) in Active Directory? If what I think about readers of this blog is true probably majority of readers is very aware what this is and how it works. At the end I don't have any survey site to perform such survey so we will not get results. But for those who are newbies for AD or haven't read about LVR (and of course for search engines) I'm posting this following my Polish blog.
As everybody knows (but from time to time it's shows up that not everybody) Active Directory is working in mulitmaster model, which means that every DC is equal in terms of replication and changes to directory can be made on every DC at the same time. To maintain consistent data replication mechanism was put in place which is taking care about replication changes between DCs, solving conflicts etc. Replication is keeping AD in a consistent state, allowing it to operate. Replication is possible because for every object \ attribute some additional data about how it what and when it was changed is being kept by DCs. This is in very (VERY) simple words how it is working.
Active Directory introduced with Windows 2000 is keeping replication data at attribute level only. This means that if attribute has many values change in one of those values causes replication for whole attribute.
Most common example of this problem is replication of member attribute for Active Directory group. If we have group with 3000 of users and we will remove only one user from this group, without LVR whole attribute will be replicated which is 2999 values. Of course this is unnecessary overhead and that's why it was improved with Windows 2003.
Windows 2003 introduces new mechanism called Linked Value Replication (LVR) which can be enabled if forest is working in Windows 2003 mode. Idea behind this mechanism is to take replication data (metadata) one level lower for values of linked attributes, and store it for each value in such attribute. Linked attribute is special type of attribute in Active Directory which consist from two attributes for which Active Directory is maintaining connection (link and back-link), which means that if DN of an object will be added to one side (link) of such pair, Active Directory will automatically update other side (back-link) of this association. The same will happen if value will be deleted. Most known example of such attribute are group member (link) and user memberof (back-link) attributes. That's why if you want to add user to group from script or code You are adding user to group attribute, not group to user attribute. BTW linked attributes are pretty cool idea which isn't present in every LDAP directory on the market (as far as I know it is only present in AD).
So … with LVR we have replication metadata for every value in linked attribute, which are kept in msDS-ReplValueMetaData attribute. You can read this value with ldp.exe, script, code or any other tool which will give You an access to AD data.
So what will it change in our previously described scenario – if we would have group with 3000 values (LVR enabled) and we will remove one value, only fact of this value being deleted will get replication over the wire. Wow .. we are saving a lot of time and data for replication.
You can check this information for particular object using repadmin.exe tool with /showobjmeta switch. Below is an example how this looks for member attribute of some group.
We can see that we have replication metadata associated with every value of member attribute. But for one value we have this data empty and this value is marked as LEGACY. LEGACY is a way in which AD tags values added to attribute before LVR was enabled and for which replication metadata are not accessible. This values will be replicated in exactly the same way as in Windows 2003. Values for which Type is set to PRESENT are those which were added to attribute with LVR enabled, and replication metadata are hold for them. For this attribute one additional Type value can be found which is ABSENT. ABSENT tags values for tombstone objects – if user is being deleted it is turned into tombstone object. Corresponding values in linked values are marked as ABSENT and will get removed when this tombstone will be finally removed from directory.
This simplifies significantly process of restoring user deleted user objects and its membership, as ntdsutil.exe delivered with Windows 2003 SP1 can take advantage of this and when user object is being restored it can generate LDIF files which can be used to refresh linked attributes for this user. This procedure is described in KB 840001.
Looks great, but in practice values (group members) in environments which were upgraded from Windows 2000 and added when LVR wasn't available are still maintained as legacy entries. This mean that we can't take advantage of LVR replications and new mechanisms from ntdsutil for those users until this value will not get refreshed. Unfortunately there isn't any magic button which will say "Refresh values" and we have to deal with it on our own. Good news is, that this is very simple operation – we have to remove (sound scary, huh!) and add again those values (members) to attribute (member).
Using LDIFDE.EXE we can export group membership using following command syntax:
ldifde.exe -f file_name.ldf -s <DC> -b <group DN > -l member
which for group "CN=RAS Users,OU=Oddzialy,DC=W2K,DC=PL" will give us:
ldifde.exe -f ras_user_member.ldf -s ROOTDC -b "CN=RAS Users,OU=Oddzialy,DC=W2K,DC=PL" -l member
In this way we are getting export LDIF file which contains our members:
dn: CN=Domain Admins,CN=Users,DC=w2k,DC=pl
changetype: add
member: CN=jan tomaszewski,CN=Users,DC=w2k,DC=pl
member: CN=jkowalski,CN=Users,DC=w2k,DC=pl
member: CN=Administrator,CN=Users,DC=w2k,DC=pl
To make is slightly more useful for our pourpose, which is modify member attribute we have to modify it a little:
- change operation type to modify
- add directive to replace member attribute
- terminate it with '-' sign.
After changes it should look like this:
dn: CN=Domain Admins,CN=Users,DC=w2k,DC=pl
changetype: modify
replace: member
member: CN=Administrator,CN=Users,DC=w2k,DC=pl
member: CN=jan tomaszewski,CN=Users,DC=w2k,DC=pl
member: CN=jkowalski,CN=Users,DC=w2k,DC=pl
Now we can clean our group membership, just for example we will use admod.exe for this:
admod -b "CN=RAS Users,OU=Oddzialy,DC=W2K,DC=PL" member:-:
And now we have to import data about members of our group again with LDIFDE.EXE:
ldifde.exe -i -f ras_user_member.ldf
Now lets check this group again with repadmin.exe:
As we can see all values are marked right now as PRESENT which means that replication metadata are being present for these values.
Before going with this operation:
- make backup
- make and verify backup 🙂
- think about replication traffic it may cause – it shouldn't be significant but meaning of significant changes from environment to environment.