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:
-
Legacy—Link that's still stored in the old format with all values
stored and replicated in a single blob; only contains "active" links.
-
Present—Link that's stored in the new LVR format and "active" (e.g.,
a normal member of a group).
-
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,
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.
