ConfigMgr Peer Cache and BranchCache – Better Together!

Just recently, here at 2Pint HQ – we’ve been noticing a big surge in interest in ConfigMgr Peer Cache, and the most common question that we get/see is – Should we use BranchCache or Peer Cache? As we’ve been testing the life out of both technologies for our StifleR product integration I though it might be useful to put together a de-facto comparison of the two technologies so that you can make up your own minds.

To start – here’s a summary of the two technologies and their use within Microsoft ConfigMgr:

BranchCache

BranchCache is a Windows OS component, and works independently of ConfigMgr, but integrates with it. In the context of this article we’ll only talk about how it works with ConfigMgr. That’s quite enough in itself 

BranchCache has it’s own cache, and operates at the ‘block level’. So BranchCache doesn’t know or care about ‘files’, ‘Packages’ etc, simply blocks of data. This means that in ‘Distributed Mode’ as used in ConfigMgr, it can store content across many machines, and can retrieve content from multiple clients simultaneously. So it’s a truly distributed caching solution. It also integrates with the Data DeDuplication feature of Windows Server (2012+) which can greatly reduce the data transferred. Discovery of content is via broadcast, so BranchCache OOB is restricted to sharing only on the same subnet. You can’t interrogate the BranchCache cache and ‘see what’s in there’, you can only request blocks of data – which makes it a bit of a ‘Black Box’, albeit one that ‘just works’ in the background. To implement BranchCache within ConfigMgr you simply enable the Windows BranchCache feature via the ConfigMgr UI 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 then enabled on a ‘per deployment’ basis, using a checkbox on each deployment type within the UI.

Good Points: Fast distribution of content, set and forget config, benefits from DeDuplication, can handle non-ConfigMgr content, Content update only results in changes transferred. Full API and PowerShell available for customizations.

Limitations: Difficult to visualize, Subnet based discovery, requires separate cache from CM Cache. No BranchCache in WinPE OOB *, Long term working with BranchCache may result in excessive alcohol consumption,  hair loss and ageing. *BranchCache Integrates with WinPE/OSD via our free BranchCache for OSD Toolkit

Peer Cache

Peer Cache is designed specifically for ConfigMgr, and deals with ConfigMgr content only. It can cache, and share any type of ConfigMgr content to other ConfigMgr clients within the same Boundary Group.  This means that Peer Cache client transfers are not restricted by subnet and can be transferred anywhere within that Group. To configure Peer Cache, involves a couple of checkboxes in the ‘Client Cache’ section of the Client Settings, and you can specify either HTTP or HTTPS for content transfers. Once a client has this setting enabled, it becomes a ‘Peer Cache Source’. Think of them as ‘Mini DPs’.

Content is downloaded by clients that have been designated Peer Cache sources, and once the download is complete (and it has to be the whole package/application etc), the ConfigMgr client reports back to the CM site that it has the content. When you enable Peer Cache on a client, and existing content that is already in the CCMCache is also reported back to the site DB.

Clients that request content during a deployment, perform a regular content lookup, and any Peer Cache sources that already have the content are returned in the list of content sources, along with regular Distribution Points, and/or Cloud Distribution Points. The requesting client then connects to the CCMCache folder on the Peer Cache source and copies the content via a regular BITS download job. Peer Cache sources are also available to a client during OS Deployment in WinPE.

Good Points: Inter-Subnet transfers, Reporting, single copy of content.

Limitations: ConfigMgr content only, slow to initially share content, Content version increase invalidates the whole package

Some Recommendations

Based on the above, and what we have learned from experiences in the field – we recommend that BranchCache is turned on everywhere (for all clients). This is due to the way that BranchCache works – it doesn’t care if machines are on or off and is fairly self-maintaining. We also recommend that Peer Cache is enabled on carefully selected clients – within their own collection so that custom client settings can be used to enable Peer Cache on them. The reason for this is that Peer Cache clients are ALWAYS returned by a content lookup, even if the client is powered off. So if a clients requests content from a machine that is turned off, it currently takes 7.5 minutes to failover to the next one (it retries 4 times). Imagine if you had enabled Peer Cache everywhere and then everyone went home and powered of their machines! It has happened  Try to ensure then, that your Peer Cache sources have enough disk space, and are powered on when available. You can use WoL for this.

So, still confused? Here are some real-life scenarios where both technologies may or may not work well.

Mass deployment – i.e Software Updates etc at a specific time.

In this scenario, where you configure a deployment to become ‘available after’ a specific time, all Peer Cache clients will attempt to get the content. Obviously the issue here is that the content cannot be shared until at least one client has the entire content in the cache and has reported that back to the site. This results in all clients going back to the DP to get the content which results in excessive data transfer, be that across the LAN or WAN.

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

User Applications – Made ‘Available’ as opposed to required.

In this scenario, Peer Cache fares much better, because it is more likely that a Peer Cache source will get a ‘head start’ and have cached the content in readiness for others to request it. BranchCache can still be a useful ‘backup’ however, if for instance a Peer Cache source is powered off. Then clients can ‘fall back’ to using BranchCache and still get the benefit of P2P.

Content Which is Updated Frequently

If a ConfigMgr Package/App etc 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 it’s 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.

In Summary.

I think by now that you should get the message that we are trying to get across here! Peer Cache is a great new addition to the ConfiMgr Armoury – and remember that it’s still in Pre-Release form so many improvements and features may yet be in the pipeline. BranchCache is the perfect tech to backup Peer Cache and fill the gaps, as it’s very much ‘Set and forget’ tech that will hum away in the background, so you can implement it and not worry too much. To ensure maximum P2P enable BranchCache on ALL deployments.

Peer Cache need to be handled with care – but implemented correctly, has certain advantages by being tightly integrated with ConfigMgr.

Bottom line? You own both these technologies so use them! They work really well together and we only see things getting even better in the future.

Of course, P2P is great but you need to integrate that with some awesome bandwidth management tech – which, hey presto, we happen to have in the form of StifleR, which is the only Content Distribution and Management System to work with BranchCache, Peer Cache, and Microsoft Delivery Optimization