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.
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
XYZA0314S01
XYZA0699S01
XYZA0281S01
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.
Important
You’ll find a detailed description on how to recover missing or corrupted FRS Active Directory objects in the following articles:
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 http://go.microsoft.com/fwlink/?LinkId=16718. 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:
RepHrs: 168 Sched: FFFFFFFFFFFFFFFFFFFFFFFF
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.
Important
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.
XYZ\DCFRCAN
XYZ\DCFRCAZ
XYZ\NLDC001
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 http://support.microsoft.com/?id=312862.
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 http://support.microsoft.com/?id=257338 or article 327781, "How to Troubleshoot Missing SYSVOL and NETLOGON Shares on Windows Server 2003 Domain Controllers" at http://support.microsoft.com/?id=327781.
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.