Pre-Caching Content for P2P in a ConfigMgr Environment

ConfigMgr natively supports three different platforms for peer-to-peer (P2P) of content. It's Peer Cache, BranchCache, and Delivery Optimization (DO). To cover P2P of all types of content ConfigMgr supports you need to pick at least two of these.

You always have to pick DO, because it's the only platform that can P2P native Windows 10 apps (and some other data types), and most customers I have worked with are picking BranchCache as the second. It's usually a bit more efficient than Peer Cache. But, that being said, I have also been working with a customers using all three, and even customers using just DO and Peer Cache. It's one of those it depends…

TL;DR

In this article you learn about ConfigMgr scenarios were pre-caching content is useful, and how to do it for the following P2P technologies:

• Peer Cache
• BranchCache
• Delivery Optimization (DO)

As usual, if you have any feedback, or some tips to share, please use the comments below 🙂

Do you really need to Pre-Cache?

Pre-Caching is simply the concept of downloading content in advance to clients in remote office that has no local DP. But, do you technically need it? The answer is no… If a client in a remote office needs a package of some sorts, and no other machine in that office has it already, it's simply going to download it over the WAN link, and store it in its own cache.

But what if you already know that in the upcoming week(s), there is going to be deployments of some large applications, or Windows 10 images? Well, for this scenario, it makes sense to make sure at least one client in each location have those packages in their cache prior to start the mass deployment.

Pre-Caching also makes sense for environment that have many available deployments. Allowing users to select to install whatever applications, upgrades etc. they need from software center, or even from the Microsoft Store. If the application is not available locally, and you have a heavily used WAN link, it can literally take hours to get that application installed. Not the best experience for the end user. However, if one or more machines in that office already have it in their cache, it goes pretty quick.

Pre-Caching for Peer Cache

When using Peer Cache for P2P, pre-caching content is usually done with a task sequence that does nothing than download the content. No installation or anything, just download. When deploying the task sequence, make sure to set the deployment settings to "Download all content locally before starting task sequence".

Note: The "Download all content locally before starting task sequence" is not required if you only pre-cache legacy packages, because the download package content action have options for where to download the packages. But the setting is required for pre-caching application model content without actually installing the apps.

For the task sequence itself, just add one or more download package content steps for your packages, and one or more Install Application steps for your applications. For both of the steps, since you are just downloading the content, make sure to set a condition that is never true. So that the task sequence don't install the apps. In my example just set a made-up variable, NeverTrue to True as condition.

Note: Don't forget to allow your applications model apps to be installed by a task sequence by selecting the "Allow this application to be installed from the Install Application task sequence action without being deployed" check box, or you'll find the task sequence fails before it even starts, and the execmgr.log will show something like this:

Could not find the policy in WMI for Application ScopeId_A626CF84-32CC-49A1-957A-774D47B5F3DE/Application_c0e9929e-0b43-4c0b-9e8a-6ebeffacc49e
Could not find the policy in WMI for Application ScopeId_A626CF84-32CC-49A1-957A-774D47B5F3DE/Application_dfcf0bd5-8bcc-4d3f-9151-eb49259937b3
Could not find the policy in WMI for Application ScopeId_A626CF84-32CC-49A1-957A-774D47B5F3DE/Application_e6b22493-8e3f-4d07-8054-2b2861e59a9f

Below you find some screenshot of the task sequence I was using for this guide:

Pre-Caching for BranchCache

As with Peer Cache, when using BranchCache for P2P, pre-caching content can also be done with a task sequence that does nothing than download the content. Meaning the preceding task sequence works great also for BranchCache.

But since BranchCache has it's own cache, there are other options available too. For example running a PowerShell script that just injects the packages into the BranchCache cache. With some clever scripting you can even completely bypass the ConfigMgr cache, and just inject it to the BranchCache cache directly. When using BranchCache, the ConfigMgr client cache more turns into temporary storage than anything else. Here are some resources:

Script to pre-cache specific packages for BranchCache, via the ConfigMgr cache (from Gary Blok)
https://garytown.com/bits-download-from-http-dp

Script to pre-cache any package for BranchCache, with or without going via the ConfigMgr Cache (from 2Pint Software).
https://github.com/2pintsoftware/BranchCache/blob/master/CacheInjection/InjectBCData.ps1

Pre-Caching for Delivery Optimization (DO)

Pre-Caching for Delivery Optimization is a bit trickier, and what I found works quite well has been simply bump up the time to live value for the DO cache, and simply have one or two machines always running Windows 10 in every location. Windows 10 will download updates every other day, and put them in the DO cache.

Note #1: Unlike Peer Cache, and BranchCache. Just because there is content in the DO cache, it doesn't mean it will make them available for other peers. Only files that have been pinned by DO for caching will be available for peers, and that is far from every file.

Note #2: Starting with Windows 10 v1903 you can pin files on your own via PowerShell, but that feature has turned out to be quite buggy. So better leave it be for now.

Other techniques available for pre-cache DO content is to force Windows 10 to look for updates every now and then, by scheduling a PowerShell script (still evaluating how effective this one really is):

$NameSpace = "Root\cimv2\mdm\dmmap"
$ClassName = "MDM_EnterpriseModernAppManagement_AppManagement01"
$wmiObj = Get-CimInstance -Namespace $NameSpace -ClassName $ClassName 
$wmiObj | Invoke-CimMethod -MethodName UpdateScanMethod