Since I wrote the Peer-to-peer Content Distribution Options blog in March, a few people have asked about the new Peer Cache feature that was introduced in Configuration Manager 1604 Technical Preview and how it compares to the other options, so I had a look at it in my lab. The Technical Preview documentation positions Peer Cache as “a built-in Configuration Manager solution for clients to share content with other clients directly from their local cache. For Peer Cache clients to share content, they must be members of the same boundary group. Peer Cache does not replace the use of other solutions like BranchCache but instead works side-by-side to give you more options to extend traditional content deployment solutions like distribution points.”
Peer Cache replaces (or perhaps more accurately, extends) the Windows PE Peer Cache feature introduced in Configuration Manager 1511. The Windows PE Peer Cache feature was designed to get around the limitation of BranchCache (not officially supported in Windows PE) and enabled Package content to be downloaded from a peer on the same subnet during Task Sequence execution. Peer Cache aims to extend this functionality to normal distribution of Package and Application content, with the additional benefit of being able to share across subnets within the same Boundary Group. This Technical Preview also adds a Client Data Sources view (Monitoring > Client Status > Client Data Sources) and a report (Monitoring > Reporting > Reports > Client Data Sources) in the Configuration Manager console, although as shown below I don’t trust the data these are providing at the moment.
After many hours trying to get this working, I have yet to see a client download content from a peer using Peer Cache 🙁 However, I’ve detailed my journey in this blog to show what’s involved and I’m really keen to hear back from anyone who has more success than me.
Configuring Peer Cache
Peer Cache uses Boundary Groups to determine which peers are ‘local’ and will only attempt to find a peer Content Source if it is in a Boundary Group configured with a Slow Connection to the DP. I believe it will also attempt to find a peer content source on the same subnet (through broadcast) but have not been able to confirm this in my testing. The diagram below shows my lab setup.
Enabling Peer Cache
To use Peer Cache, you need to configure one or more clients in each Boundary Group to enable them to share content with peers. This is enabled in the Client Cache Settings (in Client Settings) as shown below. (You will notice that Client Cache Settings replaces the Windows PE Peer Cache settings introduced in CM 1511 – you’ll find it at the bottom of the list – and now includes options to configure the client cache size too). While you can enable Peer Cache in the Default Settings, in practice you should use Custom Settings deployed to a Device Collection that contains the clients you want to use as Client Content Sources.
Once you’ve done this and updated the computer policy on your clients, you should see the following in the CAS.log on the clients. Note the URL through which the client cache is published so peers can obtain content over HTTP – I’m guessing the CM client establishes an HTTP server as there is no requirement for IIS to be installed.
You’ll also see the ContentTransferManager logs aggregating (and sending if necessary) client download history data every 5 minutes (whether or not Peer Cache has been enabled). I’m guessing this is associated with the back-end reporting that you’ll see later in this blog.
I also noticed the following errors recurring in the Policy Agent log on all clients. I suspect DownloadBytesStats relates to the content download history data being sent back to the site now to provide the Client Data Sources. Maybe this error is related to the reporting anomalies shown later in this blog.
You need to grant the Network Access account Full Control on the CCMCache folder on each of the clients where Peer Cache is enabled. I’m puzzled that the CAS log says “The network access account is not defined”, because it was…
Deploying Software using Peer Cache
Peer Cache will only work if the requested content has been fully cached on at least one peer-cache-enabled client in the Boundary Group. (If you deploy something to all clients at the same time, they will all download from the DP).
In my lab, I enabled Peer Cache on all workstations. I then created both a Program and an Application Deployment to all workstations, which I made Available rather than Required so I could manually manage the download to the first client. Don’t forget to select Download content from distribution point and run locally when the client is within a slow or unreliable network boundary. Note that on the Program Deployment settings, an additional Allow clients to share content with other clients on the same subnet checkbox has appeared. The first instance is the familiar Branch Cache option and is selected by default. I’m guessing the second instance (disabled by default) enables clients to use Peer Cache but I couldn’t find any reference to this in the Technical Preview documentation. I checked it anyway – it seemed the right thing to do 🙂
Interestingly the Application Deployment Type settings still only include one instance of this option.
Download to first client
I initiated the download manually on one of the workstations (W81) through Software Center. The CAS.log and ContentTransferManager.log confirmed that the content was obtained from the Distribution Point.