Display Replication Partners and Status of a Domain Controller

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2

When troubleshooting replication errors, it is helpful to know who are the replication partners of a specific domain controller and the status of replication with each of those partners.

Repadmin /showrepl displays the replication partners (RepsFrom and RepsTo) for each naming context that is held on the specified domain controller. By enumerating each RepsFrom and each RepsTo for each domain controller, you can visualize the replication topology for each naming context.

It also indicates whether the domain controller is also a global catalog server. Inbound replica links are displayed by default. Outbound links can also be shown, as well as connections that correspond to those links. The command also displays errors that correspond to replica links that cannot be created by the Knowledge Consistency Checker (KCC). This helps the administrator build a visual representation of the replication topology and see the role of each directory server in the replication process.

Syntax

Repadmin /showrepl <DC_LIST> <SourceDCObjectGUID> [NamingContext] [/verbose] [/nocache] [/repsto] [/conn] [/csv] [/all] [/errorsonly] [/intersite]

Show replication partners and replication status

The following example uses the showrepl operation of repadmin to display the replication status of ROOTDNS in relation to its partners. In our example, there are no problems reported because replication is running properly. There is lot of information one could gather from this output and please read the comments next to each line explaining what it means.

Figure 3.2.1

C:\>repadmin /showrepl rootdns

HUB\ROOTDNS (Site name and domain controller name)

DC Options: IS_GC (DC Options)

Site Options: (none) (Site options)

DC object GUID: 076cd5dd-e25e-4897-acd2-7c8691621522 (GUID of NTDS settings)

DC invocationID: 076cd5dd-e25e-4897-acd2-7c8691621522 (Database signature)

==== INBOUND NEIGHBORS =========================================================

DC=contoso,DC=com (Naming Context)

HUB\ROOTDC01 via RPC (Replication link)

DC object GUID: 2a92f776-6c0f-4cb4-a111-f5dcd447af6c (GUID of replication partner)

Last attempt @ 2005-01-05 01:04:34 was successful. (Status of last replication)

CN=Configuration,DC=contoso,DC=com (Naming Context)

HUB\ROOTDC01 via RPC (Replication link)

DC object GUID: 2a92f776-6c0f-4cb4-a111-f5dcd447af6c (GUID of replication partner)

Last attempt @ 2005-01-05 01:01:31 was successful. (Status of last replication)

HUB\BRANCH-HUB-BH via RPC (Replication link)

DC object GUID: 9090b7ce-53a6-4a44-91bf-b50ed232be53 

Last attempt @ 2005-01-05 01:01:44 was successful.

CN=Schema,CN=Configuration,DC=contoso,DC=com (Naming Context)

HUB\BRANCH-HUB-BH via RPC (Replication link)

DC object GUID: 9090b7ce-53a6-4a44-91bf-b50ed232be53

Last attempt @ 2005-01-05 00:53:34 was successful.

HUB\ROOTDC01 via RPC (Replication link)

DC object GUID: 2a92f776-6c0f-4cb4-a111-f5dcd447af6c

Last attempt @ 2005-01-05 00:53:34 was successful.

In the output under INBOUND NEIGHBORS, repadmin.exe shows the Lightweight Directory Access Protocol (LDAP) distinguished name of each directory partition for which inbound directory replication has been attempted, the site and name of the source domain controller, and whether it succeeded or not, as follows:

• Last attempt @ YYYY-MM-DD HH:MM.SS was successful.

• Last attempt @ [Never] was successful.

If repadmin.exe reports any of the following conditions, further investigation is required:

• The last successful inter-site replication was prior to the last scheduled replication.

• The last intra-site replication was longer than one hour ago.

• Replication was never successful.

DC Object GUID is a reference point used in the Active Directory and Domain Name System (DNS) to locate a domain controller primarily for the purposes of replication. This GUID is automatically generated for each domain controller, is unique when created, and will not be duplicated.

