Here follows a few techniques you can use to troubleshoot and verify BranchCache functionality in a ConfigMgr environment.
But let's start with a quick setup checklist for BranchCache, and then dive deeper:
BranchCache Setup Checklist
- Make sure WS-Discovery is allowed on the network
- Make sure that Cisco Storm Control levels are set to reasonable values (if used)
- Make sure BranchCache has been enabled on the ConfigMgr DPs
- Make sure packages/deployments have been flagged for BranchCache
- Make sure BranchCache has been enabled/configured on the clients
- Make sure that BranchCache traffic is allowed in the firewall
- Make sure the firewall setting allows for unicast response to multicast or broadcast network traffic
- Make sure the clients have enough disk space
- Make sure the clients have enough ConfigMgr Cache size configured
- Make sure the clients have enough BranchCache Cache size configured
- Make sure BranchCache mode/policy is correct
- If testing in VMs, make sure to assign enough resources
- Use Microsoft Message Analyzer for network tracing
BranchCache Testing Tools
Verifying the Checklist Items
1. Make sure WS-Discovery is allowed on the network
WS-Discovery is usually enabled on VLANs used for wired machines, but I often find it being disabled on Wi-Fi networks. You can use our free BCMon.exe tool with /ProbeV2 and /ProbeMatch switches to verify that machines can speak BranchCache on the network.
2. Make sure that Cisco Storm Control levels are set to reasonable values (if used)
Cisco switches are sometimes configured with Storm Control on client ports, and BranchCache can generate quite many multicast packages on larger subnets, meaning the Storm Control may kick in and drop the port (depending on configuration). Our recommendation is to configure Storm Control for trap actions and set the levels high enough on the network so BranchCache is functional.
3. Make sure BranchCache has been enabled on the ConfigMgr DPs
When enabling BranchCache on the DPs, make sure to do that from the ConfigMgr console, instead than via Server Manager. When enabled via ConfigMgr it takes care of synchronizing the server secret key among all the DPs. Also, when enabling BranchCache, move the publication cache to a data disk, and increase the size to at least 10 GB. Using our BCMon.exe tool and the /VerifyCI switch, you can quickly verify that the DP is creating the CI's for ConfigMgr packages. Sample syntax:
Using BCMon to verify the DP BranchCache configuration and its Publication Cache.
4. Make sure packages/deployments have been flagged for BranchCache
Starting with ConfigMgr 1802 all new packages and applications have BranchCache enabled by default, but if you are still using packages created/deployed earlier than that, they might not be enabled for BranchCache. Same could be if you are using a package creation tool, or script to create packages. Use these scripts to verify if you packages, applications, and software updates are configure for BranchCache: Verify BranchCache Flags on Packages, Software Updates, Applications and Deployments By default the scripts run in gather mode, but you can also enable and disable BranchCache for the packages.
Sample log from gathering info about packages in ConfigMgr.
5. Make sure BranchCache has been enabled/configured on the clients
When configuring BranchCache, I don't recommend using ConfigMgr client settings or group policies, because these are far too limited. Use this ConfigMgr CI instead to enable and configure BranchCache. You can use the netsh command, netsh branchcache show status all (or just netsh br sh st a) and PowerShell: Get-BCNetworkConfiguration | Select *
Using the Get-BCNetworkConfiguration cmdlet.
6. Make sure that BranchCache traffic is allowed in the firewall
While the ConfigMgr CI mentioned in the preceding step, admins may still have blocked BranchCache in central configuration in either the built-in firewall in Windows, or in a third-party firewall. Make sure to open the ports needed for BranchCache. 3702 UDP for discovery, and whatever port you configured as the listener and connect port in the ConfigMgr CI, also known as the BranchCache Tuner. That CI is using port 1337 TCP by default.
Note #1: Do Not disable the native "Network Discovery (WSD-In)" firewall rule in the Private profile. It's also used with BranchCache for domain joined computers. No harm in enabling for the Domain profile though.
Note #2: Do Not disable the native "Core Networking - Neighbor Discovery Solicitation (ICMPv6-In) firewall rule. The F-Secure antivirus/firewall products seem to disable this one, which is otherwise enabled by default in Windows.
Note #3: While most organizations allow the outbound BranchCache traffic by default, but if that's locked down, you need to open this for outbound traffic as well.
Don't disable this rule, enabled by default in Windows for a reason.
Don't disable this rule either.
7. Make sure the firewall setting allows for unicast response to multicast or broadcast network traffic
In the Windows firewall settings for the various profile, you need to allow for unicast response to multicast or broadcast network traffic. This setting is found on the properties on the firewall item itself, and not in the inbound or outbound rules section. To verify this, in your Group Policy, navigate to Computer Configuration / Policies / Windows Settings / Windows Firewall with Advanced Security. Right-click the Windows Firewall with Advanced Security item and select Properties (you can also click Windows Firewall Properties in the right pane). Then click the Customize button in the Settings area, and in the drop-down list for Allow unicast response, select Yes (default). Then repeat for the Private and Public profile. See below screenshots:
8. Make sure the clients have enough free disk space
Often overlooked, but configure your hardware inventory to report on free disk space, and check those reports on a weekly basis. If a client is running low on disk space, BranchCache will immediately purge the downloaded data, making it unavailable for other peers. The client typically needs to have as much free disk space available, as the remaining unused BranchCache size, plus a few GB to be on the safe side.
9. Make sure the clients have enough ConfigMgr Cache size configured
Make the ConfigMgr cache size at least 25 percent larger than the content you are planning to pre-cache.
10. Make sure the clients have enough BranchCache Cache size configured
When using BranchCache with ConfigMgr, the ConfigMgr cache becomes more of a temporary cache. In general you want to reserve more disk space for the BranchCache cache than the ConfigMgr cache.
11. Make sure BranchCache mode/policy is correct
It's quite rare, but we have seen scenarios where the BranchCache policy have been set to local mode. This will not work with ConfigMgr. Check for the presence of the policyrefreshinprogress value in the hklm/software/microsoft/windows nt/currentversion/PeerDist/Service registry key, and if set, delete it from the client(s).
Below you find a CMPivot query you can run to see the current settings in your environment:
Registry('hklm:/software/microsoft/windows nt/currentversion/PeerDist/Service') | where Property == ('policyrefreshinprogress')
12. If testing in VMs, make sure to assign enough resources
When testing in VMs, assign at least 2 vCPUs and 4 GB RAM. Also, if testing OSD, configure the VM to use static memory.
13. Use Microsoft Message Analyzer for network tracing
Microsoft Message Analyzer may have been discontinued, so I hope you save a copy, but its still very useful to trace BranchCache traffic due to its native parser sets for BranchCache.
For BranchCache I recommend to use the following parser filter: HTTP || PCCRC || PCCRD || PCCRR || PCCRTP || PCHC
Note: Don't forget to run Message Analyzer as Administrator, and for best result/performance I recommend running the trace on a physical computer (If using Hyper-V you need to enable promiscuous mode on the external virtual switch using PowerShell).
Parser filter for BranchCache
Sample trace from a BranchCache download
Scoping down the testing
To quickly determine where the problem is you can for example do the following:
1. Determine if ConfigMgr is to blame or nor by simply adding a few files to Inetpub\wwwroot, and download them via Start-BitsTransfer. If you can't these files to BranchCache, ConfigMgr never will, and you just ruled out ConfigMgr of the troubleshooting. Here is the syntax: Start-BitsTransfer -Source http://dp01.corp.viamonstra.com/winpe.zip -Destination C:\Demo\winpe.zip
Note: When testing, do clear out the ConfigMgr and BranchCache caches in between the tests. Here is a script that does that: Clear ConfigMgr and BranchCache caches
2. Temporarily disable the firewall. To quickly rule out firewall issues, disable the firewall temporarily and try again. Enabling logging for dropped packages can also be helpful
3. Deploy a few VMs in a workgroup, to rule out domain policies breaking BITS, BranchCache, or both.
4, If running a network trace to troubleshoot, use a bit smaller packages, 10-20 MB, or there will be a lot of data in the trace.
Happy Deployment / Johan Arwidmark