Better together-BranchCache and Nomad…wait, not so fast…

A few months ago, I noticed that Nomad had become really slow almost to the point that I thought I had a serious problem with my home lab. It did not matter if it was a virtual machine or a physical machine. Downloading content from a distribution point using Nomad had become painfully slow (averaging 1 blk/s). However, downloading without using Nomad was completely normal. I could also copy files using SMB from the distribution point at normal speeds and also download using HTTP using the browser. By the way, this is a good troubleshooting step. Look in the CAS.log for the DP location for the package, it will look something like this:

Then copy and paste that URL in IE or Edge

Then try downloading a big file and see what kind of transfer speeds you are getting with what you expect:

Downloading a similar package using Nomad yielded the following painful 1 blk/s (typically it would be about 100x this value):

This system is on a gig network with a gig interface card but only using 584 Kbps?:

Looking a little closer at the Network Activity in the Resource Monitor I saw PeerDist running and remembered that I had enabled BranchCache in my lab to do some testing:

Sure enough, the BranchCache service was running:

After stopping (and disabling) the BranchCache service, there was a little hiccup in the Nomad log:

But shortly afterward, things were back to normal (getting about ~30 Mbps):

Still a bit conservative on the network but at least it was moving along again:

Nomad log back to normal getting around 100 blk/s:

In summary, I will definitely be letting 1E know about this issue. BranchCache is used for things other than ConfigMgr traffic in the Enterprise (i.e. SharePoint and other web applications). Also, BranchCache could even be used for ConfigMgr traffic that Nomad does not handle (like WSUS, Automatic Client Deployment, etc.), even for Nomad customers!

Originally posted on

6 thoughts on “Better together-BranchCache and Nomad…wait, not so fast…

  1. This only effects downloads from the DP, Nomad peer copy performance is unaffected. 1E plan on releasing a fix soon. In the meantime, the solution is to disable BC on your DP

    Simon Burbidge

      • Agreed. As I say, we’re currently creating a fix that can be applied to the Nomad agent to resolve it. Having said that, the vast majority of our customers will not be relying on branchcache on their DPs, but for the few that do, the fix will be provided. What’s happening, after the Nomad election, http headers invoking Branchcache are being added to the HTTP Get request made by Nomad to the DP. Branchcache then goes about broadcasting for the content on the subnet before downloading from the DP causing the delay. We can modify the header to ensure the download from the DP happens without delay.

        Simon Burbidge

  2. It’s also important to mention that in the current release of Nomad (6.3) with it’s Dynamic Block Size feature, the download delay with branchcache diminishes massively. Since the delay is caused per block request. 6.3 is able increase the block size up to 16MB – depending on bandwidth available of course.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.