Replication Latency

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

There are two mechanisms each specific to the underlying operating system functionality to measure replication latencies. Repadmin could be used against both environments based on the following table.

Windows 2000 functionality	Windows Server 2003 functionality
/latency provides you replication latency report by measuring how recently the Intersite Topology Generator (ISTG) attribute has changed.	/showutdvec provides you replication latency report by leveraging a new field stored in the Up-To-Dateness (UTD) vector – “last successful replication timestamp.”
Note that this report ceases to give meaningful results when the forest functional level is Windows Server 2003 because the interSiteTopologyGenerator on the NTDS site settings object is not updated at that functional level.	/showutdvec provides you replication latency report by leveraging a new field stored in the UTD vector – “last successful replication timestamp.” This timestamp records the last time the corresponding domain controller completed a successful replication cycle with its partner. The replication cycle may have occurred directly (direct replication partner) or indirectly (transitive replication partner).
Latency is shown for configuration naming context only.	Because this data is recorded on all domain controllers that host the partition, it is possible to identify non-replicating domain controllers from any domain controller in the forest that has a common partition between them.

Syntax

The following command displays the amount of time between replications on a site by site basis from the perspective of the servers listed in <DC_LIST>, using the ISTG Keep Alive time stamp.

Note

The ISTG Keep Alive time stamp is the mechanism used in Windows 2000 to determine whether a new ISTG is required for the site. Prior to Windows Server 2003, all ISTGs will record a time stamp every 30 minutes to indicate they are alive. After this gets replicated within the site, all of the domain controllers in the site know whether an ISTG is down or not by verifying this attribute, which is stored in Active Directory.

repadmin /latency*<DC_LIST>*

How to interpret the data

In this example, the forest has only four sites.

Field	Explanation
Origination site	This column has a row for each site in the forest
Ver	Version number for site specific interSiteTopologyGenerator
Time Local Update	Local time when the remote ISTG attribute change was replicated in.
Time Orig. Update	Time when the ISTG attribute was changed on the originating server.
Latency	Difference between the Time Orig. Update and Time Local Update
Since Last	Difference between the Tool execution time and Time Local Update

Examining the UTD vector from time to time on one bridgehead server is another good way to ensure that replication is healthy. The (UTD) vector shows the last time that a domain controller has received updates from each replication partner for a particular naming context. The UTD vector is transitive in that one domain controller does not have to talk directly to another domain controller to receive an update from it.

repadmin /showutdvec <DC_LIST> <NamingContext> [/nocache][/latency]

Parameters	Definition
<DC_LIST>	Specifies the host name of a domain controller or a list of domain controllers separated by a space that the object will be replicated to. For details about DC_LIST, see repadmin /listhelp.
<NamingContext>	Specifies the distinguished name of the directory partition.
/nocache	Specifies that globally unique identifier (GUIDs) are left in hexadecimal form. By default, GUIDs are translated into strings.
/latency	Sorts the information by the time required to complete the replication. By default, the information is sorted by Update Sequence Number (USN).

How to interpret the data

• In Figure 3.3.2, there are four sites, two domains and six domain controllers in the forest.

• The output is a list of dates and times indicating the last time that inbound replication of the configuration container occurred from each domain controller. If an excessive amount of time has passed since replication last took place it could indicate a problem and there is reason to be concerned.

• The entries are listed by domain controller and the /latency parameter sorts the output by date/time.

• As given in the example, occasionally GUID’s will be displayed instead of a domain controller’s name. It is safe to ignore the GUID entries as these are a result of InvocationID changes or domain controllers being demoted or rebuilt and do not affect the health of the topology.

• HUB\ROOTDNS will always report the current date and time and the highest committed USN. The reason is that a domain controller does not keep itself in its own UTDVEC and always builds its entry on the fly based on the current state.

• Latency from the perspective ROOTDNS is the difference between its current date/time with respect to other partners (direct or transitive) for the given Naming Context. For example, latency between ROOTDNS and BRANCH1 is 00:24:17.

Display the latency only for the domain partition

In this example, we are only interested in the domain naming context latency. Both the domain controllers are running Windows Server 2003 and reside in the same site; hence the latency is less than a minute. Also please note that we are only displaying the domain members and not the whole forest due to the scope of the naming context.

While it is important to measure replication latencies, it is equally important to understand that intersite replication depends on many factors such as:

• Site link schedules and intervals

• Availability of bridgehead servers and their load

• Whether change notifications are enabled

• LAN/WAN infrastructure