BranchCache vs. Peer Cache

  • Article

Recently, many customers have reached out to me, asking always the same question: "Should we use BranchCache or Peer Cache?"

I decided to write this summary of both technologies and with the use in Configuration Manager to help understand and decided what technology is the best match for your case.

 

BranchCache

BranchCache is a bandwidth-optimization feature that has been available since the Windows Server 2008 R2 and Windows 7 operating systems. Each client has a cache and operates at the block level. For that reason Branch Cache doesn't care about Files and Packages, it simply replicates blocks of data.

BranchCache enabled clients act as an alternate source for content that devices on its own network request. The discovery of the content is only possible via broadcast, which means that Branch Cache only works on the same subnet.

Unfortunately there is no Management GUI for BranchCache, which would allow any management or prioritization of block transfers.  But, luckily it is very easy to configure and implement.

BranchCache has two operating modes: Distributed Cache mode and Hosted Cache mode. For detailed information about how Distributed Cache mode and Hosted Cache mode work, see BranchCache Overview but Configuration Manager only supports Distributed Cache mode.

To implement BranchCache in Configuration Manager you simply enable the Windows BranchCache feature via the Console for each Distribution Point, and then turn on BranchCache on the clients via a couple of checkboxes in the "Client Cache’"section of the Client Settings. BranchCache is enabled on a ‘per deployment’ basis, using a checkbox on each deployment.

Important Side Note:

Since Windows 10, version 1607, the Windows Update Agent uses Delivery Optimization by default, even when the updates are retrieved from WSUS. When using BranchCache with Windows 10, simply set the Delivery Optimization mode to Bypass to allow clients to use the Background Intelligent Transfer Service (BITS) protocol with BranchCache instead. For more information, see Configure Delivery Optimization for Windows 10

 

Good Points

  • Fast distribution of content
  • "set and forget" config
  • DeDuplication Benefits
  • can share Content (Blocks) as soon as the Block is in the Cache (no need to wait until the full Filesize was replicated)
  • can handle all content (non-SCCM)
  • only changes will be transferred (Block-level replication)
  • Full API and PowerShell available for customizations.
  • Allows sharing of Task Sequence Policies between clients (these policies are usually small. But some of these policies can get quite big and as they are also transferred to the clients it would be like distributing a big application)

Drawbacks

  • Difficult to visualize
  • only within Broadcast Domain possible
  • additional cache location (not using the SCCM Cache folder)

 

Peer Cache

Peer Cache is a built-in Configuration Manager solution that enables clients to share content with other clients directly from their local cache. It is available as a feature since the Configuration Manager Current Branch version 1710.

Peer Cache was specifically designed for Configuration Manager, therefore it only handles Configuration Manager content. The Content can be shared via the Boundary Groups to all managed Configuration Manager Clients. This means that Content Sharing is not restricted by the Broadcast Domain.

To configure Peer Cache, open up the Configuration Manager Client Settings and activate it in the "Client Cache" section. Once a client has this setting enabled, it becomes a ‘Peer Cache Source’ - which will be handled similar to a Distribution Point.

Peer Cache sources can only share content to other client, as soon as the whole Package / File is downloaded and cached. This process is similar to the Distribution Point. The Content is downloaded by designated Peer Cache sources, and once the download is complete (and it has to be the whole package/application etc), the Configuration Manager Client reports back to the CM Site that it has the content.

When promoting a Client to a Peer Cache Source, the existing content in the CCMCache folder is also reported back to the CM Site.

Client that request content during a deployment, perform a content lookup. This lookup will contain any Peer Cache source (which already have the content successfully cached) along with the regular Distribution Points. The requesting client then connects to the CCMCache folder on the Peer Cache source and download the content via a regular BITS download job.

Peer Cache sources are also available to a client during OS Deployment in WinPE.

The best practice is to choose only clients best suited as peer cache sources. Evaluate client suitability based on attributes such as chassis type, disk space, and network connectivity. For more information that can help you select the best clients to use for Peer Cache, see this blog by a Microsoft consultant.

Good Points

  • Boundary sharing
  • Reporting
  • All Content in CCMCache

