The ins and outs of the Windows File Replication Service

by Scott Lowe MCSE | Aug 25, 2003 7:00:00 AM

Tags: Business structures, Scott Lowe MCSE, File Replication Service, replica, Microsoft Windows

Takeaway: The File Replication Service is one of the lesser-known Windows services, but it can have a large impact on your network's reliability and performance. Here's what you need to know to keep FRS humming along.

At the heart of Windows Server lies the File Replication Service (FRS). FRS is critical to the proper functioning of the Distributed File System and Group Policies, not to mention the proper functioning of login scripts across the domain. Without a properly functioning FRS, none of these services could be depended upon to provide the timeliest information available, and the Windows network would soon become unusable.

What is FRS?
Introduced with the name File Replication Service in Windows 2000, FRS replaced and enhanced the Windows NT LAN Manager Replication (LMREPL) service. FRS is a multithreaded service multimaster replication engine responsible for a variety of functionality in Windows networks. Because FRS uses a multimaster replication engine, FRS enables any domain controller to begin the propagation changes for replicated materials.

FRS terminology
Like other services, FRS has a set of terms you need to know to properly understand it. Here are some of the key terms:

Inbound partner. The inbound partner in a replica set refers to the system that has the changed file that needs to be replicated. This is not a static designation. An inbound partner for one replication cycle may be an outbound partner for a future cycle, depending on the location of the changed files.
Outbound partner. The outbound partner in a replica set is the system to which a changed file is being replicated.
Multimaster. FRS does not use primary and secondary nomenclature for systems participating in replication, as all included systems are considered equal—or masters.
Knowledge Consistency Checker. The Knowledge Consistency Checker (KCC) is responsible for creating connections between domain controllers and for triggering replication. At specified intervals, the KCC reviews and modifies the replication topology based on any new information it receives.
Replica. A replica is a single member of a replica set. A replica contains a copy of files and folders.
Replica set - A minimum of two copies of a shared folder or file. A replica set's consistency is maintained by FRS.
Initial master. The initial master is the first replica in a replica set by which all other replicas are created.

FRS provides the underpinnings for a number of Windows services, including the Distributed File System (Dfs), system policies, and login scripts. Dfs provides a high level of availability for an environment by replicating specified files and folders among various servers in the enterprise. A user accessing a Dfs share does not necessarily know—or care—which server the file is being accessed on. This provides resource and location independence for the files and folders supported under Dfs, as well as the ability for an organization to successfully withstand the loss of multiple servers and still maintain a production-level environment.

In Windows 2000/2003 domains, system policies and login scripts that are stored in the SYSVOL folder (which replaces netlogon from Windows NT) are automatically replicated to all domain controllers to make sure that users are using the most recent version of this important information and to prevent the need for an administrator to manually update each domain controller. The default path for the SYSVOL folder is %SystemRoot%\sysvol.

Active Directory replication not included
It is important to note that Active Directory replication and FRS replication are two different services that act differently, although they accomplish similar objectives. For example, Active Directory replication compresses replicated content between sites, while the original release of FRS under Windows 2000 did not. This shortcoming was addressed in Service Pack 2.

Optimizing FRS
Because of its importance in Windows Server environments, keeping FRS operating at peak levels can result in a much more efficient overall infrastructure. Although FRS does not have its own management console, the services that rely on FRS do have this feature. FRS also includes a number of registry entries you can tweak to achieve maximum performance.

Service packs and updates
One easy way to realize increased performance from FRS is to install both Windows 2000 Service Pack 3 and the post-Service Pack 3 release of Ntfrs.exe. Installing these updates will bring your system current with a large number of improvements made to FRS with the release of Service Pack 2, as well as more updates made after the release of Service Pack 3. Here are a few of the improvements to FRS supplied by these updates:

On-the-wire compression of replicated content results in much faster data transfer.
In conditions in which the system determines that a service restoration may correct a problem with FRS, it performs a nonauthoritative restore.
A memory leak in management instrumentation as a result of problems in FRS was corrected.
Numerous bugs and inconsistencies were addressed, resulting in a more capable, robust service.

Be wary of disk defragmentation
Under certain conditions, performing a defragmentation procedure on a disk hosting Dfs volumes or SYSVOL can result in excessive replication of files that have not changed. This can create unnecessary network traffic and affect the performance of the server and its replication partners. The problem occurs because of the way that Windows 2000 file system defragmentation APIs use the file cache to write data to the new disk location.

