How it Works: Peer Cache enables Peer-to-Peer (P2P) transfers of content between clients within the same Boundary Group. Peer Cache clients report their cache contents to the ConfigMgr site, so that other Peer systems can request that content. The content is located just like any other content lookup, except that ConfigMgr returns a list of Peer Cache Systems along with any Distribution Points that have the content. So think of your Peer Cache clients like a kind of ‘Mini-DP’. Simple!
Setting it Up:
Client Configuration: Peer Cache is enabled on Clients via Client Settings. You set the “Enable Configuration Manager client in full OS to share content” to “Yes”. in Client Settings. For testing purposes you can enable Peer Cache on as many systems as you like – but you may not wish to do this in production, for reasons that will become clear later. Once your clients receive that setting you are good to go.
Network Access Account: Network Access Account – Update – No special rights required for your NAA – MS docs have been updated to reflect this 🙂
Deployments: Unlike BranchCache – which has to enabled for each and every deployment, Peer Cache P2P content transfers are always attempted. If there are no Peer Cache sources, then the content lookup simply returns the regular DP locations.
Peer Cache In Action: Once enabled, your Peer Cache Source clients will spin up a Web Service locally which is used to act as a content server to other peers. This is known as the ‘SuperPeer’ service and you will see references to it in the CAS.Log. Confusingly enough, the URL that it uses to share content is http(s)://mycomputah/SCCM_BranchCache$ – but it really has nothing to do with BranchCache at all.
Clients that are looking for content perform a content lookup as usual, and the Management Point will return a list of content locations. Any SuperPeers that have the requested content will be returned along with the regular Distribution Points. The client will then pick a local peer (if available) and from there it performs a regular BITS download of the content. You can check the BITS Event log for this, and you will see which Peer was selected for the download.
Visibility: We all like a nice dashboard right? Well the Client Data Sources dashboard is the place to go to see if Peer Cache is doing it’s thing or not. It’s a really clean, succinct overview, and it shows Peer Cache, BranchCache and DP sources in an easy to read screen like this:
What’s also neat about this is that you can hover over some content for an expanded view of the data sources:
So that, in a nutshell is that. But obviously it can’t be that simple right? This is ConfigMgr folks!
Some Peer Cache food for thought and tips:
Testing: So how does it shape up? Well I only performed limited testing, but it shapes up fairly well for a ‘Pre-Release’ feature. I pushed out a few deployments of Packages and Applications to a bunch of clients on the same subnet and the Peer Cache clients were merrily grabbing content from each other once the content was fully cached. The best way to test this is to deploy to a few clients (or single machine) first, then bring others online and check to see if they are getting content from the initial downloaders.
Tip: The clients only report their data sources every 24 hours so be patient. I’m sure there’s a way to make this happen quicker in a lab and will update this article if I find it 🙂
However! Getting a bit braver – I decided to power off a machine that was acting as a SuperPeer, and it wasn’t pretty.. The DTS log looked like a bit of a bloodbath – which is to be expected if your content source goes offline – but the client seemed to get a bit confused at this point, trying to download from other peers that were also powered off etc. So not very dynamic in this release. The download did eventually failover to the correct peer that WAS powered on, and complete the transfer but it took around 10 minutes to get 10Mb.
Caching: Peer Cache clients can only share content once the whole package/app etc has been downloaded. So if you schedule a deployment with a start time in the future, Peer Cache isn’t going to work too well until you get the whole package/application etc cached. All the clients will try to grab the content at once, and they will all end up back at the DP. Careful planning and perhaps pre-caching content to a group of selected Peer Cache clients may be required.
Content Version: Peer Cache works on Content version, so if you update some content, Peer Cache may have to get the whole thing again plus changes? Need to test that one a bit!
Bandwidth Management: Both Peer Cache and BranchCache use BITS as the content transfer mechanism. You can throttle the amount of bandwidth used by BITS using the SCCM Client Settings. However, because BITS is used for Peer Transfers as well as WAN transfers, the throttling rate limit for the WAN will also be used for Peer transfers.
Boundaries: Boundary Groups and how they behave have changed in ConfigMgr 1610 – so I recommend that you read up on how they work and the terminology.
The wee gotcha to consider here is that the Current Boundary of a Peer Cache content source is determined by that client’s last hardware inventory submission. So a system that is moved to a new location that is in a different boundary group might still be considered a member the old group for the purpose of Peer Cache. Whaaat!? So you may end up transferring Gb of unwanted Data across the WAN? No biggie then..
Scalability: It will be interesting to see how this performs at scale. It will depend I think on the selection process – hopefully the content lookup process is clever enough to make sure that you don’t get single SuperPeers getting swamped by peer transfers (not sure if the 20 connection limit will apply to BITS transfers – more testing!)
BranchCache vs Peer Cache: So the number one question recently from our customers has been – ‘Peer Cache or BranchCache’? does Peer Cache replace BranchCache?, how do the two work together? Well I will attempt to clarify things a bit, but ultimately it’s up to you dear Peer-to-Peer ‘ers – you can use BranchCache OR Peer Cache OR both. Depends…
ConfigMgr will use BranchCache if it can’t Peer Cache. So in the scenario above where you have a deployment scheduled to be Available at midnight for instance, BranchCache will be used (if configured), and will start sharing content as soon as the first segment of data hits the first client. This will help the Peer Cache clients to get the content into the cache quicker, so that clients who come online later will use Peer Cache to get the content.
Remember too that BranchCache is subnet based whereas Peer Cache is only restricted by Boundary Group which means that it’s good for multi-VLAN sites where the content transfers can cross subnets.
Another scenario where Peer Cache will work well is in a mixed OS deployment. BranchCache has 2 versions, V1 = Windows 7 and V2 = Windows 8/10 and they do not talk to each other by default. Peer Cache is a bit of a tart and will talk P2P to anybody for a Pint and a packet of peanuts (providing it is a Windows ConfigMgr Client – no MAC or Linux yet).
So really I would say that BranchCache with Peer Cache make a good story. They kind of back each other up like Starsky And Hutch. And of course they are both technologies that you already own if you have Windows and ConfigMgr licenses so why not use them both?
Of course the best news of all is that BranchCache + Peer Cache + Our StifleR Bandwidth Management software can make your LAN/WAN and everything in between hum like a bird!