Boswell's Q&A

Two Places At Once

How to work around a VPN connection that's keeping remote users hanging for a while longer than this admin likes.

• By Bill Boswell
• 04/26/2005

Quite a few of the users travel back and forth between offices and plug into the network with laptops. They complain that it takes them a long time to open their files when they aren't in their own office. I did some checking and it's because we redirect their My Documents folder to their home drives and the VPN is really slow so it takes a while for them to open large files.

Is there some way to speed this up?
—Name withheld by request

Anonymous: As long as the data is only accessed by one user at a time — which is typical of home directories and My Documents — you can use the Distributed File System (Dfs) to maintain replicas of the user data in both offices.

Dfs creates a virtual "volume" in which each folder is actually a link to a share point on another server. This creates a share point on a target server that forms the root of the Dfs volume. Information about this volume is saved in Active Directory so any client that's a member of the domain can map a drive to this virtual Dfs root in the same way that a drive is mapped to a regular share. You can then create links under the root that point at shares on other servers.

For the examples, I'm going to assume that you have a Windows Server 2003 domain. You can use Dfs in Windows 2000, but the interface and terminology is a little different. I'll call the domain Company.com.

Let's say the two servers where you store user home directories are HQServer and BranchServer. The UNC paths to the user home directories on these servers are:

\\HQServer\UserFolders
\\BranchServer\UserFolders

You would start by creating a domain-based Dfs root called Dfsroot. The nice part about domain-based roots is that clients can map a drive to the root using just the domain name, such as:

net use u: \\company.com\dfsroot

You would then create Dfs links to the UserFolders shares on the two servers. You can use a "path" string for a link name, which gives the impression of a hierarchy when displayed in the Dfs volume.

For example, you could create a link named UserFolders\HQ and point this link at the \\HQServer\UserFolders share. In Dfs, this would appear as a hierarchy of folders under root:

\\company.com\dfsroot
=====================
          |
          |
          UserFolders
          ===========
               |-- HQ

You could do the same for the branch office server. Create a link named UserFolders\Branch that points at the UNC path \\BranchServer\UserFolders. The Dfs folder hierarchy now looks like this:

\\company.com\dfsroot
=====================
          |
          |
          UserFolders
          ===========
               |-- HQ
               |-- Branch

Here's where Dfs gets interesting for your situation. Create a new shared folder on both servers to hold user data from the other server. For example, HQServer would have a shared folder called BranchUserFolders and BranchServer would have a shared folder called HQUserFolders. Initially, leave these folders empty.

In the Dfs management console, right-click the UserFolders\HQ link and create a new target that points to the HQUserFolders share on BranchServer. Then right-click the UserFolders\Branch link and create a new target that points to the BranchUserFolders share on HQServer.

When you create a second target for a Dfs link in Windows Server 2003, a Replication wizard will walk you through configuring replication between the two targets. When asked to select an initial master, choose the share with data in it. (The other share should be empty. If it isn't, the files will be copied to a hidden folder where you can pull them out later.) Specify a Ring topology, although with two targets; the topology selection doesn't really matter.

At this point, sit back and have a cup of coffee and catch up on your e-mail. In a while, Ntfrs will get to work and replicate content from the primary target to the secondary target. Once the files have been fully replicated, changes made at either target will replicate to the other. The replication uses the same interval as you defined for inter-site Active Directory replication. This is three hours by default although just about everyone drops the interval down to the minimum of 15 minutes.

Once the initial sync finishes, the amount of WAN traffic generated to keep the data in sync is small compared to the amount of traffic generated by constantly going across the wire to open files. If a file is changed on one target, though, a full copy of the file is replicated to the other target.

You now have two Dfs links that point at exact replicas of the user data, one in HQ and one at the branch office. Now change the UNC paths for user home directories and redirected My Documents folders to point at the Dfs links rather than the actual shares on the servers.

When a user travels from HQ to Branch and plugs in a laptop, Dfs will determine the user's location based on IP subnet and point the user at the local replica.

A couple of caveats about using multiple targets in Dfs. Don't use it to replicate data that can be accessed by more than one user at the same time. Ntfrs replicates the last update, no matter where it occurs, which will overwrite the copies on other servers. In other words, there is no distributed lock tracking in Dfs.

Also, with the current version of Dfs in Windows Server 2003 (including SP1), you don't want to replicate mountains of data. The replication engine used by Dfs is the same Ntfrs used to replicate Sysvol between domain controllers. Ntfrs gets a little cantankerous if it's asked to handle gigabytes of files.

However, in just a few months you'll be able to get your hands on Windows Server 2003 R2, which has a brand-spanking new Dfs replication engine that's tuned for just this sort of branch office work. You'll be able to download a beta of R2 very soon to use for testing.