DFS-R or Branchcache?

ATTENTION!

I’d like to write more about DFS and Branchcache. Which subject within these two fields do you want to read more about? Do you have unanswered questions about any of these two technologies? Please use the comment section below and let me know what you want me to write regarding Brachcache or DFS. Thank you 🙂

Recently I’ve been discussing DFS replication (DFS-R) and Branchcache (BC) as solutions that allow users in regional offices access their files on a central fileserver across the WAN link. As always there is no “one size fits all” answer in the IT business, and so I’d like to share their different pros and cons with you all.

DFS-R was introduces in Windows Server 2003 R2 and replaced FRS (File replication Service) both for replicating Active Directory and for creating your own file server replication. DFS-R is implemented on a pr folder basis, and it will (after the initial sync) replicate only the changes within a file and not the entire file when a user make a change to it, and you can easily customize replication schedule and bandwidth consumption. The replication in DFS-R uses a multiple-master model so any server in the replication group can make changes and it replicates to all other members in the replication group, making this a very easy way to provide duplication of data which can be stored on servers either in the same site or a remote site. Note that DFS-R does not require DFS Namespaces though they are usually combined.

Branchcache is a feature introduced with Windows 7 and Windows Server 2008 R2 which allows a server or client in a remote site to cache data accessed from a file server. Whenever a file is accessed from a BC-enabled share, the client will create a cache of the files data which is now available for other clients is the same site when they try to access the same file. This way only a minimal amount of data, and the files metadata, has to be transferred over the WAN-link and the users can access most of the file over the local network. Branchcahe can be set up in hosted cache mode if the regional office has a local server. This will make this server host the cache and making it available to all local clients. For offices without a server, BC can be set up in “Branchcache distributed mode” which makes all the Windows 7 clients share their caches among themselves.

So what’s the big difference then? The biggest difference is that DFS-R is a replica of the data, while BC is only a cache. Because of this the two solutions act differently pretty much all the time.

Starting with redundancy, the DFS-R creates a complete replica of the data making it available in case one of the servers becomes unavailable, while BC requires the source file server to be available or the users can’t access the files.

DFS-R requires a local server which is Windows Server 2003 R2 or later, while BC can operate in offices without a local server, or a local server earlier than Windows Server 2008 R2.

BC requires Windows 7 Enterprise or Ultimate on the client and Windows Server 2008 R2 on the server, while DRS-R has no client requirements as the files is just another SMB share.

Filelocking is one of the most common challenge with DFS-R because when a user open a document the file is automatically locked for editing for other users, but only for user which uses the same server. The filelock does not replicate and so the file is available for editing on other servers which can cause a conflict. The last one who saves wins, and the other changes are stored in a folder which contains replication conflicts. This of cource something the administrators have to resolve in each such conflict. In BC there is only one file so filelocking works as normal and no users can edit a file that’s open.

As for bandwidth consumption it is really hard to tell as there are many factors that affects how much replication traffic will occur, but DFS-R provides more options to control and tune the replication. BC will save all changes to a file over the WAN-link and pull all file metadata which isn’t in the cache available at the local site. DFS-R will have a complete replica of all the files and after the initial synchronization when you set up DFS-R only the changed file blocks will ever cross the WAN again

Here a simple review of the differences

Filelock

  • DFS-R: Only within the same server, filelock is not replicated
  • BC: Filelock as usual

Filversions

  • DFS-R: If replication conflict, 2 or more versions, must be addressed by admin
  • BC: 1 version

Require server at regional office?

  • DFS-R:Yes
  • BC: Yes, for hosted cache mode. No, for distributed mode

Latency at file changes

  • DFS-R: Minimal (saved at local server, then replicated according to schedule)
  • BC: None

Server requirements

  • DFS-R: Windows 2003 R2 or more recent
  • BC: Windows 2008 R2 Enterprise

Client requirements

  • DFS-R: None
  • BC: Windows 7 Enterprise/Ultimate

Server implementation

  • DFS-R: Server Role, replication groups manually set up.
  • BC: Share property, GPO settings

Client implementation

  • DFS-R: None
  • BC: GPO settings

Available if WAN goes down?

  • DFS-R: Yes
  • BC: No

Data duplicaiton?

  • DFS-R: Yes, each server has a full copy of the data
  • BC: No, files are stored centrally with some data available locally

And if you have several regional offices, remember than you can use both solutions and give DFS-R to some offices and let the rest use Branchcache.

Advertisements

3 thoughts on “DFS-R or Branchcache?

  1. Pingback: Branchcache demonstration, part 1 | Per-Torben Sørensen

  2. Nice Article, Do you know if you can could use both? As In, let users in a site access files from their local DFS target. But if they access something on the namespace that has a target remotely, then use branchcache. Would branchcache work in this scenario?

  3. Hello, and thank you for your comment and question. Both are very much appreciated.

    Let us say we have a Paris office and a London office. Users in London access files from a DFS Namespace (DFS-N) link that points to the share \\london-fileserver\data and it works great. So let’s say that we have another fileshare: \\paris-fileserver\data2. Now assuming Branchcache is set up correctly and the data2-share is Branchcache enabled, then data accessed from \\paris-fileserver\data2 will be cached in the London office.
    Then we bring in DFS-N and create a DFS-N link which points to \\paris-filserver\data2. The users access the same share which is Branchcache enabled and they have been referred to that UNC path by DFS. Since the users still connect to the same share, Branchcache should still work.

    Keep in mind that Branchcahce is not site-aware, but uses network latency to determine whether files from a share should be cached or not. There’s a group policy setting for controlling that behaviour. So if the latency between London and Paris is low enough then no data will ever be cached.

    I hope this information was helpful to you. 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s