Understanding Win2K's File Replication Service

FRS simplifies Sysvol synchronization across DCs

If you've used logon scripts, default domain profiles, or system policies under Windows NT, you know that you need to store them on Netlogon, a share that NT creates on every domain controller (DC). If you have more than one DC in your domain, you need to make sure that every DC has the latest copies of those scripts, policies, and profiles—if you change anything, you must replicate that change to every DC's Netlogon share. You can use NT's directory replication service to automate the replication, but the service isn't simple to set up or monitor. Windows 2000 changes Netlogon's name to Sysvol and simplifies the job of keeping Sysvol folders consistent across DCs.

To keep the contents of their Sysvol folders consistent, Active Directory (AD) DCs use the File Replication Service. FRS runs automatically on all DCs and requires no administrative intervention to set up.

(Unfortunately, Win2K doesn't have the option to run NT's directory replication service, so in mixed environments, the Netlogon share on an NT DC won't automatically replicate to Sysvol on the Win2K DCs. The only workaround is to use the Scheduler service to run a batch file that does the replication.)

Win2K Server also uses FRS to synchronize the contents of replicas of Dfs shares. FRS's Sysvol replication approach is a bit different from the way that FRS synchronizes Dfs replicas, though. Let's explore FRS's Sysvol replication behavior.

Trying Out FRS
Win2K implements FRS as a service through the ntfrs.exe program. If you have two or more DCs, you can try out FRS. Create a text file (or another kind of file) in one of your DCs' Sysvol shares. By default, the Sysvol share is in winntsysvolsysvol, although you can choose to place it somewhere else when you create a DC.

If you can't find Sysvol, log on to your DC, right-click My Computer, then choose Manage. Open the Shared Folders object, then click the Shares object. In the right pane, you'll see a list of your computer's shares; the volume and directory name of each share will appear in the Shared Path column.

After you've put that first file into one DC's Sysvol, take a peek at the Sysvol share on another DC on the same site (I discuss multisite considerations later). You should see that a copy of the file appears in that Sysvol—and in all the other Sysvols on the site. Modify some other DC's copy of the file, wait a few seconds, then check the other Sysvols—you'll see that they already have copies of the updated file.

Those nearly-instantaneous updates surprised me. I'm used to AD's DC-to-DC replication, which by default takes place every 5 minutes. If I had changed the description of a user account or modified a group policy, I might have had to wait up to 5 minutes to see those changes reflected in all the other DCs on the same site. (Both FRS replication and AD replication behave differently across site boundaries.) The nearly immediate intrasite FRS replication illustrates that FRS doesn't replicate in lockstep with AD. And although you can force AD to replicate immediately between two DCs on different sites, you can't make FRS replicate between sites on command.

Like AD, FRS is a multimaster replication system. In other words, suppose you have four DCs with a file called test.txt on each DC's Sysvol. (For simplicity's sake, assume the DCs are on the same site.) Suppose further that you originally created test.txt on DC1. A few seconds later, test.txt appeared in the other three DCs' Sysvols. Let's say that you then edited test.txt on DC3 and saved the changes in DC3's Sysvol. The updated file would quickly appear on the three other DCs. Thus, you can modify any DC's copy of Sysvol, and all other DCs will soon receive those modifications.

Conflict Resolution
A question that arises from FRS's prompt replication is What about conflicts and file locking or record locking? The answer is that FRS is a very simple system and doesn't provide much in the way of protection against conflicts. If you were to edit test.txt on DC1 while I was editing it on DC2, FRS wouldn't warn us about each other's activity—whichever of us wrote his or her file changes last would win. Part of the blame for that lack of notification lies with Notepad—the tool that we'd likely use to modify a .txt file—which doesn't enforce any kind of file locking.

But suppose that for some reason a Microsoft Word document—call it test.doc—resides in Sysvol. Word, of course, keeps track of file locking. If you're editing a copy of test.doc on DC1 when I try to edit the same file on DC1, Word would see that I'm trying to open a locked file. I'd then get Word's standard message, which says, in effect, User XYZ is editing this file; would you like to open it as read-only? But if you're editing the copy of test.doc on DC1 when I try to open DC2's copy of the document, Word wouldn't complain because no file-lock linkage exists between files in different Sysvols. As with the simpler Notepad scenario, then, whoever saves his or her file last wins, and changes made earlier are lost.

