Iologsum.cmd: FRS Inbound and Outbound Logs Summary Report Tool

This command-line tool processes the output generated when the NtfrsUtl tool is run with the inlog, outlog, or idtable parameters.

Running NtfrsUtl inlog or NtfrsUtl outlog creates a summary inbound or outbound NtfrsUtl log report showing the pending change orders for the replica member. Running NtfrsUtl idtable creates a report with version information for each file in the replica tree; this version information tracks the last change order accepted for that particular file or directory. Running IOLogSum then sorts and formats this NtfrsUtl output.

Corresponding UI

There is no corresponding user interface for this tool.

Concepts

The File Replication Service (FRS), first introduced in Windows 2000, is an essential element of the Microsoft Active Directory technologies. The Active Directory service uses FRS for SYSVOL replication. FRS can also be used with the Microsoft Distributed File System (DFS) technologies for automatic replication of content between alternating targets. For more information on FRS and Active Directory replication please see the Windows Server 2003 Resource Kit.

A replica set consists of two or more computers configured to replicate the contents of a file folder. The individual computers are referred to as replica members.

FRS maintains logs of change orders that are either received from replication partners (the inbound log), or are to be sent to outbound replication partners (the outbound log).

The inbound log stores pending change orders to be processed. As entries are processed, FRS sends acknowledgment to the inbound partners. Data stored in the inbound log includes the change order's globally unique identifier (GUID), file name, object ID, parent object ID, version number, and event time.

The outbound log stores pending change orders to be sent to outbound partners. Change orders remain in the outbound log until all outbound partners receive and acknowledge the change. Data stored in the outbound log is the same as that stored in the inbound log. Also in the outbound log is the leading (next change) and trailing (last acknowledged) index for each partner.

The outbound logs can become quite large, particularly when replica members are unavailable, links between replicas are slow, replication hours are restricted, or a large number of changes occur. For example, even when a member for a given replica set is unavailable, outbound log entries are maintained until the member becomes available. When the changes are then sent, the inbound partner sends all changes in log file order.

System Requirements

Files Required

Related Topics