We have a small stub office that currently has a single server 2003 domain controller, and a DFS-R copy of the file store held at our main office. We probably replicate about 100Gb of data, I would guess about 20Gb maximum is actively used at both ends. We have (relatively) slow ADSL links between sites.

Replication mostly works quite well for us, except on instances where we make changes to security on some of the replicated files. - this causes a huge backlog of changes that seem to take several days to clear. I've been reading some other posts about issues, and also about the new Branch Cache feature that Windows 7 & Server 2008 R2 have to offer, and as I understand it, the pros and cons are as follows:

Branch Cache


  • No version conflicts
  • Fast access for subsequent access


  • Slow access for first time access
  • Slow write access



  • Quick read/write access to data at all times
  • A limited amount of additional data security


  • Backlogs can occur very easily
  • Version conflicts can be an issue with backlogs
  • Replication can take too long - not suited to real-time access to files between offices.

Has anyone tested branch cache? I'm wondering if know how well branch cache performs in the real world? Would it be better than DFSR for our setup? I would imagine it could be very useful if I were able to pre-fetch chunks of data (I guess I could do this manually with robocopy and delete!). The only concern I have is the fact that data writes would be slow.

I've also been considering implementing sharepoint at our main office. I think this might just swing in favour of Branch Cache.

Obviously if I decided to go with branch cache it would have to pass testing, but I just wanted to know if I'm missing any other pros or cons that might persuade me one way or the other?

I'd probably keep our AD deployed software as DFS-R replicated and maybe even user specific data (e.g. Home Directories and Profiles), otherwise the writes would surely cause delays on the clients?


It sounds like BranchCache may be a good fit for you, though you may also benefit from some performance improvements in DFS-R made in Server 2008 and Server 2008 R2.

There have been some case studies written about BranchCache that may tell you more about BranchCache performance in the real world. Just search for "BranchCache case study".

BranchCache is careful to always honor the most current access control settings on any piece of content (file, web page ...). Before a client pc can download data from the cache in the branch office (either on a hosted cache server or on a peer) it must obtain content identifiers from the main office server. If the client doesn't have permission to access the data, the main office server won't send the identifiers. There are a bunch of documents explaining how this works on branchcache.com.

If you want, you can pre-load the BranchCache cache by having one of the clients in the branch (or the actual hosted cache server) access data ahead of time. This might be scriptable in some cases if you want to preload the cache before workers get in.

If you're going to keep a server in the branch, and you're going to upgrade to R2, there's no reason why you can't deploy a combination of BranchCache and DFS-R. A single box can act as a DFS-R replication point and as a hosted cache server simultaneously. You can get sharepoint and SMB optimization this way, and by spreading your data across the two technologies, you can get the best properties of each for your various categories of data.

I hope this helps! -Tyler

| improve this answer | |
  • Thanks, good answer. TBH I wasn't aware of improvements to DFS-R in Server 2008 & Server 2008 R2. I'll certainly have to do some more digging. – Bryan Oct 13 '09 at 22:41

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.