Working with the Windows 2000 File Replication Service

If you have lots of users sharing access to a single file, your server might be a bottleneck to smooth performance. Fortunately, you can use the Windows 2000 File Replication Service to replicate the file to multiple servers. Brien Posey shows you how.

Have you ever seen a server get bogged down because too many people are accessing a common set of files from a single share? If too many people access a share, the server can have a difficult time fulfilling all of the requests. That’s because such an operation consumes the server’s memory and processing power and can tie up the server’s hard disk.

So what do you do if you need to make a common set of files available to a large number of users? If users plan to access the files often, one solution is to replicate the files to multiple servers. By doing so, you can take the strain off of a single server and distribute the workload across multiple machines. In this article, I’ll explain how this process works.

How does the File Replication Service work?
If you think making files available across multiple servers sounds a lot like clustering, you’re right. You can think of the File Replication Service as a sort of poor man’s clustering scheme. The File Replication Service doesn’t require that you run Windows 2000 Advanced Server and use a lot of special hardware, but then again, it doesn’t offer as many features either.

So how does the File Replication Service work? At it’s simplest, the File Replication Service allows you to make a copy (or replica) of files existing on one server available on other servers. The original files can exist on either a domain controller or on a member server and can be replicated to either domain controllers or member servers. Likewise, a single server can receive replicas from many different servers.

As with Active Directory replication, the File Replication Service uses a multimaster replication model. This means that file updates can be applied to either the original copy of the replicated files or to any one of the replicas. The change is then propagated to the remaining servers in the replica set. When an update does occur, the replication process copies entire files. This means that even if you only changed a single byte in a replicated file, the entire file would be copied to each server in the replica set. Of course, this can result in quite a bit of replication-related traffic. Therefore, it’s best to replicate files that won’t be frequently changed. If you’re dealing with a set of files that do get updated frequently, it’s a good idea to weigh the benefits that you’ll gain from replicating the files against the increased amount of network traffic that you’ll generate in the process.

What about conflicts?
If you have copies of a file spread all over your network, there’s always the chance that two different users will attempt to update the file simultaneously. If two users were accessing the file from a single share, this wouldn’t be a problem. Windows 2000 would lock the file while the first user was working on it and no one else would be able to make changes to the file until that user finished and Windows unlocked the file. However, in a distributed environment, there’s absolutely nothing stopping two or more users from simultaneously modifying multiple copies of a file.

Needless to say, a situation like this creates a conflict. Fortunately, Windows 2000 has several methods that it uses to resolve conflicts. Any time a user makes a change to a replicated file, Windows 2000 begins the replication process when the file is closed. As each member of the replica set receives the updated file, those machines must make a decision to either accept the changes or to reject them.

The first step in the conflict resolution process is for Windows 2000 to look at the time stamp of when the file was last updated. For example, suppose that you made a change to a replicated file. As the other members of the replica set received the change, they would check to make sure the changed file was at least 30 minutes newer than the existing copy. If the file is at least 30 minutes newer than the server’s current copy, the server accepts the change. If the file is at least 30 minutes older than the existing copy of the file, then the server will reject the change.

So what happens if two copies of a file are updated within 30 minutes of each other? In such a situation, the File Replication Service would compare version numbers. Version numbers are similar to Active Directory’s Update Sequence Number. A version number is simply a number that’s applied to the file as an attribute. The version number keeps track of the number of times a file has been changed. Therefore, if two copies of a file were updated within 30 minutes of each other, Windows 2000 would look at their version numbers. The file with the higher version number would be accepted while the file with the lower version number would be rejected.

If two copies of a file are updated within 30 minutes of each other, and their version numbers are equal, Windows will look at the time stamp again—this time ignoring the 30-minute rule. Whichever file is newer will be the file that’s accepted.