DC invocationID – Active Directory database has its own GUID, which the Directory System Agent (DSA) uses to identify the database instance (version of the database). The database GUID is stored in the invocationId attribute on the nTDSDSA object. Although the DSA GUID never changes for the lifetime of the domain controller, the Active Directory database GUID (also known as the invocation ID or database signature) is changed during the Active Directory restore process to ensure the consistency of the replication process. In Windows Server 2003, it changes when application directory partitions are removed or added to the domain controller.

Using repadmin /showrepl to display detailed and precise information

The following showrepl output is returned by combining <Naming Context> and /verbose.

For two domain controllers to engage in replication, they have to first resolve each other’s GUID CNAME to a host name and the host name to an IP address, such as the following:

2a92f776-6c0f-4cb4-a111-f5dcd447af6c._msdcs.contoso.com is the GUID CNAME registration in DNS.

High-watermark value

The high-watermark value is not required for any administrative task. However, it can help you deduce the state of progress on that replication link. You can see the high-watermark in the output of the repadmin /showrepl /verbose command in Figure 3.2.2. Look for lines that begin with USNs:. The high-watermark USN is the number that is followed by /OU.

The object update (OU) USN saves the position when in the middle of a replication cycle. It stays the same as the property update (PU) when replication is not occurring, and increases during a replication cycle. At the end of the cycle, the final USN replicated becomes the PU value and the OU is left to match. Thus, the OU indicates progress within a cycle, and the PU indicates the last update seen at the conclusion of a successful cycle. A PU of zero means that the link has never completed a successful cycle, as is the case when performing its first synchronization on a new domain controller connection. If the OU and PU are not equal, it means a replication cycle is in progress.

The following table lists nbrflagoptions, which are flags that define expected replication actions with its partner.

Showing outbound neighbors

By default, repadmin /showrepl does not display outbound neighbors, as with previous versions. The /repsto parameter provides this feature, as shown in Figure 3.2.5.

Some of the repadmin /showrepl Error Messages and their root cause

The following table lists some repadmin /showrepl errors and their root cause. The next sections after the table explain some errors in more detail.

No inbound neighbors

A “no inbound neighbor” error appears in the repadmin /showrepl command output when one or more of the following conditions exists:

• No connection object exists to indicate which domain controller(s) this domain controller should replicate from. These connection objects are typically created by the KCC. However, in some environments, administrators have turned off the part of KCC (Intersite) that creates connection objects for inbound replication from domain controllers in other sites, relying on manual connections instead.

• One or more connection objects exist, but the domain controller cannot contact the source domain controller to create the replication links. In this case, the KCC logs events each time it runs (by default, every 15 minutes) detailing the error that occurred when it attempted to add the replication links.

• Existing replication links has been inadvertently deleted in between KCC executions.

Repadmin in this scenario could be used only to diagnose. The following table explains subcommand usage that can help you diagnose the problems leading to this situation.

Active Directory replication has been preempted

When Active Directory replication has been preempted, an inbound replication in progress was interrupted by a higher priority replication request. An example of a higher priority replication request is a request generated manually by using the repadmin /sync command.

Repadmin in this scenario could be used only to diagnose. The following table explains subcommand usage that can help you diagnose the problems leading to this situation.

Last attempt @ never was successful

Last attempt @ never was successful error typically indicates that KCC successfully created the replication link between the local domain controller and its replication partner, but because of the schedule or possible bridgehead overload, replication has not occurred.

Repadmin in this scenario may be used for both diagnosis and resolution. The following table explains subcommand usage that can help you diagnose or solve the problems.

Access denied

This error indicates that the local domain controller failed to authenticate against its replication partner when creating the replication link or when trying to replicate over an existing link. This typically happens when the domain controller has been disconnected from the rest of the network for a long time and its computer account password is not synchronized with the computer account password that is stored in the Active Directory of its replication partner.