Tracking AD Replication

Learn about USNs and high watermarks and how to use them

In "Get a Handle on AD Internals," September 2001, and "Forcing AD Replication," September 15, 2001, I explain how to use repadmin.exe to track and control Active Directory (AD) replication and give you a bit of background about how AD replicates. In this issue, let's look at how AD tracks replication traffic.

Administrators in a Windows NT 4.0 or mixed-mode AD domain must connect to the PDC before modifying a user account or other domain data. But administrators in a Windows 2000 native-mode (i.e., AD) environment can update AD from any domain controller (DC). Thus, native mode is more flexible than NT or mixed mode, but native-mode AD replication is more complex and implements some new concepts, two of which are update sequence numbers (USNs) and a high-watermark table.

Every DC keeps track of how many AD updates have occurred in its lifetime and gives each update a unique, sequential USN. Let's say we create a new, empty AD on a DC named dc1.acme.com. Then, we create an account named Mary on the DC. That account is the first AD update, so AD gives that update a USN of 1. (I'm greatly simplifying the USN numbering scheme, of course.) If we next create an account named John, AD assigns USN 2 to that update. Then, Mary updates AD by changing her password, which becomes USN 3, and John changes his password, making USN 4—the highest USN on this copy of AD.

Now, let's bring online a second DC, dc2.acme.com. As part of the process of becoming a DC, DC2 copies DC1's AD database. But DC2 doesn't copy AD's entire history; it copies just the latest information. Thus, DC2 copies the two user accounts and considers each one an update, so DC2's USN is 2.

DCs use their own and other DCs' USNs to determine whether DCs are up-to-date with one another. For example, when DC2 asks DC1 for updates, DC2 doesn't want a tiresome litany of everything that DC1 has ever learned; instead, DC2 simply wants to know what has changed since the last replication. In effect, DC2 says to DC1, "Tell me everything that's happened since your USN 4." As you can see, DC2 must remember the last USN it got from DC1; that USN is called DC1's high watermark. Each DC keeps a table of the high watermarks from all its replication partners. You can use the Repadmin /showreps command to view that table:

Repadmin /showreps   /verbose

For example, to see DC2's high-watermark table, you'd type

Repadmin /showreps dc=acme,dc=com dc2.acme.com /verbose

Excerpted, the output might resemble

INBOUND NEIGHBORS

...    Site1DC1 via RPC...     USNs: 59228/OU, 59228/PU

You'll see a line for each replication partner. The high-watermark value is the number that follows USNs:—59228, in the example.

How can you use this information? In a properly functioning AD, you wouldn't ever have to. But suppose you've given a user some new permission or right, and the user is sometimes unable to exercise that permission or right. What might the problem be? Like as not, one of the DCs in your network hasn't received the updates detailing the new right or permission.

To determine whether that's the problem, open a command line at the user's desk and use the Set command to determine which DC the user is logged on to. Then, retrieve the high-watermark table for that DC. You'll be able to see whether the DC that logged the user on is behind the times compared with the other DCs. If it is, force a replication following the instructions in "Forcing AD Replication," and the problem should disappear.