Obviously, you have to be able to defragment server drives once in a while. To avoid an excessive replication problem, you can choose not to defragment drives that host FRS-replicated files. A second option is to use a disk defragmentation program that allows you to exclude specific folders from the process. If you choose this option, exclude folders on any drives that contain replicated content.

Registry entries related to FRS
FRS has a number of registry entries that can be modified to change the way that the service functions or logs information. Table A provides a summary of the FRS registry entries in Windows 2000 and the default values. Columns are provided for pre-SP2 and SP2 and greater because of the significant changes made to the service in Windows 2000 SP2. All registry entries in the table are REG_DWORD values located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters. If you do make changes to the values below, you should stop the FRS service (net stop ntfrs) before making the change and start it again afterward (net start ntfrs).
Table A

Registry key	Description	< SP2	>= SP2
Debug log files	Although this parameter does not directly affect the performance of FRS, it does affect how much disk space is used by the FRS. A new log file is created after the number of lines in the current files reaches the value defined in "Debug Maximum Log Messages." After more than the number of log files allowed by this parameter is met on the system, the lowest log Ntfrs_0001 is deleted and the version numbers for the remaining logs get decremented. This parameter has a minimum value of 0 and no maximum. For less disk space usage, use a lower number.	5	5
Debug log severity	This determines how much detail the FRS log files provide. Log files are stored in %SystemRoot%\Debug\Ntfrs_xxx.log where xxx is the number of the log file with a maximum determined by the “debug log files” key. Every FRS event has a severity level associated with it. Events with a severity level equal to or greater than this value will be logged. If you are having a replication problem, increase this number to obtain more detailed troubleshooting information. For best performance, use lower numbers. They will result in fewer details being logged, which in turn requires less processing overhead. Values can range from 0 to 5.	4	2
Debug maximum log messages	This specifies the number of lines that can be stored in a single Ntfrs_x.log debug log file before a new file is created. This parameter has a minimum value of 0 and no maximum. For less disk space usage, use a lower number. The default value of 10,000 lines will use approximately 1-2 MB of disk space.	10000	10000
DS polling long interval in minutes	If there are no configuration changes to Active Directory, FRS uses the long polling interval and reverts to the short interval after configuration changes. This value has a one-minute minimum and no maximum limit.	5 (DC) 60 for member server	5 (DC) 60 for member server
DS Polling short internal in minutes	This is the interval in minutes before FRS polls Active Directory after configuration changes. Eight of these polls are conducted. A configuration change will cause this counter to reset to zero. If the counter gets to 8 with no configuration changes, the service begins to use the long polling interval. This value has a one-minute minimum and no maximum limit.	5	5
Ntfs journal size in MB	This value determines the size of the Update Sequence Number (USN) journal file. NTFS uses this information to track changes to files and folders. Be sure that this value is high enough to prevent journal wrap errors. These occur when the number of changes that take place on the NTFS partition is high enough that the last USN change that FRS recorded before it was shut down does not exist when the services are restarted. Microsoft suggests 128 MB of journal space per 100,000 files managed by replication on that volume. To increase this value, stop FRS and make the change and then restart FRS. Unfortunately, decreasing this value requires that you reformat all volumes containing FRS-replicated content. This value can range from 10 MB to 2-terabytes	32 MB	32 MB (<=SP2) 128 MB (SP3+)
Staging space limit in KB	This dictates the amount of space to use for files held on disk until retrieved by all downstream replication partners. Be careful not to set this number to a value that is greater than the amount of free disk space as you will risk running out if there are replication problems.	660 MB	660 MB
Working directory	FRS uses a Jet database called Ntfrs.jdb to store transaction data.file and associated log files, which should reside on an NTFS partition. FRS performance can be potentially enhanced by moving this database and the FRS log files (whose location is also dictated by this key) to a dedicated or faster disk. Before changing this value, be sure to stop FRS and to properly create the %SystemRoot%\Ntfrs directory structure in its new location.	%SystemRoot% \Ntfrs	%SystemRoot% \Ntfrs

Windows 2000 FRS registry entries and default values

Fear not the FRS
The FRS may sound like a complicated service, but it's not, once you know how it works. FRS provides a key service to Windows environments. Keeping it running at peak efficiency will provide faster, more responsive results.

2 comment(s)