Fear and Loathing: More Windows 7 BranchCache Stuff - Part 1

Yes… I keep getting yelled at.  Post your results, talk about more details…  So, as promised this is the first post in a series of posts that will dive into the technical details about Windows 7 BranchCache.  Once you have all been satisfied, I plan on discussing other subjects/features from Windows 7 and Windows Server 2008 R2. However, first things first, all of the information that I present in these posts can be found in the BranchCache Early Adopter’s Guide and on MSDN as I referenced in my previous post:

• http://msdn.microsoft.com/en-us/library/dd303704(PROT.10).aspx
• http://msdn.microsoft.com/en-us/library/dd357279(PROT.10).aspx
• http://msdn.microsoft.com/en-us/library/dd340715(PROT.10).aspx
• http://msdn.microsoft.com/en-us/library/dd304322(PROT.10).aspx
• http://msdn.microsoft.com/en-us/library/dd303737(PROT.10).aspx  

In other words, this is not super secret knowledge, and I’m not breaking any NDAs.  Sorry…  Instead, I’m merely trying to digest the information for you while also injecting my take on these new features.  Hopefully this is helpful.

Distributed Cache Mode

There are two distribution modes in BanchCache: Distributed Cache Mode and Hosted Cache Mode.  Considering that Distributed Cache mode is the easier of the two to implement, this will be the first mode that discuss.

Summary

Distributed Cache Mode is a Peer-2-Peer caching scheme that is used to cache intranet web site or a file server (SMB) content within a branch office without the need of a local hosted cache server.

Server-Side Configuration

By default, BranchCache is not something that is not enabled.  To enable it on an application server (Web server) or a file server you need to perform a couple of steps:

1. Application Server – You would need to enable the BranchCache feature.
2. File Server – You would need to enable the BranchCache for Remote Files role service which is part of the File Services role.

Additionally, for file servers, you would also have to a few extra things:

1. Configure the Hash Publication for BranchCache GPO setting (Computer Configuration\Policies\Administrative Templates\Network\Lanman Server).  Set this to: Allow hash publication for file shares tagged with “BranchCache support”.
2. Specify the HashStorageLimitPercent registry value(HKLM\CurrentControlSet\Service\LanmanServer\Parameters). This is the maximum percentage of physical disk space used store the publication hashes.
3. Lastly, tag your file shares by enabling Branch Cache support for them.  On the Caching tab, select Only the files and programs that users specify are available offline.  Select Enable BranchCache.

Hmmmmm… what about this Hash Publication stuff?  Well, in my previous BranchCache posting and at the beginning of this post I’ve referenced some links from several MSDN protocol specification documents. Within one of these links you can find some very valuable information around how content is protected, kinda split-up, and also identified.  Yes, as you might have guessed (because of the hash references), content is being hashed when a BranchCache client requests it.

Well kinda of…  What actually happens is the content is first divided into 32MB segments, which is then sub-divided into 64KB data blocks.  These blocks and segments are hashed.  The resulting hashes are then used by clients to not only identify, verify, and reassemble content when it is retrieved, but to also determine if the content should be retrieved from the source content server, or a peer or hosted cache server. These hashes are stored in something that is called a Content Information (ContentInfo) block.

 There is a Content Information block for each data segment and it contains the following items:

• HoD (Segment Hash of Data): The hash of the content block, and hashes of every data block in the segment.
• Kp (Segment Secret): A segment-specific hash that is sent to authorized clients along with the rest of the content information.
• BlockHashList: A list of hashes for each data block within the segment.

It is important to note that the Segment Secret is used to encrypt the data blocks.  So the data is technically protected once it has been cached by a BranchCache client.  Also, as equally important, is that the content server caches all of these Content Information blocks.  This is why you need to define the HashStorageLimitPercent registry value.

Obviously, I do have questions about all of this:

1. First off, what about DFS?  I’m going to assume that the Content Information blocks are only valid for file server that they come from.  I have not tested this, and if I have time, I will try.
2. Also, what about content changes?  I’m going to assume that the Content Information blocks need to be regenerated every time a piece of content is modified.
3. What about Content Bloat?  Each data block hash is 32bytes.  The larger the content, the more hashes.

Ok… that’s enough for tonight.  In my next post, I will go over the client side configuration and the discovery protocol.

If you like this, check out some other posts from Tyson:

• When a computer science degree matters, and when it doesn't
• Since when did cloud computing become/need a manifesto?
• Why would one phish using a Certificate Authority (CA) as bait?
• Would I trust you, if everyone else trusted you?
• Here is a good question: Is scripting programming or just systems administration?
• PowerShell boy and the case of the missing cmdlets!
• Fun with PowerShell 2.0 Eventing!
• Creating a custom 404 page to handle link redirection for ASP.NET web applications

Or if you want, you can also check out some of Tyson's latest publications:

• Windows PowerShell Unleashed (2^nd Edition)
• Windows Server 2008 Unleashed (Yes, I did help on this book)

Lastly, visit the Microsoft Subnet for more news, blogs, and opinions from around the Internet. Or, sign up for the bi-weekly Microsoft newsletter. (Click on News/Microsoft News Alert)

• Microsoft
• BranchCache
• Windows 7