In a ConfigMgr environment, when planning on removing remote distribution and replace them with BranchCache, there are quite many things to consider. For example, not all networks are suitable for the default BranchCache settings, and some networks are downright being blocked for it. To make things worse, it’s often you, the ConfigMgr admin, that have to proof that the networking side is not OK for BranchCache.

VPN Networks

If you have a bunch of remote workers that are connecting from user-based VPN connections, using BranchCache in distributed mode (the supported ConfigMgr mode) is probably not your best option. There is simply not much sense in having one user in home 1, sharing data to another user in home 2. These two users are better of getting the content from a central resources, than from each other.

WiFi Networks

Wireless networks, WiFi, are usually quite good candidates for BranchCache, or peer to peer in general. But certainly not with the same speed as for your LAN-based clients (100 mbit or 1000 mbit). This means that identifying which networks that have wireless clients is critical when determining how fast the peer to peer traffic is allowed to flow. Another complicating factor is that some wireless networks are using central switch, which basically means that if client 1 in subnet 1, is trying to send data to client 2 in the same subnet, the traffic is routed through a central data center. Meaning the data has to go over the WAN link twice. Certainly not a good candidate for peer to peer.

LAN Networks

Normal wired-based networks rarely have any problems with BranchCache, but I did stumble across on customer where the security team effectively block ALL traffic in between clients on the same subnet. Needless to say, not a good candidate for any type of peer to peer.

Verifying BranchCache support

By now I have lost count on the number of times networking team are claiming that BranchCache is not blocked on a network level, especially wireless networks, just to find out it actually is blocked. So how can you verify if BranchCache is indeed supported on a given subnet? Well, I would really love if everybody was using StifleR for controlling BranchCache, because our client actually tests the network to see if BranchCache is enabled. However, not everyone is using our software, and just want to verify that BranchCache is working. For that, you can download our free BCMon.exe utility from this link: https://2pintsoftware.com/products/branchcache-monitor

To verify the BranchCache multicast discovery protocol, which BranchCache is using to locate friends with the content, is working, you simply locate two clients on that subnet (PC0001 and PC0002 in this example) and then run the following:

On PC0001 having IP address 192.168.1.101
BCMon.exe /probematch 192.168.1.101

On PC0002 having IP address 192.168.1.102
BCMon.exe /probev2 192.168.1.102

If you see replies in between the two clients, multicast discovery is indeed enabled.

Note #1: The reason for specifying the local IP address is because you may have multiple network cards, and this allows you to select which one to test on.

Note #2: Make sure to configure the local firewall to allow the BCMon.exe too.

 

What about automating this probe testing if you have hundreds, or thousands of subnets? Well, that’s for tomorrows post.

/ Johan