Verify the FRS Topology As Stored in Active Directory

Each FRS server reads the replica set topology information from the closest available domain controller, not from some specified master DC. If the topology information is changing, and if there are delays in Active Directory replication due to backlog or schedule, then it is possible that different FRS servers will temporarily be out of sync.

Therefore, the first task in topology analysis is to decide the locations from which to check and compare the topology. This will typically include an FRS server from the main sites from which topologies are updated, along with a handful of branch sites, or any sites experiencing replication or join issues.

For each FRS server you choose to inspect topology from, run the Ntfrsutl DS command to obtain the raw topology information, then run the Topchk tool as described in Topchk.cmd: DFS and SYSVOL Replication Topology Analysis Tool.

Then, for each server from which to compare topology, follow the procedures described in this section.

Detecting a Missing NTDS Settings Reference

One possible reason for the differences could be that NTDS settings objects are missing in Active Directory.

The ServerReference attribute on the FRS member object of a SYSVOL replica set points to the Distinguished Name (DN) of that member’s NTDS Settings object. If the NTDS Settings object was deleted, the Server Reference attribute is not rebuilt. This means that either (i) the NTDS Settings object is missing or (ii) the link to it in the ServerReference attribute does not exist.

In the top.txt file this situation is reported in the following manner (only on the servers where the ntds settings object is missing):

M I S S I N G   N T D S   S E T T I N G S   R E F E R E N C E S
The following FRS Member objects have no Server Reference to an NTDS Settings Object

Repairing a Missing NTDS Settings Reference

To recover from these problems you have to know if the NTDS Settings object was removed intentionally (so the server should have been demoted) or by accident. If it was intentional, remove the member object (DN=ERNI-VMDC1,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=erni,DC=com) with ADSIEDIT or LDP. Also remove the whole server object (CN=ERNI-VMDC1 ,CN=Servers, CN=Site1, CN=Sites, CN=Configuration, DC=erni, DC=com). NTDSUTL should do this job, if not try to delete is in the sites and services MMC or use ADIEDIT or LDP again.


You’ll find a detailed description on how to recover missing or corrupted FRS Active Directory objects in the following articles:

Investigating and Repairing Connection Balancing and Schedules

In this section, we look for 4 specific issues:

Here is an example from a top.txt file that shows a case where hubs are not well balanced – DC08CCAN has significantly more partners than the others:

Servers referenced from cxtions (From List)
XYZ\DC06CCAN			 47  63
XYZ\DC07CCAZ			 78  78
XYZ\DC08CCAN			152 162 

To remedy such situations, you can manually rebuild the topology or use the MKDSX script (in both cases refer to the Windows 2000 Branch Office Deployment Guide available at You can also use this script to set an appropriate schedule.

The Topchk report includes a section that shows a schedule that has been set unnecessarily high (actually continuous since 24x7 = 168 hours). For a larger site with > 100 Domain controllers in as many Active Directory sites it would be advisable to correct this.

M E M B E R S   W I T H	1 6 8   H O U R   C O N N E C T I O N S
The following FRS Member objects have connection objects with 168 hour replication schedules
Member:   DC10CCAN   cxtion:   03A1E67D-FCD3-4E6F-A17B-A81149A19206   host: CCA\DC10CCAN
Member:   DC10CCAN   cxtion:   40A91E15-9572-4B18-8B74-BF9B06DDD3C0   host: CCA\DC10CCAN
Member:   DC10CCAN   cxtion:   40EAAD73-511F-4D67-8555-EC69F2232370   host: CCA\DC10CCAN

The schedule as reported in the Topchk report represents every hour of Monday – only Monday is shown in order to reduce the size of the report, by making the assumption that the Monday schedule is representative of the normal daily schedule:

RepHrs: 168  Sched: 111111111111111111111111

In this example FRS replicates once per hour in 168 hours of the week (24*7=168). Every single number of the above represents one hour of the day as a decimal 4 bit value. Each single bit represents 15 minutes of this hour. So if we have "1" in decimal, then one bit is set in binary (0001) and we replicate once per hour.

If the decimal value is 5 (0101 in binary) we replicate twice per hour, for example:

RepHrs: 168  Sched: 555555555555555555555555

Finally if it is F (1111) we replicate 4 times per hour:


A connection can be disabled (enabled: FALSE) or the schedule could be all "0" or "none". If the connection is disabled, the FRS service does not use it and therefore does not replicate; this is true for both DFS/FRS and SYSVOL/FRS replication. If the schedule has 24 zeros, FRS also does not replicate. However, if it is set to "(none)" FRS will replicate 4 times per hour, because this is the default schedule on replica set objects.


Every Member Must Have at Least One Inbound Connection

Every member of a replica set has to have at least one inbound connection. This is always true for SYSVOL and therefore Active Directory replication as otherwise no new users or even password changes could replicate. A possible exception could be a custom DFS topology where changes are only made on one of the participating servers.

In the case of servers missing inbound connections, the following warning is shown in the top.txt report:

S E R V E R S   M I S S I N G   I N B O U N D   C O N N E C T I O N S

The following FRS Member servers have outbound replication partners but no inbound connection objects. There could be several reasons for this:
1. There are no connection objects under the NTDS Settings object for this server.  This is an error.
2. The ServerReference Attribute for this server is null. This is an error.
3. This server could be in a different domain so there will be no FRS member object for it.
4. The FRS member object may be missing.  This is an error.

Members Missing Computer Reference

S E R V E R S   M I S S I N G   C O M P U T E R   R E F E R E N C E

This part of the topology report appears if any FRS member objects have no computer reference. For more information, refer to article 312862, "Recovering Missing FRS Objects and FRS Attributes in Active Directory" at

Members Missing Connection Objects

S E R V E R S   M I S S I N G   C O N N E C T I O N   O B J E C T S

This part of the topology report appears if any FRS member objects have no inbound connection objects. This is most commonly caused by an administrator manually defining a replication topology, and not creating a connection object.

In this situation, check for NTDS connection objects. If none exists, create one by using the Active Directory Sites and Services snap-in. For more information, refer to article 257338, "Troubleshooting Missing SYSVOL and NETLOGON Shares on Windows 2000 Domain Controllers" at or article 327781, "How to Troubleshoot Missing SYSVOL and NETLOGON Shares on Windows Server 2003 Domain Controllers" at

Members With Self-Reference Connection Objects

This part of the topology report appears if any FRS member objects have connection objects that refer back to them. This is most commonly caused by an administrator manually defining a replication topology and mistakenly creating this condition. In this situation, the topology must be manually corrected by deleting the object that points back to the server.