Leverage LVR to Simplify AD Object Recovery

Upgrading to Windows Server 2003 requires this additional step

Executive Summary:
The Microsoft Windows Server 2003 Linked Value Replication (LVR) feature helps you recover accidentally deleted Active Directory (AD) data. Upgrading from the Microsoft Windows 2000 operating system (OS) to the Microsoft Windows Server 2003 operating system (OS) doesn’t automatically enable the Linked Value Replication (LVR) feature. To enable the Microsoft Windows Server 2003 Linked Value Replication (LVR) feature, you need to convert Active Directory (AD) domains from Microsoft Windows 2000 to Microsoft Windows Server 2003 forest functional level, update Microsoft Windows Server 2003 domain controller (DC) link tables, and update legacy links in the Active Directory (AD) forest.

In an ideal IT world, no user or administrator would make mistakes. More specifically, they'd never delete any data they still needed. But accidents do happen—typically, much more often than we'd like. Restoring accidentally deleted data on a network computer is a trivial task if you have a valid backup that contains the data. Recovery is fairly simple for data such as a file or folder deleted from one of your file servers. However, data stored in Active Directory (AD) is typically replicated across multiple domain controllers (DCs) and is more difficult to recover.

Windows Server 2003's Previous Versions feature simplifies file and folder data recovery by leveraging the new Volume Shadow Copy Service (VSS), which lets you create snapshots of your shared file-system data at periodic intervals. Using this feature to recover an accidentally deleted file is as simple as right-clicking a folder to show its properties, selecting the Previous Versions tab, and viewing the folder's contents prior to the incident. Although Microsoft hasn't quite replicated this functionality for AD, Windows 2003 has various powerful new AD features, one of which is particularly helpful in recovering AD objects during an authoritative restore: Linked Value Replication (LVR). (Note: Microsoft has implemented additional features for the upcoming Windows Server version, Windows Server 2008, which will give AD administrators a similar experience for AD objects as the Previous Versions feature for files. You'll be able to open snapshots of the AD database as a separate offline instance, then use those instances to read data from previous versions of the objects.)

In this article, I describe the challenges AD administrators face when they need to recover accidentally deleted objects in their AD domains and how correctly leveraging the Windows 2003 LVR feature can help. This feature is especially important for companies that previously deployed their AD forest on Windows 2000, then upgraded to Windows 2003. In this case, administrators need to perform some extra work before they can take advantage of LVR's special benefits during object recovery.

What Is LVR?
Before you can understand the benefits of LVR for recovery of AD objects, you must first understand how AD stores and replicates data, because this information is crucial to understanding the recovery process. As its name implies, LVR is a feature that improves the replication of linked values between objects in AD. Objects in AD are linked in many ways—the most well-known example is the linkage maintained to store the relationship between user and group objects. As Figure 1 shows, each group object has an attribute called member that references the distinguished names (DNs) of the group's members (such as users, computers, or other groups), and each user object has an attribute called memberOf that references the DNs of groups the user is a member of. In my example, John in the OU-Users organizational unit (OU) is a member of MyGroup in the OU-Groups OU.

Although you can view the DNs contained in a group's member attribute when using LDAP tools such as adsiedit.msc or ldp.exe, the DNs aren't actually used to store the links in AD. If they were, you'd have problems when renaming or moving objects, because these activities also change an object's DN. In reality, the AD database consists of a data table and a link table. All objects of all naming contexts hosted by a specific DC are stored in the data table, along with their DNs and a unique identifier called distinguished name tag (DNT), a 32-bit unsigned integer that doesn't support reusability.

To store links (references) between objects, the link table uses only the DNTs of the objects, which are then resolved to the correct DN of the object, when reading the respective linked attribute via LDAP. This method essentially maintains referential integrity of the objects and their respective links. To reference parent-child relationships such as required for the OU hierarchy, AD uses a column called parent distinguished name tag (PDNT) in the data table. As you'd expect, the PDNT contains the DNT of the object's parent. Figure 2 is a simplified example of the AD database tables, showing that the user John is a member of the MyGroup group. If you look closely, you'll notice that Mary is also a member of this group and that she is John's manager.

