A not-so-distributed file system

A key feature in Windows 2000 Server is DFS, short for Distributed File System. DFS is handy because it lets you point all network drives, no matter what server they physically occupy, to a single virtual share. That means no more mapped drives. Users simply get a single network drive with all their previous mapped drives appearing as directories beneath the virtual one. If you’ve ever had to explain the difference between the Resource folder on the S: drive and the Resource folder on the G: drive to a user while their eyes glaze over, you know how much easier DFS can make your life.

I haven’t had as much luck, however, with DFS’s Replication. This feature is designed to mirror two file systems over a networked connection. Imagine 20 users in separate Manhattan locations using a single Manhattan-based server, called Infoworld2, for most of their local serving needs. Meanwhile, 100 users at corporate headquarters in southern New Jersey are using their local server, called Infoworld1. With DFS Replication, what corporate users save in Jersey appears in New York and vice versa.

Sounded great until I actually tried it. For one thing, Microsoft really didn’t intend this feature to be used over a WAN; most of the company’s documentation refers to mirroring two file systems on the same LAN. Useful, I suppose, for large buildings or campuses, but I wish Redmond had kept the WAN in mind. DFS Replication creates significant traffic and can quickly choke a WAN pipe, so not only is other traffic impeded, but files that users save to one repository take an unduly long time to show up elsewhere.

Initial implementation can be problematic, as well. For large data repositories, polishing one repository and then replicating it to the other might seem the right way to go, but it’s not. Replication is basically large-scale syncing and that’s a resource-intensive operation. Asking one server to suddenly “sync” a few dozen gigabytes of data to where none existed before is not a simple copy command. It creates lots of traffic and takes loads of time; days in some cases. You’ll also be building large temp files based in part on the size of files being replicated. If you’re running this operation in a small OS-only C: partition (as I did originally), you’re almost guaranteed a replication crash. And depending on how replication crashes, you can lose data in the process.

You’re much better off getting the original file repository ready via the usual house cleaning steps and then connecting your target server locally. Then just copy the repository from one server to the other without using replication. Once the copy is done, the target server can be redeployed at the remote site and DFS Replication can be switched on.

I’ve managed this at a number of client sites and it works reasonably well. I’d still like to see more flexibility from the configuration side, such as being able to schedule replication at shorter intervals than 15 minutes. I’d definitely like to see a way to force replication. Occasionally, I still get a call from an irate user who just saved something to server A and now can’t see it on either A or B. This is because it’s temporarily lost in DFS Replication limbo; it usually turns up again within a few minutes.

On the upside, Microsoft has promised some improvements for DFS in Windows Server 2003. You’ll be able to do multiple DFS roots, for example, which is certainly nice for large organizations. No word yet on DFS Replication in Windows Server 2003, but as soon as I get a chance to test it in the real world, I’ll let you know.