Using BranchCache with the MEMCM Task Sequence HTTP downloader!!

Did you know BranchCache can be used with ANY http download that goes through the winhttp.dll or wininet.dll (i.e most stuff on Windows)? This includes downloads made by the MEMCM Task Sequence engine, without using an ACP. Read more to find out how this works!

Our friends over at a 'large financial institution' have been dabbling; trying to figure out how to deal with BranchCache in Task Sequences where there might be reasons for not using our BITSACP (which redirects the downloads of the TS to BITS). Lost already? Well you are not the only one...read on!

So, to take a step backwards, the Task Sequence can be set to either:

• Download all content before starting the TS - All downloads are done via BITS, which will then use BranchCache, all good. In the case of the Task Sequence running on its own
• Download on demand - the Task Sequence engine does pure HTTP calls to download the files from the DP dynamically. What about BranchCache here? Well, it will use BranchCache on Windows Enterprise SKU's, but not on Pro.

Ok, so we are on Enterprise, so how can I troubleshoot/verify this? Well, first of you need an Enterprise machine or two and BranchCache enabled and up and running! After that, lets head over to Perfmon and view the BranchCache perf stats.

Once the BranchCache counters are loaded, check the button (the little one looking like a chart) to change to Report mode, and have a look at the numbers. As you see above, the BranchCache client has reported data for both BITS (in red) as well as HTTP (in blue, separated per WINHTTP and WININET).  In this case above, you can see my machine has pulled down a whopping ~17GB from BranchCache when using WINHTTP. Most modern apps (non .Net apps) uses WINHTTP and the ones designed for UI user driven apps uses WININET. The reason why old Edge uses BranchCache is because it goes through WININET meanwhile the new Chromium based Edge does not. So now you know that too!. But as this is all about testing & verifying, we need to reset the counters to start fresh, so lets do that by using some PowerShell.

We run the PowerShell command "Reset-BC -ResetPerfCountersOnly - Force" here:

As we do that, the perfcounters in Perfmon are updated:

But what the deuce, there is one that is stuck, showing data still?!?!?! AAARGH its all broken. No, it's just the number of Cached segments that are in the database. So since we were to start fresh, lets see what happens if we clear the cache too!!!

Back to PowerShell and the favourite command "Clear-BCCache -Force" which gives no output:

But voila, we can now start fresh:

Ok! Lets go, so in order to test this, I got a Task Sequence that is set to RUN and download on demand:

And a step in that Task Sequence that downloads content the good ol' way, no BITSACP in play here (the notepad step is just to pause it to have a chance to pause it for screenshots):

Let's hit this thing in Software Center:

Then the download starts:

As the download happens, you can actually see the stats updating, in real time (it's not real atomic real time, more like lazy updating, so don't panic).

Look at the actual final picture below , it shows a good "243 233 995,000" in the "WINHTTP: Bytes from server" and "19 750 987,000" in the WINHTTP: Bytes from cache counter. So basically a 19MB of data from Peers, this really SUCKS right?!? Well, what if I told you there was NO OTHER PEER on this network? So basically, BranchCache lowered the number of bytes from the server, by looking at it's own dedupe. Read more on how that works here: https://2pintsoftware.com/news/details/picking-the-right-compression-algorithm-for-branchcache---take-two

Ok, so then maybe this thing doesn't suck so much after all? Well lets take a look to see how much we got into our own cache now, the PowerShell "Get-BCDataCache" command will show us the CurrentActiveCacheSize value:

As we see, we have the whole thing in the BranchCache, so lets reset those counters and retry, if you cant remember how to reset the counters or find out where to do that, I would suggest an alternative career or lowering the caffeine intake. So now we are reset:

Remember what the "Local Cache: Cache complete file segments" meant? Good! If not, start from the beginning! In this take we, don't wipe the BCDataCache.  ( BCDataCache = Local Cache).

Lets do the ConfigMgr dance again: RERUN!!!!

Reusing the picture here, mostly because this time, the DL is so fast it's just blasting past on the screen faster than I can get "Alt + Prt Screen" pressed. Whoah, what was that? Lets review a really lengthy video of what this looks like when looking at the perf counters:

https://2pintsoftware.com/using-branchcache-with-http-downloader/

That video is a whopping 2 seconds long, and is about 300% longer than the download takes, (getting why I couldn't press the keys? I am not that slow, the download is that fast...)

The final pic then looks something like this, very similar to the previous download, but the "Bytes from cache" and "Bytes from server" has pretty much swapped places:

So sure there are some nitpicky people out there wondering why 229332 bytes did NOT come from the BranchCache, it came from the server! And yes, that is true. Have a guess what data that is? If you break down the videos in this post frame by frame (both of them), you can see that they both start with downloading 229 332 bytes from the server before doing anything. Interesting... what might that be? Well, shall we see if it's the actual BranchCache Content Information (CI= Bunch of hashes)? Lets fire up BCMon and get the CI for the file we are downloading:

Yeah, you guessed right! If we download the CI, it's an exact match on the size. How cool is that, mystery solved. We are using bandwidth to save bandwidth.

So give yourself a pat on the back, we have used BranchCache with the default HTTP downloader, and learned how to troubleshooting this with some basic tools!

Getting data from other peers pretty much works the same, so if you are not getting any bytes from cache from other machines, you are most likely running into one of these:

1. You are using Pro, this is Enterprise only! Use the BITSACP to redirect to BITS.
2. CCMTOKEN paths used by ConfigMgr breaks BranchCache completely and should be avoided if using BranchCache. Read more here: (COMING SOON!!!)
3. Your existing BranchCache implementation is broken. Read up on troubleshooting: https://2pintsoftware.com/troubleshooting-branchcache-for-configmgr-environments/

Always be caching!

//Andreas

ps. If you like this article below, please let me know, it will push us to write more of these technical how to's!