Export (0) Print
Expand All

Topchk Remarks

Updated: March 28, 2003

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

TopChk Remarks

Before Using TopChk

If Perl is not installed on your system, if you are connected to the Internet, you can download a free version from the ActiveState Web site.

TopChk Report

The TopChk report is used to verify that configuration information for FRS replica sets has been defined and stored correctly within the Active Directory. It is useful both as a regular health-check tool to confirm that replication is correctly configured, and as a troubleshooting tool for investigating possible causes of FRS replication issues.

Familiarity with FRS concepts and terminology is required in order to interpret TopChk reports.

The report consists of two main sections: The Subscriber List Summary followed by a Topology Analysis for each replica set. There is a section that summarizes the report following these sections.

Subscriber List Summary

This part of the report displays one row of information for each replica set that this member participates in. For example:

SUBSCRIBER: DOC|SALES      Root: f:\docs\sales                     Stage: e:\frs-stg
SUBSCRIBER: DOC|SUPPORT    Root: f:\docs\support                   Stage: e:\frs-stg

Each row shows the replica set name, the location on this computer where the replica set data exists, and the location of the FRS staging directory for this replica set.

Replica Set Topology Analysis

This part of the report contains a separate topology section for each replica set that this member participates in. The beginning of each section is indicated by the heading:

SET: <replica set name>

There may follow any of several possible sections, depending on the topology of the given replica set. The following sections can be included in the TopChk report:

SERVERS MISSING INBOUND CONNECTIONS

SERVERS MISSING OUTBOUND CONNECTIONS

MISSING NTDS SETTINGS REFERENCES

MEMBERS MISSING COMPUTER REFERENCE

MEMBERS MISSING CONNECTION OBJECTS

MEMBERS WITH SELF-REFERENCE CONNECTION OBJECTS

MEMBERS WITH 168 HOUR CONNECTIONS

SERVERS MISSING INBOUND CONNECTIONS

This part of the topology report appears if any FRS member servers have outbound replication partners but no inbound connection objects. There may be several reasons for this condition:

  • There are no connection objects under the NTDS Settings object for this server. This is an error.

  • The ServerReference Attribute for this server is null. This is an error.

  • The FRS member object may be missing. This is an error.

  • The server may be in a different domain, therefore no FRS member object can be identified for it. Domain controllers that hold a copy of the Global Catalog and are in a different domain are also listed this way. Such servers very likely do have inbound connections to replicate parts of the local domain naming context, but they are not members of the SYSVOL replica set. As a result, these servers are listed but they are not in an error state.

SERVERS MISSING OUTBOUND CONNECTIONS

This part of the topology report appears if any FRS member servers have inbound replication partners but no outbound connection objects.

MISSING NTDS SETTINGS REFERENCES

This part of the topology report appears if any FRS member objects have no Server Reference to an NTDS Settings object. For more information, refer to the Knowledge Base article Q312862: "Recovering Missing FRS Objects and FRS Attributes in AD."

MEMBERS MISSING COMPUTER REFERENCE

This part of the topology report appears if any FRS member objects have no computer reference. For more information, refer to the Knowledge Base article Q312862: "Recovering Missing FRS Objects and FRS Attributes in AD."

MEMBERS MISSING CONNECTION OBJECTS

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, an Administrator should check for NTDS connection objects. If none exists, the Administrator can create one by using Active Directory Sites & Services. For more information, refer to Knowledge Base article Q257338, "Troubleshooting Missing SYSVOL and NETLOGON Shares."

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 themselves. 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.

MEMBERS WITH 168 HOUR CONNECTIONS

This part of the topology report appears if the FRS member object has a connection object with a 168-hour (that is, 24x7) replication schedule. This section intentionally lists connections that are continuously enabled; it does not indicate an error.

Summary Report Section

This section provides a statistical overview of the other reports. Each potential entry for this section is described here.

Member objects with no NTDS Settings reference

This entry represents the number of FRS objects that did not replicate their SYSVOL share and need to be further investigated.

Member objects with no connection objects

This entry represents the number of NTDS Settings objects with no connection objects, meaning that the servers shown here are not replicating inbound. Note that each SYSVOL member must have one inbound and one outbound connection object. DFS replica sets are permitted to have inbound connection objects with no outbound connection object when using hub and spoke or custom topologies.

Connection objects set to disabled

This entry represents the number of disabled replication connections. The Administrator should investigate these to see which connections have been disabled, and determine if this is intended. The section titled Connection Summary printed as part of the Summary Report can be used for this purpose.

Monday Schedule

This section appears if TopChk finds a connection object scheduled to replicate at least daily (Monday in this case is assumed to be representative of the schedule for the business week). This provides some insight into whether the schedules have been staggered across connections, which is a best practice for large configurations.

Number connections with per-week active replication hours

This section displays replication hours for each connection object. It begins with a number of rows showing (a) number of servers, then (b) the number of hours the schedule is enabled for those servers.

Note

  • This is approximate. Any hour in which the schedule byte is non-zero is counted as an active replication hour.

It is possible that objects used for intra-site communication may show high replication hours (in the range of 160 or over); however, in most cases this level of network use is not advised.

Connection Summary

This section lists each connection, along with its Monday schedule, replication hours, and enabled/disabled status in order to facilitate further investigation of schedules.

Note

  • A connection with a GUID, for example "cxtion: CC9BA0F4-3B12-4ADE-86BA-C405D86D4D59" indicates a connection that has been auto-generated by the Active Directory Knowledge Consistency Checker (KCC) or that has been created by using the DFS MMC snap-in utility. When the connection is associated with a name such as "cxtion: DC22," this indicates the connection was manually generated.

Server Inbound/Outbound Partner Report

The Server Inbound/Outbound Partner report (the final part of the Summary) lists the total number of inbound and outbound connections for a given server. Each server shows two entries: one with '<<' signifying an inbound connection list, and one with '>>' signifying an outbound connection list.

This part of the report is beneficial for investigating two aspects of the topology definition:

  • It shows whether SYSVOL members have the required minimum of one inbound and one outbound connection object.

  • It helps determine if the topology is reasonable with respect to the number of direct partners for each member, the amount of content being replicated (size * change), the link speed, and so forth.

An excessive number of connections to or from any one partner should be evaluated in order to see if the topology is balancing replication load appropriately.

See Also

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft