Q: How are Active Directory (AD) security group memberships replicated between different domain controller (DC) AD instances? Does AD handle replications differently in Windows Server 2003 than in Windows 2000?

A: An important deficiency of the way AD implements groups in Win2K is that a group's membership attribute is always completely replicated between DCs each time a group membership change occurs. Even if you make a change as small as adding or removing a single user to or from a group, AD will replicate the complete group membership, because in Win2K AD group membership is a multivalue AD attribute and multivalue attributes are replicated as a single data blob. In Win2K AD, the smallest unit of replication is the object attribute, which is still much more granular than in Windows NT 4.0, where the smallest replication unit is the object itself.

AD attribute-level replication isn't perfect. In addition to transferring more data over the wire than required, another problem with attribute-level replication is that when two administrators are updating the same group membership almost simultaneously on different DCs, one of the administrator's changes will be overwritten by the other's as the changes are replicated between the two DCs. In AD in Win2K, the last writer wins and the first writer's changes are lost.

Windows Server 2003 AD replication introduces an important new feature, linked value replication (LVR), which resolves the problems mentioned above. Thanks to LVR, the individual values of a multi-value attribute can be replicated separately between AD DC instances. LVR reduces AD replication traffic and usage of network bandwidth, processor, and memory resources.

An important detail is that LVR is available only if the Windows 2003 forest is in the Windows 2003 interim or native functionality level—your forest shouldn't include Win2K DCs. Memberships of groups that are carried over from Win2K to Windows 2003 don't take advantage of LVR automatically. After you upgrade your AD forest to Windows 2003 and switch its functionality level, legacy groups can still cause group membership change losses. Also, those groups' memberships will still be replicated using the legacy attribute-level replication mechanism.

To convert legacy group members to LVR members, you must remove the members and add them back again. You can easily do so by piping the output of the Dsget command (use the -members switch) as input to the Dsmod command (use the -chmbr switch to replace all memberships in a group). For example, to convert a legacy group called mygroup, use the following command, making sure to use the correct Fully Qualified Domain Name (FQDN) you want to convert:

dsget group  -members | dsmod group  -chmbr

You should never remove or add more than 5,000 members in a single operation, or AD might report replication errors, because an update to the AD database must be written in a single transaction and a single transaction is limited to approximately 5,000 entries. This weakness is caused by an underlying limit in Jet, the AD database engine. If you have automated group management in your AD, you should ensure that your provisioning or group management systems understand this limitation. The 5,000 entry limit also exists in Windows Server 2008.