Drawbacks

  • Configuration Manager content only
  • slow to initially share content
  • Content version increase invalidates the whole package

 

Comparison BranchCache vs. Peer Cache

BranchCache Peer Cache
Possibilities BranchCache works with any content that is accessed via HTTP or SMB. Other users of the content get the benefit of branch cache. Peer cache only works with SCCM content.
Sharing BranchCache clients can share content with each other only if they are in the same subnet. Peer cache clients can share content with each other even if they are not in the same subnet.
BranchCache works at a block/segment level. The unit of download is blocks, which is typically just a portion of a file. Blocks are identified by their hashes and not by their association to any file. This allows a client to share content even if it only has portions of it. This also makes it is difficult to know which client has which content. Peer cache works at SCCM package level. The unit of download is an SCCM package. An SCCM peer cache client can only start sharing content if it has completely downloaded the entire package. You can also tell which client has which content.
Cache BranchCache uses its own cache which is separate from the actual content. There is essentially two copies of the content on the client. Peer cache only has one copy of the content, all in the ccmcache.
WinPE BranchCache does not work with WinPE clients. Peer cache works with WinPE clients. WinPE clients can get content from peer cache clients in full OS.
Discovery BranchCache discovers content by broadcasting the hash of a block, and the clients that have the block will respond. This is why clients have to be on the same subnet for this method to work. Peer cache discovers content by asking the SCCM MP for the location of packages. WinPE clients also performs a broadcast on the subnet, in addition to the MP look-up.

 

Some Examples

Required deployment (... at a specific time)

Depending on the time between when the content was available and the deadline, the client peer cache might have attempted to pre-download the content. (depending on Maintenance Windows, etc)

Latest the content will be downloaded by the Peer Cache Computer when the deadline is reached. As Peer Cache Content can only be shared when the content is fully downloaded, Obviously this results in a massive fallback of all Client to the DP. To solve this the content needs to be pre-cached prior deployment start.

BranchCache in this scenario works a little better, as it can share content as soon as any client gets a block of data.

Available deployment 

Peer Cache might work much better in this scenario, as it might be able to have already downloaded the content prior an Client request it.

BranchCache can also be used (as Backup) in the case no Peer Cache clients are available. Then clients can ‘fall back’ to using BranchCache and still get the benefit of Peer to Peer.

Frequently updated Packages

If a Configuration Manager Content (Application, Packages) is updated, the version changes. This invalidates the content on all Peer Cache clients, that is , the new version is treated as new content so Peer Cache sources with the previous version will not be returned in the content lookup, until they have downloaded the new version into the cache in its entirety.

BranchCache clients will simply download the changes to the content at the block level. So again, BranchCache can be used to facilitate the efficient updating of content which can then be used by Peer Cache.

Verdict

To get the most out of the technologies, enable both Branch Cache and Peer Cache. Both Method work great together and both technologies can fill the gaps of the other one.

BranchCache is for all clients on and Peer Cache is enabled on carefully selected clients (within their own collection that custom client settings can be used to enable Peer Cache on them). Try to ensure then, that your Peer Cache sources have enough disk space, and are powered on when available.

Comments

  • Anonymous
    January 25, 2018
    BranchCache not Branch Cache please :)
    • Anonymous
      January 27, 2018
      Thanks for pointing that out. It‘s done
  • Anonymous
    January 25, 2018
    Nice Summary!
  • Anonymous
    January 26, 2018
    Great!
  • Anonymous
    February 01, 2018
    Added your article to my Windows 10 link reference. ;) http://aka.ms/w10linksGood job!
  • Anonymous
    March 14, 2018
    Very nice article - loved the structure/sections and the "Verdict" section at the end
  • Anonymous
    March 16, 2018
    Great summary. Thanks a lot. Do you have any resources to share about the PowerShell and APIs that can be used for the customisation? (You mention them in the Good Points of BranchCache)
  • Anonymous
    July 10, 2018
    Nicely written!
  • Anonymous
    November 18, 2018
    Hi, Thanks for the great summary! But, Branchcache uses multicast, not broadcast. ;)