Dfs Tips, Tricks, and Caveats
Before you get too excited about Dfs, realize that it has some limitations—it isn't the final solution for all your offsite data-replication needs, but it's a useful tool to get you started. The first caveat is to recognize what types of data you can replicate with Dfs. For example, Dfs works well with files that users open, change, then close until they need to access those files again. Dfs recognizes that the file has changed and replicates the new version of the file across your network, as needed. Again, Dfs replicates the entire file, not just the changes. Therefore, if you update a large file, Win2K will copy the entire new file to each of the replicas in your network.
In addition to moving data files from one replica to another, Win2K also replicates permissions between the replicas that you define in the Dfs structure. If you add or remove permissions to a folder or file in one location, Dfs will replicate those changes throughout the environment.
The only items that Dfs won't replicate are file locks—the indicators that Win2K uses to determine whether someone else is working on a file. This consideration is important and will most likely affect how you choose to define your Dfs structures. Because Dfs doesn't replicate file locks, two users could be working on the same file at the same time, each with a different copy of the file and completely unaware of the other copy. If this situation takes place and both users save their changes to the network at roughly the same time, a last-writer-wins methodology occurs. For example, one user's changes might be written to disk and synchronized, only to be immediately overwritten by changes saved by the other user. To help avoid this situation, I typically advise people to always consider synchronized replicas as backup shares only, ones that users should never access directly.
One way I typically synchronize replicas as backup shares is to define shares according to the individual sites that own documents, then define a backup share in another site. For example, a repository of sales documents from the New York office might be in a share called NYSALESDOCS. To replicate this information to London, I would create a directory, share it as NYSALESDOCS-BACKUP, then define it as a Dfs replica. This naming convention helps clarify what the share on the London server is all about.
As you can probably guess, if only one master SALESDOCS Dfs share exists for the global organization, Dfs will have a hard time forcing users into a specific share on a specific server because Dfs uses AD sites to determine whether a share is nearby.
Because Dfs replication is triggered by a file change, Dfs doesn't work well with database files that are always open—database files never really encounter a "close" operation, so the data is never synchronized. As a result, Dfs won't help you replicate your Microsoft SQL Server or Microsoft Exchange Server databases.
Keep in mind that Dfs replication is similar to disk mirroring (i.e., the system replicates whatever data it's given, good or bad). As a result, if a virus infects a user's workstation, corrupts all *.doc files, and users modify those files, Dfs will replicate those corrupted files as long as they're in the Dfs structure. This scenario is one example of why traditional backups are still necessary. Finally, by default Dfs can't replicate certain files: .bak and .tmp files and any filename beginning with a tilde (~).
Only a Partial Solution
Dfs is an affordable and reliable mechanism for providing disaster-recovery capabilities for certain types of data in your organization. Considering you've already paid for the capability, you can implement Dfs as part of your disaster-recovery plan and use it to the best of its abilities—with the sincere hope that you'll never end up depending on it.