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 \winnt\sysvol\sysvol, 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.