Setup BranchCache for ConfigMgr Current Branch

In a previous post: Setup Peer Cache in ConfigMgr Current Branch, I explained how to setup ConfigMgr for Peer Cache to reduce the network impact when using ConfigMgr for software distribution.

Peer Cache and BranchCache

In this guide, you learn how to setup BranchCache for ConfigMgr, and in many cases that's all you need in addition to Delivery Optimization which is yet another P2P platform. That being said, BranchCache and Peer Caching can work together, where BranchCache can act as a backup, and also to peer content that Peer Cache cannot peer, like ConfigMgr policies.

Here is a quick summary of BranchCache and Peer Caching features:

BranchCache

• Peers on the local subnet only (unless adding in a third party solution, then it can span multiple subnets)
• Can start peering content as soon as the first client receives a few blocks of the file
• Can peer all ConfigMgr package types, as well as ConfigMgr policies
• Uses a separate cache than the ConfigMgr client
• Can utilize ConfigMgr content that has been data deduplicated to further reduce network impact.

Peer Cache

• Peers on boundary group level or on local subnet (configurable on the boundary group)
• Cannot start peering content until the entire package has been downloaded
• Can peer all ConfigMgr package types, but not ConfigMgr policies
• Uses the ConfigMgr client cache

Step-by-step guide – Setup BranchCache for ConfigMgr Current Branch

The following is a quick guide to setup BranchCache for ConfigMgr Current Branch, and how you can verify that it actually works.

Creds: A shoutout totally goes to @ozthe2 for one of the early write-ups on using BranchCache with ConfigMgr.

The guide in this post covers five simple steps to get it going:

• Step 1 – Enable BranchCache on the Distribution Points
• Step 2 – Enable Data Deduplication on the Distribution Points
• Step 3 – Configure BranchCache on the clients
• Step 4 – Make sure your ConfigMgr packages and application are enabled for BranchCache
• Step 5 – Verify that it works    

But first. a little bit of background.

Introduction to BranchCache

BranchCache is available in Windows 7 / Windows Server 2008 R2 or later versions of Windows (I better mention that it has limited support via BITS 4.0 in Windows Vista and Windows Server 2008 before the good folks at 2Pint Software crack down on me 🙂  ). However, if you are still deploying Windows Vista or Windows Server 2008, in the year of 2017, please stop 🙂

Anyway, like Peer Caching, BranchCache is a technology for optimizing network bandwidth, or simply put: It helps you download content in distributed environments without killing the network. Now, BranchCache comes in two flavors:

• Distributed Cache Mode. The mode that ConfigMgr supports, and in this mode clients are sharing content with other clients.
• Hosted Cache Mode. This when you are using local servers to cache content for the clients. Since this is not used with ConfigMgr, I won't mention this mode any more in this guide.

How BranchCache works in Distributed Cache mode (with ConfigMgr)

BranchCache may look pretty simple at a first glance, but once you go behind the scenes there is quite a lot of things going on to make this work. That being said, you don't need to be a super-expert on BranchCache to use it. Once configured correctly, it behaves nicely without much need for maintenance, and when your manager asks "what's in it for us", you simply answer that it makes everything go faster, and it reduces the network traffic on our WAN links. And it's free. Solution sold. 🙂

Tip: If you really want to learn BranchCache in-depth, Mr. Andreas Hammarskjold (@andhammarskjold) presented a pretty shiny session at Microsoft Ignite. It's one of those sessions you probably are going to watch a few times, and it's not because it's not a good presentation, it's simply because there is a lot of info to take in (it is a good presentation). Here is a link to the session: Dig deeply into BranchCache: learning from the experts.

Back on track. The simplified version of how BranchCache works in distributed cache mode is like this:

1. A ConfigMgr client requests a file on a BranchCache enabled distribution point (DP), and as part of that process, the client tells the DP that it's BranchCache capable.  
2. The DP responds, and since it was told the client was BranchCache capable, it won't provide the file to the client, but rather a collection of content identifiers, that define the content the client wanted. In this case a file.  
3. After receiving the content identifiers, the ConfigMgr client then tries to find a local computer (peer), on the same subnet, that already has the content (again the file).  
4. If another ConfigMgr client has the content, the first ConfigMgr client will download the file from it's peer.  
5. If the first ConfigMgr client can't find a local peer with the content (on the same subnet), it will once again contact the DP, this time saying it's not BranchCache capable.  
6. Since it's a "normal" file request from a "normal" ConfigMgr client, the DP happily hands over the file to the client, which puts the file in its local cache, ready to be requested by another client.

Scenario

In my lab, I have two sites; New York (192.168.1.0/24) which has a local DP, and Chicago (192.168.4.0/24) which does not have a local DP.

• New York:  With the CM01 DP, has five clients: W10PEER-0001 – W10PEER-0005.  
• Chicago: With no DP, has five clients: W10PEER-0006 – W10PEER-0010.   

Note: To setup a lab with multiple routed networks I recommend using a virtual router instead of the typical NAT switch in Hyper-V or VMWare. It can be based on either Linux or Windows, and you can find a step-by-step guide here: https://deploymentresearch.com/285/Using-a-virtual-router-for-your-lab-and-test-environment.

Step 1 – Enable BranchCache on the Distribution Points

To enable BranchCache on a DP you should do two things: The first one, enabling the ConfigMgr BranchCache feature itself, is mandatory. The second one, moving the Publication Cache to a Data Volume and increase the size of it, is not mandatory, but highly recommended.

Let's start with the configurations you do in the ConfigMgr console.

