SQL Server Magazine

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.

   Prev. page   [1] 2 3     next page