Appendix A - Managing BranchCache Cache Versions
The following is an edited version of a blog post from the 2Pint Software Web Site. Please visit the Web Site for the latest advice and tips on managing this issue.
Managing BranchCache Cache Versions in a Windows 7/Windows 10 mixed environment or “When to downgrade BranchCache clients and how”
The other day I was asked to clarify when to use which of the two hashing versions in BranchCache, so thought I would write it all down in one place for future reference.
To give a bit of background. BranchCache comes in two version; V1 that came with Windows 7/Vista and V2 that came with Windows 8 and subsequently Windows 10. A V2 machine can operate as either V2 or V1. Which to use is a not-so-straight-forward policy decision for your organization. In addition to the client operating systems the OS version of the server handing out the BranchCache hashes also requires consideration. V2 hashing was only introduced in Server 2012. A Server 2008 R2 can only serve V1 hashes and a V2 client will be auto downgraded to V1 when it contacts a V1 server.
You can downgrade a client manually by setting the following group policy option:
Now to the crunchy question: If an organization has a mix of both Windows 7 and Windows 10 clients, which version should they use?
The answer is of course - It depends!
A V2 client can be downgraded to V1, which means it can then P2P with a Windows 7 V1 client just fine. All good there. The problem is that V2 is much, much more efficient than V1, so once you start having more and more V2 machines, it makes sense to start shifting to V2. But there are some technical considerations that come into play.
A V2 client can, at any time (even when its operating as native V2), respond to V1 requests for content as long as it has that content in its database.
A V2 client can inject files as V1 into a V2 database
2Pint’s StifleR product, has a feature that enables a V2 client to generate V1 content on the fly. In the scenario where a V2 client is downloading Office for instance it can, at the same time, cache that same content as V1.
Smart huh? Yes! But what does it really mean?
It means that for all apps and other cacheable content, the V2 clients can generate V1 content for older clients while taking advantage of the fact that the V2 delta content is much smaller than V1 and thus keep the bytes on the wire to a minimum.
Ok, but what if I don’t have StifleR? How can I deal with all of this? Well, you can still inject that data as V1 content into your V2 BC data cache and then you need to run our BranchCacheTool.exe with the correct command line switches, or use our Cache Injector script logic. So far so good.
We then have another issue to overcome, which is seen when building machines using our OSD Toolkit. If you are deploying new Windows 7 clients, using a WinPE image created from Windows 10 (as you do) this defaults to BranchCache V2. When that machine reboots from WinPE the Windows 7 V1 machine cannot recognize the V2 cache content. BranchCache can only upgrade, never downgrade, which means that all that cache data is invalidated and purged.
The OSD Toolkit allows for the BranchCache version to be set using BCEnabler.exe with conditions/and/or variables on the command line:
In the above example, the 2.0 command line option tells the BCEnabler.exe binary to configure BranchCache to use Version 2.0. If it’s changed to 1.0 the tool will downgrade the client to V1 which is then compatible with Windows 7 peers.
So, why would we ever use V2 hashes when deploying Windows 7? Well typically the answer is, we don’t. But since V2 is so much more efficient than V1, there are benefits of using it when syncing large files, like .wim files. For this reason staying on Windows 10 V2 hashing can make sense, as all the other Windows 10 clients around can be used as source, using V2 hashing, grabbing device drivers etc. But if the Windows 7 build has a lot of content that is unique to the Windows 7 stage, that content should never be on Windows 10 boxes, and will have to be pulled down over the wire again. Problem!
So what’s the best compromise? Typically, if you are deploying new Windows 7 machines (Why????) you should set the version in the OSD Toolkit option to use V1, getting content from the other V1 clients, and possibly V2 that have V1 data injected on them. All great. Then switch to V2 the day when you stop deploying Windows 7 and never look back. Done!
Yes but… remember what I said about that the BranchCache data can only be upgraded otherwise it is purged. Well, it actually applies to the database version, not the content inside it. So, when the Win10 DB is moved to Windows 7, it’s purged right into space… all data gone! But… how do we solve that? Well, the workaround is to have a step at the end of the sequence to dump all of the content from the Packages\ folder from the _SMSTS folder right back into the cache, just before exiting the sequence. More on that in another upcoming blog post.
Problem solved, BC forever!