1. Using the ConfigMgr console, in the Administration workspace, right-click your DP (CM01 in my example), and select Properties.

2. In the General tab, select the Enable and configure BranchCache for this distribution point check box, and click OK.

Note: The preceding steps will install the BranchCache feature on the server, which you can verify by running the following PowerShell command:

Get-WindowsFeature -Name "BranchCache"

To move the Publication Cache to a different volume, and increase the size of it. Run the following PowerShell commands (modify line 1 and 2 to match your environment:

$NewHashFolder = "E:\BCPublicationCache"
$NewHashSize = 10GB

New-Item -Path $NewHashFolder -ItemType Directory
$BCCache = Get-BCStatus
Set-BCCache -Path $BCCache.HashCache.CacheFileDirectoryPath -MoveTo $NewHashFolder -Force

$BCHashCache = Get-BCHashCache
$BCHashCache | Set-BCCache -SizeBytes $NewHashSize -Force

Step 2 – Enable Data Deduplication on the Distribution Points

Data Deduplication is not a requirement for BranchCache, but if you do enable it, not only do you save quite some disk space on your DPs, but BranchCache will now have all hashes pre-calculated as part of the data deduplication process.

1. On your DP, using Server Manager (or PowerShell), add the Data Deduplication role (in File and Storage Services / File and iSCSI Services).

2. Reboot the DP if needed. Server Manager (or PowerShell) will let you know if it's needed 🙂

3. Using Server Manager / File and Storage Services / Volumes, on the disk volume having the Content Library (SCCMContentLib folder), right-click CM01, and select Configure  Data Deduplication.

4. In the Volume Deduplication Settings dialog box, select General purpose file server, and select to deduplicate files older than 1 day.

Warning 1: Since ConfigMgr only supports Data Deduplication on the Content Library (SCCMContentLib folder) and the SMSPKGx$ folders, make sure to enable Data DeDuplication only on that volume. If you have other ConfigMgr folders, like the installation folder (if this is also your site server), SQL folders, Remoteinstall folder (WDS), package sources, BranchCache Publication Cache, DOINC/MCC, etc., they must be excluded.

Warning 2: Read Warning 1 again. Make sure to only deduplicate ConfigMgr folders that are supported, and possibly non-ConfigMgr folders that you KNOW can be deduplicated (such as a MDT Lite Touch Deployment Share for example).

Step 3 – Configure BranchCache on the clients

BranchCache can be enabled both via group policy, or via a series of registry settings and netsh or PowerShell commands. The reason you want to use the latter is because that gives you additional control of the settings. For example one important settings, being able to set the port used for BranchCache.

So why is assigning port a big thing? Well, BranchCache by default is using port 80, so if you have a local web server, or an app using the same port (Skype), the BranchCache service may not start. And this is kind of bad :).

Anyway, the guys at 2Pint Software has created a Configuration Item for ConfigMgr that configures everything for you, and you can download it here: https://2pintsoftware.com/download/branchcache-tuner-ci-configmgr/

1. Import the configuration item into ConfigMgr, create a configuration baseline with it and deploy it to a collection where you have your clients.

Step 4 – Make sure your ConfigMgr packages and application are enabled for BranchCache

Once you have configured the server and client side of things, you may need to configure your packages to have BranchCache enabled.

Starting with ConfigMgr 1802, all packages have the BranchCache flag set, but if you had packages created earlier than that, or have migrated packages, it might not be.

1. To verify and/or enable BranchCache for legacy packages, software update packages, and application model applications, you can use the following scripts that are being hosted on the 2Pint Software GitHub: https://github.com/2pintsoftware/BranchCache

Step 5 – Verifying that it works

Now it's time to verify it works. In my example, I deployed a few packages configured for BranchCache to a collection containing my clients.

Once you see clients start to download content, you can fire up good old performance monitor and add the following two counters from the BranchCache node:

• BITS: Bytes from cache
• BITS: Bytes from server

Note: If the BranchCache node doesn't show up even though the group policy has applied, simply reboot the machine and they will be there 🙂

You can also checkout the various BranchCache PowerShell commands. For example, Get-BCDataCache represents the BranchCache data cache.

After waiting for 24 hours, you can see the clients reporting their download history both in the ContentTransferManager.log, and by going to the Monitoring workspace and select the Distribution Status / Client Data Sources node.

Note #1: There is an unsupported / undocumented way to shorten the upload interval for lab and demo scenarios, but since the ConfigMgr team says it is Not ok to publish those details, I won't 🙂 But don't despair, there is hope….

Note #2: You can use the TriggerHappy.exe tool on https://2pintsoftware.com/download/trigger-happy/ to set the interval, again for lab and demo scenarios.

New York site

Below, you see the Client Data Sources for the New York site. This environment has both Peer Caching and BranchCache configured, but since the New York site has a local DP (same subnet), Peer Caching is never going to be used.

Chicago site

Below, you see the Client Data Sources for the Chicago site. Again, this environment has both Peer Caching and BranchCache configured, but since the Chicago site has a no local DP, you will see a mix of BranchCache and Peer Caching being used.

A little bit of SQL

You can also check the info in the database directly by querying the ClientDownloadHistorySources table:

Select * from ClientDownloadHistorySources

Or, why not use one of the ready-made views: vSMS_ClientDataSourcesContent.

ConfigMgr Reporting

There is also a ready-made ConfigMgr report for the client data sources, and you find the report in the Software Distribution – Content node under Reports in the Monitoring workspace.

Written by Johan Arwidmark