First look at the Peer Cache feature in Configuration Manager 1604 technical preview

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

Boundary Groups
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.

After a while I checked the Client Data Sources dashboard to see how things were going. This is a new dashboard in the Client Status folder in the Monitoring workspace in the CM Console that gives an overall percentage of content downloaded from Peer Cache, BranchCache, DP and Cloud DP. As shown below, you can select a time period (1-4 weeks), a Boundary Group and a Package. This was somewhat confusing as it showed 100% of the content in my Remote Site was downloaded from Peer Cache, even though this 45MB package was the first bit of content delivered to the site and was clearly downloaded from the DP, as seen in the CAS and ContentTransferManager logs above.

Another thing to be aware of with the Package list in this dashboard is that Applications are listed by Content ID, not Application Name. I also found that if you delete a Package (which I did after completing this test), the download history data still remains but will be represented by the Package ID (as the name is no longer available).

I then initiated the download manually on another workstation (W71) on the same subnet (and therefore the same Boundary Group). As indicated in the CAS and ContentTransferManager logs below, this client also got the content from the DP. I was expecting it to be downloaded from the peer W81.

I took a look back at the Client Data Sources for this Package in my Remote Site and saw the following:

The package content in this case is 45.1 MB (47,333,544 bytes) and at this stage had been deployed to only two workstations, both of which (according to the evidence in the CAS/CTM logs) had downloaded from the DP. A bit more investigation into the underlying data here revealed that sure enough, the Content Download History data was recorded twice for each client (once for PeerCache and once for DP), as shown below. Note also that the Start Time does not accurately record when the client started the download (as shown in the logs above, this was on 5/9/16 around 3:30pm).

If you’re interested, I cobbled together the following query to get the above result set as the out-of-the-box views don’t give you machine-specific details.

select
bg.Name BoundaryGroup, s.Name0 Device, cdh.StartTime
, "DPType" = CASE cdhs.DistributionPointType
WHEN 4 THEN 'DP'
WHEN 3 THEN 'PeerCache'
WHEN 5 THEN 'BranchCache'
WHEN 1 THEN 'Cloud DP'
END
, cdhs.ContentID, cdhs.BytesDownloaded
from
v_R_System s
join ClientDownloadHistory cdh on s.ResourceID = cdh.ClientId
join ClientDownloadHistorySources cdhs on cdh.ID = cdhs.DownloadHistoryID
join ClientDownloadHistoryBoundaryGroups cdhbg on cdh.ID = cdhbg.DownloadHistoryID
join BoundaryGroup bg on cdhbg.BoundaryGroup = bg.GroupID
where cdhs.ContentID = 'NEW00009'
order by Device

I initiated the installation on the other two clients in my lab. In each case, they downloaded the content from the DP and there was no indication in the CAS or ContentTransferManager logs that the client was even attempting to find a local peer. I also deployed an Application, following the same process outlined above for the Package, and saw the same results – the clients all downloaded from the DP and appeared to make no attempt to find a local peer. I even went back and double-checked and confirmed the client versions (5.00.8385.1000), just in case they were still running the 1603 client, but they were all fine.

Conclusion

I was really keen to get this feature working so I could provide a fair comparison between Peer Cache, BranchCache and 1E Nomad, but while everything seems to be correctly configured and content has been fully cached by at least one client and this has been reported back to CM, my clients just keep going back to the DP to download the content. I’m obviously missing something, so do get in touch (davef@1e.com or @davef_1e) if you’ve managed to get this working in your lab and see what I’ve missed. This is of course Technical Preview code, so some issues are expected. Once I’m able to get this feature working, I’ll follow up with a revision of this blog and update the Peer-to-peer Content Distribution Options blog with a summary of the feature and how it compares with the other options available.