Some third party companies spend a lot of time badmouthing Microsoft’s peer-to-peer technologies and highlight their own. I wonder what would be in their interest to do so? Hmmm…

Anyhow, the purpose of this blog post is to provide the reader with a more correct review of the performance and capabilities of the Microsoft BranchCache™ than what some of Microsoft’s (ours?) competitors offer.

We typicaly dont like putting things into tables, cause often the answer is, “it depends”!

This table is not a full feature set of BranchCache, it only answers a few questions that some other vendor currently uses as their selling argument, in a more accurate way than a third party put it. We won’t even link to it, or bad mouth their tech, but we can’t just let them slap on Microsoft, someone has to defend them. 2Pint Software to the rescue!

Capability BranchCache with 2Pint Software BranchCache Stand alone
Advanced WAN bandwidth management Yes Yes, with LEDBAT++
Advanced OSD Support Yes Yes (1)
Peers can copy from others in remote IPSubnets Yes No
Election to identify best download host Yes Somewhat (2)
Store User State Migration data TBC (3) No
Broadcast for content on local IPSubnet Yes Yes
Will always select a Peer over a DP Yes Yes
Centralised real time reporting in ConfigMgr Yes No
Workstation able to service PXE requests Yes No
Does not require ConfigMgr Boundary Groups Yes Yes
Content fully cached on all peers Yes (4) Yes (5)
Scheduled Deployments does not cause multiple d/ls Yes Somewhat (6)
Supports delta downloads Yes Yes
Supports Office 365 update downloads Yes Yes
Does not duplicate cached content Yes (7) Yes

 

[1] With free addon from 2Pint Software

[2] As BranchCache has an answering algorithm on time, machines that are less powerful will be more likely to respond to others. But as BranchCache shares on a block level, even some less powerful machines can help by providing some data back, it’s like an “all together now” kinda effort!

[3] Based on customer feedback less people are wanting to do USMT style transfers between machines and let other technologies take care of this that can also be used in case of complete loss of an asset. That said, we have some far developed version of this that we might release if people should actually want it.

[4] If disk space allows for it, but we also do some other things to make this better

[5] If disk space allows for it

[6] This is a complicated question, and depends on several factors. As ConfigMgr randomizes the files in a package, typically even a large number of clients starting at the same time, data is not transferred twice as clients work on different files. But with a single file, all will start at the same time and it might take time to correct itself.

[7] So BranchCache stores its cached data in a deduplicated way (unlike third party competitors) and the CCM cache should only be used more as an “execution” area, but can of course also be used for speedy access. Makes no sense to have the data in both the BranchCache cache as well as the CCM cache.