Restoring replicated files
As you can see, the replication process follows a basic technique in which the newer file is accepted. The file that’s accepted becomes authoritative. This means that it will become the master copy that will be replicated to the other members of the replica set (until another update is made). However, simply accepting the newest copy can be a dangerous thing. For example, suppose for a moment that you had a 500-page document replicated among several servers. Now, imagine that some idiot erased the contents of all 500 pages and then saved the changes. The changes would be replicated to every member of the replica set. Unfortunately, there’s no getting around this problem because to Windows 2000, the change was intentional.

If an invalid copy of a file is replicated to your entire network, your first instinct may be to simply restore the file from backup. However, remember that the copy of the file that’s stored on your backup media has an older time stamp than the damaged copy on the network. This means that even if you restore the file, the copy from the backup would be rejected because of its age. The solution to this problem is to do an authoritative restore.

An authoritative restore is a process by which you tell Windows 2000 that you want the file from your backup to be accepted regardless of its age. By default, the backup program is designed to restore replicas in a nonauthoritative manner. However, you can force an authoritative restore by using the When Restoring Replicated Data Sets, Mark The Restored Data As The Primary Data For All Replicas option. When you use this option, the restore process will update the version number of the restored file to allow it to be replicated to the other servers in the replication set.

Backward compatibility
Windows NT offered a type of file replication through the use of the LMRepl Service; however, this type of replication is completely different from the type offered in Windows 2000. The Windows NT version was used primarily to replicate login scripts among domain controllers. Since the two types of replication are incompatible with each other, you’ll have to do some manipulating if you want to replicate login scripts in a domain that contains Windows NT and Windows 2000 servers. In such an environment, if you want to continue to replicate login scripts, you’ll have to make sure that the server containing the Export directory (the directory containing the login scripts) is the last server that you upgrade to Windows 2000. Once this final server is upgraded, you can switch to the Windows 2000 version of replication.

It’s a common practice to store the original copy of the login scripts in the EXPORT directory of the Primary Domain Controller (PDC). However, as you know, when you’re upgrading to Windows 2000, the PDC is the first domain controller to be upgraded. Therefore, to maintain the ability to replicate login scripts, you’ll have to manually move the scripts from the PDC’s EXPORT directory to the EXPORT directory on a different server.

Setting up the File Replication Service
Windows 2000 installs the File Replication Service automatically on all servers. If the server is a domain controller, the File Replication Service is set to start automatically. If the server is a member server, you have to start the service manually.

The primary method of replicating files is through a Distributed File System (DFS) tree. The method that you use for DFS replication really depends on what you want to replicate. You use one method for replicating the entire DFS root and a different method for simply replicating a group of files or folders within the DFS tree.

Replicating the DFS root
To replicate the entire DFS root, open the DFS console by clicking Start | Programs | Administrative Tools | Distributed File System. Select the root that you want to replicate. Next, select the New Root Replica command from the Action menu.

When you do, Windows will launch the New DFS Root Wizard. The wizard will ask you a few basic questions such as the DNS name of the server on which you want to host the replica and if you want to use an existing share on that server or create a new share. You can repeat this process as many times as you need to create the appropriate number of replicas.

Replicating individual files or folders
Another option is to replicate individual files and folders rather than replicate the entire DFS root. Windows 2000 allows you to create up to 32 replicas of any folder. To replicate a folder, open the DFS console and select the DFS link for which you want to create replicas. Next, select the New Replica command from the Action menu. When you do, you’ll see the Add A New Replica dialog box. Enter the path to the folder of the share that should store the replica, in UNC format.

You’ll also have to specify whether or not you want to use automatic or manual replication. If you choose to use automatic replication, the replication cycle will take place every 15 minutes. You can repeat this process as many times as you need to create the appropriate number of replicas.

Enabling the replicas
After you’ve created all of the desired replicas, select the Replication Policy command from the Action menu. When you do, you’ll see the Replication Policy dialog box. This dialog box contains a list of all of the replicas that you’ve set up. Select each item on the list and click the Enable button. Finally, select the replica that you want to be the initial master and click the Set Master button followed by the OK button.

In this Daily Drill Down, I’ve discussed some of the issues that you’ll face when you replicate files across multiple servers. I also explained how the File Replication Service works.

Editor's Picks