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

Nomad, WinPE and Assumed Link Speed

Lately, we have been ramping up our OSD in one of our test environments. One of the servers that hosts some of our test VMs sits behind a pretty solid firewall with only the required ports open for Configuration Manager traffic. OSD was rocking and rolling along and then we started to ‘Nomadize’ the Task Sequence. First test and the TS fell over on the first step that attempted to get content (which previously worked).

This one had me scratching my head as I pretty much know Nomad inside and out. It uses the same ports as Configuration Manager when getting content from a Distribution Point. I have seen where proxies have been configured (even for system), but this usually doesn’t break. It just makes it slower than it needs to be since the proxy slows things down. After combing the log, one line in particular caught my eye:

LinkSpeed {url} cannot be calculated (try using AssumedLinkSpeed setting)

I turns out Ping (ICMP) was blocked on the firewall and Nomad was not able to calculate an initial link speed value. On the full client, there is a setting in the registry called AssumedLinkSpeed (referenced in the log). It will use this value instead when it cannot initially reach the DP via ICMP. For this task sequence, we were in WinPE since it was a bare metal build. There is a step in the task sequence actions called Install and Configure Nomad in Windows PE. This step enables Nomad to work in WinPE. As I opened the registry in WinPE, I noticed that AssumedLinkSpeed was missing (and hence the reason for the failure). To correct this, I created a Run Command Line step with the following command directly after each of the Install and Configure Nomad in Windows PE steps:

Step Name: Set Nomad Assumed Link Speed FIX
Command: reg add HKLM\Software\1E\NomadBranch /v AssumedLinkSpeed /t REG_DWORD /d 100 /f

After adding this and rerunning the task sequence is was off and running downloading content. I have submitted a case with the vendor and hopefully it will get fixed in an upcoming hotfix.

Originally posted on