How big a problem is this? The potential for conflicts isn't large because most files in Sysvol aren't often edited. One exception, however, is Group Policy Templates (GPTs).

Every group policy has two pieces—an object in AD and a file in Sysvol. The AD object, called the Group Policy Container (GPC), replicates with all other AD objects. The file portion—the GPT—consists of a combination of directories and files and replicates with FRS. Every time you modify a group policy, you potentially change a file in the GPT. If two administrators were to edit the same policy simultaneously, they could interfere with each other's edits, just as if two people were simultaneously editing a Word document in Sysvol. Group Policy Editor (GPE), gpedit.msc, avoids conflicts in this way: Whenever you modify a Group Policy Object (GPO), gpedit.msc connects you to the PDC Operations Master for the domain. Thus, everyone who modifies a group policy does so on the same DC, which lets the GPE detect and avoid conflicts.

As a side effect of this aspect of GPE operation, policy edits might seem slow in comparison with other AD operations because the PDC Operations Master might be a WAN link away from you. You can change that behavior in gpedit.msc, but I recommend against it.

While I'm on the subject of group policies and replication, here's a related note: Because each group policy consists of a GPC and a GPT and those two pieces replicate on different schedules, a DC might get only part (i.e., only the GPC or only the GPT, but not both) of a new or modified policy. If that happens, AD doesn't apply the policy. Thus, part of group policy troubleshooting is checking that both parts of a policy have been replicated. You can use the Microsoft Windows 2000 Server Resource Kit Gpotool utility (gpotool.exe—the only Irish resource kit tool, you might say) to check the replication status of every policy.

FRS Replication Pathways
FRS discovers DCs by polling AD about its structure every 5 minutes. So, if you bring up a new DC, you might not see its Sysvol filled for as long as 5 minutes. Although FRS updates local Sysvols immediately, it doesn't update a Sysvol until it knows about the DC that holds that Sysvol share.

During AD polling, FRS also gathers the information that it needs to accomplish intersite replication. Intersite AD replication doesn't occur at a Microsoft-specified interval; rather, administrators set the frequency. By default, AD replicates across sites every 3 hours, but you can stretch the interval to as much as 60 days or shorten it to as little as 15 minutes.

FRS asks AD about other sites and about replication pathways (aka connection objects, in AD-ese), as well as about intersite replication schedules. FRS uses its own schedule to replicate between sites, but it sets that schedule to match AD's. For example, if AD replicates between sites every hour on the half hour, FRS also replicates every hour on the half hour. Notice that distinction: FRS has an independent but parallel replication schedule. As I mentioned earlier, you can't force intersite replications outside that schedule.

FRS Logging
How can you track FRS activity? FRS writes fairly extensive logs to winntdebug. The service starts a new log file every day. By default, FRS keeps only the five most recent log files. You can change the number of log files FRS keeps by modifying a registry entry at HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNtfrsParameters. The entry, of type REG_DWORD, is called Debug Log Files (note the spaces in the entry's name). The entry isn't in the Parameters folder by default, so you'll need to add it. Then, you'll need to restart FRS either from the Services folder in the Computer Management administrative tool or by typing first

net stop "file replication"

then

net start "file replication"

on a command line.

The log files have names like NtFrs_nnnn.log, where nnnn is a number from 0001 to whatever maximum value you've set. And although the log files are ... well ... log files—in other words, formatted for programmers rather than administrators—you can often glean some useful information from them. You can also set the level of information that you want the system to log by creating a REG_DWORD registry entry named Debug Log Severity in that same Parameters subkey. Set the entry at a value from 0 (i.e., no comment) to 5 (i.e., copious output). By default, the value is set to 4.

With luck, you'll never have to worry about FRS working properly. But if you find that some users get one set of logon scripts and others get another set, start sniffing around the FRS logs.