Windows Server 2008 R2 and Windows 7: BranchCache


The arrival of Windows Server 2008 R2 and Windows 7 is just around the corner and I don’t have to tell you that there are a lot of expectations. Common users are concentrating almost all the attention with the client operating system, but I can assure you that having those new platforms, Windows Server 2008 R2 and Windows 7, will give a new perspective for all users and IT guys.

One of the highlights that you can watch having this two boys together is BranchCache, focused mainly in optimizing your WAN bandwidth using special cache options.

As the name says it, BranchCache works in scenarios with branch offices where clients interact and request files from the headquarters. A common and current scenario is related when you access an internal website with the servers located in the main office, each branch office client will request the files directly with the headquarters every time a user intends to communicate with the site, significantly affecting the WAN link with the same data transmitted over and over.

BranchCache is a simple idea that caches every content downloaded from the main office using a server or other branch clients, so every time that a second client tries to download the content, the request is directly handled within the branch office optimizing the WAN link and downloading time.

How Does It Work?

There are no complex configurations and you can even use an option that does not include a server. There are two types of BranchCache deployment options: Distributed Cache (no server) and Hosted Cache Mode (Windows Server 2008 R2 server involved as the cache server).

Keep in mind that the environment will only work with Windows Server 2008 R2 and Windows 7 clients.

Distributed Cache

Windows 7 branch office clients store a copy of the content that is downloaded from the main office, and makes it available to other clients in the branch office every time that they try to retrieve those files.

Hosted Cache

Within this scenario, all the cache content is stored and controlled in a Windows Server 2008 R2 that retrieves all the requests made from branch clients and keeps all the data locally to answer any other requests for the same content.


Microsoft recommends to use this mode on branch offices with over 10 clients.

What About Cache Authorization and Updates?

These are common questions that you may be asking yourself right now:

Q: If the files are stored in a local cache within the branch office (distributed among clients or on a server), that means that all branch users will have access to these files?

A: No. There is an authorization phase that the requestor must complete before receiving the file. In a distributed BranchCache mode, when the client requests the data, the server (main office) authorizes, or not, the cache content to be delivered to the branch office client. In a Hosted Cache mode, the cache server keeps identifiers with the permissions for each cached content, giving access only to authorized clients.

Q: What about if the file changes when it was already cached by clients or a server? The file is distributed out-to-date to branch clients?

A: No. Whenever a change is made on a folder that is distributed with BranchCache, a new identifier (the same used for access authorization) it’s send to branch cache clients (if the mode is set as Distributed Cache); or send it directly to the cache server (if the mode is configured as Hosted Cache).

Configuring BranchCache

In this section I’ll give you small step-by-step BranchCache procedure. There are basically three steps to complete the environment:

1. Configure the headquarters Windows Server 2008 R2 that contains the data that must be cached.

2. Configure the Windows 7 branch clients that will use the cached content.

3. Configure the Windows Server 2008 R2 as Hosted Cache server, if that’s the option you selected for your environment.

The complete reference to achieve this deployment can be found inBranchCache Early Adopter’s Guide.

1. Configuring the File/Web Server

a. Add the feature from Server Manager: BranchCache.


Remember, it’s a feature not a role.

b. If this is going to be a file server, you must add the “File Services” role and the service “BranchCache for remote files”.


c. Configure the Group Policy to enable BranchCache.

Active Directory it is not a requirement for BranchCache, but surely it is recommended for centralized management. You can use an Active Directory or local policy to apply to this server.

The GPO can be located in Computer Configuration > Policies > Administrative Templates > Network > Lanman Server > Hash Publication for BrandCache


The options when you Enable this GPO are self explained: For all shares, files shares tagged and disallow hash publications.


2. Client Configuration

Ok, now you have the server configured to be able to distribute the BranchCache shares. Now it’s time to configure the clients to understand this type of cache. It is easily done with Group Policies, and again, this can be done in a domain environment by linking GPOs or just using Local Group Policies.

a. Access GPOs editing MMC: Computer Configuration > Policies > Administrative Templates > Network > Turn on BranchCache > Enabled.


b. On the same GPO list, you’ll find the rest of the necessary configurations according to the chosen model.

If you are using Distributed Cache, enable “Turn on BranchCache – Distributed Caching Mode”. And the same for hosted cache, “Turn on BranchCache – Hosted Cache mode”.

c. [optional] You can also set other interesting values using this set of GPOs, like latency values or setting a percentage of your disk space dedicated to this cache.

d. Ensure that you have configured the firewall inbound policies to allow BranchCache connections. More info about this on the document mentioned above: BranchCache Early Adopter’s Guide.

3. Configure the Cache Server

For obvious reasons, the communication between the parties involved must be secured and the data available must be guaranteed as updated and correct. That’s why if you are using Hosted Cache Mode, a certificate will be present to achieve a SSL communication and guarantee that data is not modified by an attacker.

It is important to note that the presence of a Certificate Authority (CA) server it is not a requirement, the certificate can be prepared directly from the file/web server and then imported to the Hosted Cache server.

a. First, enable the BranchCache feature from Server Manager.

b. Deploy the certificate inside Certificates (Local Computer) > Personal.


c. Access the certificate properties, the details page will show you the “Thumbprint” field. Copy to the clipboard.

d. Link the certificate to BranchCache with “netsh”:

NETSH HTTP ADD SSLCERT IPPORT= CERTHASH=<thumbprint> APPID={d673f5ee-a714-454d-8de2-492e4c1bd8f8}

More Resources

Here are some other guides and interesting links you can find about this feature.

That’s pretty much in this BranchCache overview and kind of walkthrough.




  1. Pingback: Cameron Fuller
  2. Hi,

    I have a little question, I was on Tech.Ed Berlin and heard allot about branch cache.
    I’m thinking in the security point of view.
    I couldn’t find anyone that could answer my question, so after reading your blog, you might be able to answer my question.
    A client request a file from offlcation, it’s gets the current file id, then broadcasts it out on it local subnet, requesting other clients for a copy of the file. No one replyes, and it starts downloading the file to it’s own cache.
    If I understand til right, then by sniffing the network subnet, I will know what file the client is requesting, and thereby it would be possible to request the file and get a copy, wont it? ofcause there is some security encryption and so on, but in theory?

    • Hello Kenger,
      That is actually a great question. And let me tell you that security is a key aspect in BranchCache, I think you can find the answer to that question within this link
      Steps 7, 8 and 9 are related to securing the content available (using Hosted Mode or Distributed Cache):

      7.The caching computer encrypts the blocks with an encryption key that is derived from the content metadata (using AES 128 by default) and sends it to the client.

      8.The client decrypts the data by using the same encryption key that the caching computer. The client and the caching computer compute the same encryption key because they derive it from the same content metadata, which is sent by the content server.

      9.After the client decrypts the data, it validates that the data is not corrupted or tampered. To do this, the client computes the block hashes on the blocks received, and then compares them to the block hashes received in the content metadata from the server. If the hashes do not match, the client discards the data.

      Hope it helps!

Leave a Reply

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

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

Facebook photo

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

Connecting to %s