Leverage LVR to Simplify AD Object Recovery

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 featuresimplifies file and folder data recovery by leveragingthe new Volume Shadow Copy Service (VSS), whichlets you create snapshots of your shared file-systemdata at periodic intervals. Using this feature to recoveran 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 contentsprior to the incident. Although Microsoft hasn't quitereplicated this functionality for AD, Windows 2003has various powerful new AD features, one of whichis particularly helpful in recovering AD objects duringan authoritative restore: Linked Value Replication(LVR). (Note: Microsoft has implemented additionalfeatures 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 opensnapshots of the AD database as a separate offlineinstance, then use those instances to read data fromprevious versions of the objects.)

In this article, I describe the challenges ADadministrators face when they need to recover accidentally deleted objects in their AD domains and howcorrectly leveraging the Windows 2003 LVR featurecan help. This feature is especially important for companies that previously deployed their AD forest onWindows 2000, then upgraded to Windows 2003. Inthis case, administrators need to perform some extrawork before they can take advantage of LVR's specialbenefits 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 issomewhat misleading, because it lets you open theproperties of a user object, then add a group to theuser via the Member Of tab. In reality, the actions youperform in this UI actually update the linked-valuepair's forward link (i.e., the member attribute of therespective group), and the DC creates the back linkfrom the group to the user's memberOf attribute, asthis UI shows. This also explains why an administrator doesn't need special permission to manage a userto add him or her to a group in AD—instead, writepermissions to the group's member attribute arerequired.

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.

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:

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:

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:

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,  OU=OU-Groups,DC=RootR2,DC=net 

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.