Forcing AD Replication

In "Get a Handle on AD Internals," September 2001, I explained how to use the Microsoft Windows 2000 Server Resource Kit's Repadmin utility to find a domain controller's (DC's) replication partners and how to use the required Lightweight Directory Access Protocol (LDAP) terminology to phrase your queries. Repadmin also lets you force those partners to synchronize.

Suppose I have two DCs—ds1 and ds2—both of which are members of acme.com. I want to run a script that works best when DCs have consistent copies of Active Directory (AD), so I want to synchronize ds1's and ds2's copies of the directory. Because AD replication is pull-only, synchronizing two DCs requires two events: I need to direct ds1 to pull ds2's changes, then I need to tell ds2 to pull ds1's changes. Both events are necessary because other DCs might have modified ds1's or ds2's copy of AD.

Use the following syntax to tell one DC to request updates from another DC:

repadmin /sync
  <namingcontext>
  <destinationDCname>
  <sourceDCGUID> /force

Namingcontext is LDAP-ese for the particular database that you want to replicate. For example, LDAP's naming context for the uptown.acme.com AD domain is dc=uptown,dc=acme,dc=com. DestinationDCname is the DNS name of the pulling DC. To tell ds1 to pull AD changes from ds2, I replace destinationDCname with ds1.acme.com.

The odd parameter is sourceDCGUID. In its place, you need to put the globally unique ID (GUID) of the DC that ds1 should pull changes from. You can use the Repadmin /showreps command to obtain that information. One of the first lines in that command's output resembles the line of output in Figure 1. The string that follows the colon is the specified DC's GUID. If that DC were ds2, we could use the command that Listing 1 shows to tell ds1 to pull replication information about the acme.com domain from ds2. The response (e.g., Sync from 8e90169a-dbf4-461b-97f5-1535085b9c04 to dun.win2ktest.com completed successfully) tells you whether replication was successful.

An easier approach uses an option that doesn't require any GUIDs. The /syncall option forces the DC to synchronize with all its partners. The syntax is

repadmin /syncall
  <destinationDCname>
  <namingcontext> /force

To force ds1 to pull changes from all its replication partners, you'd type

repadmin /syncall
  ds1.acme.com
  dc=acme,dc=com /force

If you omit the naming context, the DC replicates the forest's schema and configuration naming contexts.

Within 15 minutes after you bring a new DC online, it will run the internal Knowledge Consistency Checker (KCC) routine to choose replication partners. If you don't want to wait, you can use the following command to force the DC to run the KCC:

repadmin /kcc <DCname>

where DCname is the DC's DNS name.

We haven't exhausted Repadmin's capabilities yet. Watch for more in a future column.

End of Article