I'm currently learning Windows Server 2008r2 and am going to be setting up a network which spreads over 2 different buildings. The only connection between them is the internet and the users need to be able to access their files from the file server and login from both locations.

If I'm understanding it correctly I should be able to set up a VPN connection from the main server (and file server) which is stored in one of the buildings [site 1] to another server at the other building [site 2] and I can set the server at site 2 also as a domain controller so there's a domain controller at each site and they will keep in sync with each other.

If I set up another file server at site 2 is there a way I can keep the files in sync from both sites without causing conflicts? Or is there a way that I could maybe just have a cache at site 2 which will contain temporary copies of files that are accessed (meaning it wouldn't need to store everything again)?

If anyone currently has a setup like this it would be really helpful if you explain how you've done it and if there's much of a lag between the locations.


  • 1
    The answer is: DFS. – joeqwerty Jul 13 '12 at 21:01

Depending on the use case, you have two options. DFS and Branch Office Cache.

One big difference is there is no need for a local server with Branch office cache. It will distribute the cache quietly among the Windows 7 clients. There is a good +/- chart here: http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2branchoffice/thread/efabcbe4-bb90-4aec-ba67-a3780d242e4b

  • If I set BranchCache up in 'hosted cache mode' do you know if this checks if a file has been modified across the wan before serving it from the cache, and updates it if it has been modified? What I mean is would it prevent someone opening a file that had just been saved at the source location and getting the old version like what could happen with DFS? Thanks – Tom Jenkinson Jul 13 '12 at 21:56
  • I think Branch Office Cache gets the hash across the wan every time a file is requested so it should work how I want and I'm going to go with that. Thanks – Tom Jenkinson Jul 14 '12 at 13:06

joeqwerty's answer is the same I'll give. But I wanted to ask a few questions about the "shared" files. DFSR works great for replicating data between two servers. (over a LAN or WAN). But you'll need to consider file contention issues if more than one person is working on the files at the same time. Generally speaking the users would want to access the files that are the most local to them. If you are talking user shares, this works great, but if you are talking about departmental shares where users are accessing the same files at the same time, they would need to be working on the same copy of the file. (meaning pointed to the same server). DFS is great for creating a share that looks and feels the same no matter which location you were at. But it has the added benefit of giving you tools to point the users to the most local copy of the files. As far as lag goes, it would depend on your connection speed between locations, and the size of the changes made to the files.

  • Having no distributed lock manager makes general-purpose file shares hosted by DFs-R a bit of a pain if you have users contending for the same files. As an aside, block-level DFS replication (called DFS-R) has existed since Windows Server 2003 R2. – Evan Anderson Jul 13 '12 at 21:28
  • You are correct, I was thinking of Remote Differential Compression. But yes, the locking and contention issues are a pretty big hurdle. – MikeAWood Jul 16 '12 at 20:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.