We (well Andreas really) found an epic bug in ConfigMgr (all versions up to CB as far as we know). It goes something like this:
You setup BranchCache on a CM Distribution Point using the checkbox labelled ‘Enable and Configure BranchCache for this Distribution Point’
BranchCache then gets installed, all well and good. You then go about the business of building up the BranchCache Hash store – clients requesting content etc , or you can do it yourself via PowerShell etc.. Remember – No Hash = No P2P folks! See our fabulous BranchCache Admin Guide for more details
So the bug is that if you so much a tweak a single setting on the DP – such as updating the description field, enabling HTTPS etc, it triggers a re-setting of the BranchCache Server Secret (even if it hasn’t changed) . You can see this in the distmgr.log – ‘Enabling and configuring BranchCache..’ it says helpfully. This nukes the Hash Cache and you are Hashless..
You can also look out for Event 325 in the Application Event Log.
Why is this bad? Well in a nutshell – if the hash is there, clients can get BranchCache-ing faster, and if it isn’t, sometimes the first client will do a non-BranchCache enabled download because the hash is not created yet. This happens more with large content such as OS WIMs etc. as it takes longer to generate those hashes. So you might see poor BranchCache performance periodically, for what seems like no particular reason. Meh..
And that’s not all..
This morning we confirmed that just distributing content can trigger this – simple performing an ‘Update Distribution Points’ on a Package causes the BranchCache reset on ALL target DPs. Which is really really bad… it’s like ‘Fan meets Poo’ bad..
Hopefully the good folks on the ConfigMgr Team will fix this soon, but in the meantime you can do the following to mitigate the effects of this bug.
1. Sign up for an InTune subscription instead (OK OK joking!)
2. Configure BranchCache on the Distribution Points manually, then it won’t be affected. If you do this – bear in mind that you MUST sync the ‘server secret’ across all DPs as ConfigMgr usually does this for you.
UPDATE: If your DP was already BranchCache enabled simply un-check the box in the UI – you are good to go. The server secret won’t change and ConfigMgr will not attempt to fiddle with it anymore.
If you deploy a NEW DP – then do it manually, and use the Export-BCsecretkey/Import-BCSecretkey cmdlets to get the key from an existing ConfigMgr DP and import it onto the new one.
3. Set up a trigger on Event 325 that kicks off some PowerShell to re-create the hashes using the Publish-BCWebContent cmdlet.
-Here’s the command – Publish-BCWebContent -path <DP Drive letter>:\SCCMContentLib -recurse -force -verbose that will recreate the Hash Cache
4, Use DeDupe (you should be doing that anyway) on your DPs and you should be OK as BranchCache uses the DeDupe chunk store not the Hash Cache. Note that this only applies to Win8.x or above clients (BranchCache V2) So if you have Win7 you still need a working Hash Cache..
This issue is potentially quite nasty, but mostly annoying, as it leads to ‘sudden unexplained performance degradation’ of BranchCache. So be aware, and if necessary – take action!