An important difference exists between the two links that make up a link pair: Only the forward link (in my example, the member attribute of a group) can be edited by administrators, and only this link is replicated to other DCs in the domain or forest. The back link (memberOf in my example) is owned and maintained by each DC individually and isn't replicated. I'll come back to this crucial piece of information when I discuss the recovery process.

The Microsoft Management Console (MMC) Active Directory Users and Computers snap-in is somewhat misleading, because it lets you open the properties of a user object, then add a group to the user via the Member Of tab. In reality, the actions you perform in this UI actually update the linked-value pair's forward link (i.e., the member attribute of the respective group), and the DC creates the back link from the group to the user's memberOf attribute, as this UI shows. This also explains why an administrator doesn't need special permission to manage a user to add him or her to a group in AD—instead, write permissions to the group's member attribute are required.

In the context of AD recovery, the links between users and groups are most important to us because of their function of granting or revoking access to resources in an infrastructure. (For more information about other linked values, see the Web-exclusive sidebar "Determining LinkedValue Pairs in the Active Directory Schema," http://www.windowsitpro.com, InstantDoc ID 96311.) Another important thing to understand is that AD differentiates between single- and multi-valued attributes. It's no surprise that both the group's member attribute and the user's memberOf attribute are multi-valued—which ensures that a user can be a member of many groups and a group can have multiple users (and other objects) as group members.

The Smallest Unit of Replication
In a Win2K AD domain, the smallest unit of replication is an attribute. When Win2K was released, this fact was a great advancement from Windows NT 4.0, in which the smallest unit of replication is an object. However, Win2K DCs treat all attributes equally—regardless of whether an attribute contains only a few bytes or many thousand bytes. This replication mechanism is particularly challenging for multi-valued attributes such as a group object's member attribute, essentially causing the following two problems.

  1. Excessive Replication Data and Limited Number of Group Members—If a group has 999 members and an administrator adds another member to the group, a Win2K DC will replicate the complete member attribute to its replication partners (i.e., the list of all 1,000 members). But because an update to the AD database must be written in a single transaction that's limited to the size of a multivalued attribute with approximately 5,000 values, Win2K's AD doesn't support groups with more than 5,000 members. To work around this problem, companies with more than 5,000 users have implemented group-nesting mechanisms to keep the number of members below the supported maximum.

  2. Loss of Changes—The Win2K replication mechanism leads to potential loss of group changes when two administrators add a different user to the same group on different DCs in the AD domain. If this happens at roughly the same time (i.e., before either change can replicate successfully to the other DC), one of the changes is lost. Ensuring that all administrators perform group changes on the same DC helps as a workaround to this problem.

The Windows 2003 LVR feature is one of the key changes in the way that AD replicates specific data. This feature is available only when your AD forest operates in either of the following forest functional levels:

  • Windows 2003 interims—For NT 4.0 upgrade scenario; allows existence of NT 4.0 DCs in forest, but no Win2K DCs

  • Windows 2003—All DCs in forest must be running Windows 2003; neither NT 4.0 nor Win2K DCs are allowed

When you perform an in-place upgrade of your Win2K AD forest, your forest functional level doesn't change automatically—the forest will run in Win2K functional mode, which doesn't support LVR. Even when you implement a brand-new AD forest using a Windows 2003 DC, the default forest functional level is set to Win2K. To raise the forest level to Windows 2003, you must first switch all the domains in the forest to the Windows 2003 domain functional level.

You can use the MMC Active Directory Domains and Trusts snap-in to check your domain and forest functional levels. To raise the forest functional level, right-click the top node called Active Directory Domain and Trusts, and select Raise Forest Functional Level from the context menu, as Figure 3 shows.

After your AD forest is successfully switched to the Windows 2003 forest functional level (which is an irreversible process and should thus be planned accordingly), the LVR mechanism is activated. For confirmation of this switch, see event ID 1695 in the NTDS event log of each DC in your forest.

LVR changes the smallest unit of replication: Each value in multi-valued attributes that are linked to other attributes will now replicate separately as the value is added to or deleted from the attribute. So if for example a user is added to a group that already contains 999 members on one DC, only the addition of that one user is replicated to the DC's replication partners in the domain. Similarly, the removal of a user from a group only replicates this status change of the link between the user and the group, instead of replicating all group members. LVR thus solves the two issues I previously described for the Win2K replication mechanism for multi-valued attributes:

  • Unlimited Number of Group Members— Besides lowering the utilization of the network when replicating group changes, LVR has the great benefit that it effectively removes the upper limit for the number of members in a group. LVR is fully supported to have groups in a Windows 2003 AD with millions of members! However, the update to the AD database must still be written in a single transaction, which means that you shouldn't add or remove more than 5,000 members to a group in one operation. If your AD has automated group management, you should ensure that your provisioning or group management systems understand this limitation.

  • Ensuring Integrity of Changes—Because the changes in group memberships and other linked values are replicated separately, changes to the same group performed at the same time on different DCs won't get lost.

Changes in the AD Database Tables
To enable LVR, the link table on DCs running Windows 2003 requires some updates. Similar to objects in the data table, linked values now require extra metadata, including an update sequence number (USN) to control replication. The USN is updated to the next available value for any changes made to an object's attribute or a linked value in the AD database, which allows a replication partner to request replication of only those changes that it doesn't yet know of. But more importantly, the new metadata in the link table also defines the status of a link, which can be one of three LVR link types:

  1. Legacy—Link that's still stored in the old format with all values stored and replicated in a single blob; only contains "active" links.

  2. Present—Link that's stored in the new LVR format and "active" (e.g., a normal member of a group).

  3. Absent—Link that's stored in the new LVR format and "deleted" (e.g., a user whose membership was removed from a group).

You can use the Windows Server 2003 Support Tools command-line tool Repadmin to view the status of the links in your groups. To retrieve the status information for a group called MyGroup on a DC called DC1, use the following command:

C:\repadmin /showobjmeta DC1 CN=MyGroup,

Figure 4 shows the output from this command. As you can see, John and Mary were members of the group before LVR was enabled in the forest, and Peter was added to the same group later on. An important thing to understand is that even when you enable LVR in your forest, the links that existed in AD before you switched to the Windows 2003 forest functional level won't automatically update to LVR links. Instead, they'll remain in the AD database as "legacy" links, which usually isn't a problem because new links will still be stored as LVR links and thus the replication benefits are immediate. However, LVR links have another benefit that requires the links to be stored in "true" LVR format.

Benefits of LVR for AD Object Recovery
There's more to LVR than meets the eye—it not only improves normal replication of linked values, but it also improves recoverability of the links, in case you want to recover accidentally deleted objects in your AD domains. Recall what I said about the back links and forward links at the beginning of the article: Only the forward links are replicated between DCs in an AD domain. So, if you forced replication of a user object with all of its attributes, everything would replicate except for the back links referenced from the object. However, you couldn't replicate the user's group memberships, because the memberships are stored in the user's back-linked memberOf attribute.

When you use the native OS methods to restore an object, you basically force replication to occur. For example, after you boot into the Directory Services Restore Mode (DSRM), you'd restore the AD database via the system state backup from tape or disk on one of your DCs. Then—before reboot—you'd run the Nt-dsutil command to perform an authoritative restore. An authoritative restore can be done for a whole subtree or for a single object and effectively increases the version number of all attributes of the object(s) to be recovered by 100,000 (per day of age of the backup). For more details on this process, see the Microsoft article "How to restore deleted user accounts and their group memberships in Active Directory" (http://support.microsoft.com/kb/840001).

In a Win2K AD forest, an authoritatively restored user wouldn't replicate its group memberships to other DCs in the domain. You'd need to manually repopulate the user's group memberships or leverage a tool such as Groupadd. Windows 2003 SP1 makes the recovery process of group memberships and other linked values a bit easier because it creates LDAP Data Interchange Format (LDIF) files during the authoritative restore process, which then let you import the group memberships after reboot. However, all these steps can take a considerable amount of time and are prone to human error.

With your Windows 2003 forest running at Windows 2003 forest functional level, LVR has an additional important benefit for the links that are actually stored as LVR links in your domains. Because the links can now be replicated separately, the Ntdsutil authoritative restore process will follow the back links and increase the version ID for all LVR forward links it finds for the restored object(s). In the context of a recovered user, this means that all of the user's group memberships in its own domain will be fully recovered. Note that a DC can update only objects and links in its own domain. Therefore, if your AD forest consists of multiple domains and you also need to recover a user's group memberships in those domains, you must still leverage the LDIF files from Windows 2003 SP1's version of Ntdsutil during the authoritative restore operation.

LVR links not only improve the recoverability of group memberships—All other multi-valued linked attributes (e.g., manager/ directReports) behave the same way and will be recreated during restoration of an object that contains the relevant back links. Of course if an object has forward links, such as the group's member attribute, the forward links will still replicate during object restoration as they always have.

Updating Your AD Groups to Contain LVR Links
To take full advantage of the LVR benefits during recovery, you need to ensure that none of your groups or other linked attributes contain legacy links. In a single AD domain environment, this approach simplifies the overall AD recovery processes.

To update existing links in your AD forest, you must remove and readd the links to the linked attribute. For group memberships, you can easily accomplish this task by piping the output of the DSGET command as input to the DSMOD command. Using MyGroup as an example, you'd run the following DSGET group command with the -members option:

C:\>dsget group CN=MyGroup,OU=OUGroups,DC=RootR2,DC=net -members

Web Figure 1 (http://www.windowsitpro.com, InstantDoc ID 96310) shows the output from this command. If you combine this command with the DSMOD group command and the -chmbr option (which is used to replace all memberships in a group), you can efficiently remove and add all of a group's members, as follows:

C:\>dsget group CN=MyGroup,OU=OUGroups, DC=RootR2, DC=net -members | dsmod 
  groupCN=MyGroup,OU=OUGroups, DC=RootR2, DC=net -chmbr 

Web Figure 2 shows the output from this command. To see the effect the action had, run repadmin /showobjmeta again, as follows:

C:\>repadmin /showobjmeta DC1 CN=MyGroup,OU=OU-Groups,DC=RootR2,DC=net 

As the output in Web Figure 3 shows, all the links are now of the type "present," meaning that they are full LVR links that will be leveraged during object recovery.

But be careful: Don't remove and readd all group members for all your groups at once in a large environment, because doing so could result in a replication storm. Plan to switch your groups to LVR links so as to stagger the activity over a reasonable period of time.

Maximize the Benefits
LVR adds various benefits to your AD forest, including reduced replication traffic when updating group memberships and an unlimited number of members in each group. But equally importantly, LVR also allows for automatic recovery of back-linked attributes when authoritatively restoring objects. Especially after upgrading a Win2K domain or forest, you must take special care to switch existing group links from legacy storage to the LVR format, to be able to leverage all the benefits of LVR.

PROBLEM: Upgrading from Windows 2000 to Windows Server 2003 doesn't automatically enable the Linked Value Replication (LVR) feature.
SOLUTION: To enable and fully leverage LVR, you must perform several additional steps.
WHAT YOU NEED: Windows 2003
DIFFICULTY: 4 out of 5


  1. Upgrade from Windows 2000 to Windows Server 2003.

  2. Convert domains in your Active Directory (AD) forest from Win2K to Windows 2003 functional level.

  3. Update legacy links in your AD forest.

TAGS: Windows 8
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.