With Windows 7 out of support, protecting your WAN links, and reducing the network impact Windows 10 will have on your environment has never been more important. In this post I wanted to compare Peer Cache and BranchCache in ConfigMgr for a specific scenario to see how they compared to each other. The scenario: I wanted to deploy (bare-metal) a Windows 10 image to a bunch of machines (well 25 of them) in a remote office, with no local DP and find out which solution that was the best.
For this particular scenario BranchCache did the better job. From a core deployment speed, the two platforms where quite similar for most tests, but BranchCache used less WAN traffic, and the users working on the machines peering content were not interrupted.
But please continue to read all the details about the tests. Chances are you learn a bit about Peer Cache and BranchCache in the process 🙂
25 Deployments – Scenario Details
As you learned in the introduction, the scenario I wanted to compare the two P2P technologies for is quite simple: Deploying a Windows 10 image to 25 machines in the remote Chicago office.
The Chicago office does not have a local DP (purposely), and is connected via a 155 mbit link to New York where the remote DP is. The DP in New York also had PXE enabled. My network looks like this:
Windows 10 and more than 20 Connections
An interesting thing about various Windows 10 peer-to-peer platforms – Peer Cache, BranchCache, and Delivery Optimization – is that they are actually not limited to 20 simultaneous connections like for example file and print sharing have. At least not from a licensing point of view. From the section 2.3.d in the Windows 10 license terms: "You may allow any number of devices to access the software on the licensed device to synchronize data between devices."
Below is a link to the terms:
Note: Just to prove a point I tested to deploy the 25 machines with a single peer cache source in the boundary group, and most of the clients (24 out of 25) connected at the same time to the peer cache source (which was quite busy servicing those clients).
Benchmark Lab setup
For this Benchmark Lab I'm using a pretty Powerful Hyper-V host for most of the testing, using multiple networks separated with a virtual pfSense router. But I also added a bunch of regular Dell desktops to provide real-world peering data.
Hyper-V Host and Desktops
The Hyper-V host is a HP Z840 Workstation, 2 Sockets and 24 cores, 256 GB RAM, and 2 NVMe SSD's for the VMs. The Dell Desktops are Optiplex 7040 micro towers, i7, 32 GB RAM, and with NVMe SSD.
The Chicago network is throttled to 155 mbit, and all machines in Chicago, including the VMs, where limited to 1 gigabit traffic. The reason for the latter is that I didn't wanted a peer being able to deliver more than 1 gigabit total to any other machines. I mean there are VERY few organizations having 10 GB network adapters in their client computers 🙂
All Windows 10 VMs were given two virtual CPU's and 4 GB RAM. The VMs outbound traffic were throttled using native Hyper-V bandwidth management, and I used native Hyper-V Metering to measure the WAN traffic out from the DP in New York.
Peer Cache and BranchCache for OSD
Peer Cache supports OS Deployment by default, but to have BranchCache supporting OS Deployment, you need to add BranchCache to WinPE using the free OSD Toolkit from 2Pint Software. This kit also includes an Alternate Content Provider (ACP) for BITS, that works very well with BranchCache.
The PXE Server I used for the DP in New York was the iPXE Anyhwere solution from 2Pint Software. This solution can download boot images via HTTP/HTTPS, and also get the boot image from nearby BranchCache clients that happen to have the boot image in their cache. iPXE is quite much faster than any of the two native PXE providers that comes with ConfigMgr, and certainly more suitable to use over a WAN link. To learn more about iPXE Anywhere, check this link: https://2pintsoftware.com/products/ipxeanywhere/
Windows 10 v1903 Task Sequence
The Task Sequence I used was based on a native ConfigMgr task sequence template, and I deployed a Windows 10 v1903 image with a driver package for the Dell machines.
The driver package was downloaded and staged also when deploying the virtual machines to add extra data. The driver package was zipped prior to deployment to optimize it for Peer Cache and BranchCache. To learn more about how to speed up driver package downloads in ConfigMgr, read this post: Speed Up Driver Package Downloads for ConfigMgr OSD.
I added a few applications that was installed by the task sequence, like Office 365, Edge, and Adobe Reader. I also enabled software updates in the task sequence. All in all the total package size for the task sequence is about 7.5 GB plus whatever size the monthly cumulative update is (0.3 GB for this deployment).
Note: For best peer to peer efficiency I recommend archiving any really large applications, or any applications with lots and lots of small files, into either a ZIP file, or a WIM file, or whatever you prefer. WIM files has the benefits that they simply can be mounted by a script wrapper, and you don't need to extract content first.
The 8 Magical Benchmark Tests
Below follow a list of the 8 benchmarks I did in Chicago, and how they affected the WAN link as well as deployment time. Again, for each of the 8 tests, I deployed the Windows 10 image and a driver package to 25 new machines in the remote Chicago office. For each test round, the 25 machines were started up with about 10 seconds in between. Basically to simulate somewhat quick technician with a pair of brand new runner shoes 🙂
Test #1: No Peer Cache or BranchCache enabled
Obviously not recommended, at all, but I wanted to see how long time it took to deploy the 25 machines over the WAN link with no Peer Cache or BranchCache enabled. The result:
Total Deployment time: 3 hours and 48 minutes
Total traffic over the WAN: 203.76 GB
Included in the WAN traffic was 0.08 GB from Active Directory (domain join, GPO), and 0.58 GB from the ConfigMgr MP (ConfigMgr policies, client registration).
Test #2: Peer Cache with one Peer Cache Source
Peer Cache enabled, and one extra machine in Chicago already having the Windows 10 task sequence packages in its ConfigMgr cache. The result:
Total Deployment time: 1 hour and 21 minutes
Total traffic over the WAN: 19.12 GB
Included in the WAN traffic was 0.07 GB from Active Directory (domain join, GPO), and 0.56 GB from the ConfigMgr MP (ConfigMgr policies, client registration).
Note #1: A Peer Cache Source only starts to reject content requests when CPU hits 80 percent, and the disk queue length hits 10. Not to mentioning fully saturating its network card (1 Gbit/s). At this point the peer cache source computer is pretty much useless for anyone trying to use it. It took 10 seconds to just launch notepad.
Note #2: Since Peer Cache requires the entire content to be in its cache before starting to share, you are more or less forced to pre-cache the content to at the very least one device in each boundary group. See the following post for pre-caching content for Peer Cache: https://deploymentresearch.com/speed-up-driver-package-downloads-for-configmgr-osd/
Test #3: Peer Cache with two Peer Cache Sources
Peer Cache enabled, and two extra machines in Chicago already having the Windows 10 task sequence packages in their cache .
Total Deployment time: 1 hour and 24 minutes
Total traffic over the WAN: 19.5 GB
Included in the WAN traffic was 0.07 GB from Active Directory (domain join, GPO), and 0.56 GB from the ConfigMgr MP (ConfigMgr policies, client registration).
Note: In my lab, all peers still reached out to just one Peer Cache Source, even though two peer cache sources was available with the content in the boundary group. This is not supposed to happen, and the ConfigMgr team is investigating why it does not randomize in between the two sources.
Test #4: Peer Cache with three Peer Cache Sources
Peer Cache enabled, and three extra machines in Chicago already having the Windows 10 task sequence packages in their cache. Like when having two peer cache sources, all peers still reached out to just one Peer Cache Source, even though three was available with the content.
Total Deployment time: 1 hour and 22 minutes
Total traffic over the WAN: 19.72 GB
Included in the WAN traffic was 0.06 GB from Active Directory (domain join, GPO), and 0.56 GB from the ConfigMgr MP (ConfigMgr policies, client registration).
Tip: ConfigMgr only returns peer cache sources in the same boundary group as your client (unless the limit per subnet option is selected, then its per subnet). And, starting with ConfigMgr 1806, it only returns peer cache sources that have their fast-channel status set to online. Here is a quick SQL query you can run to find what content that are available, on which online peer cache sources, and on which subnet or boundary group:
SELECT S.Name0, BGBNI.IPAddress, BGBNI.IPSubnet, ContentID, SPCM.SiteNumber, SPCM.Version, SPCM.Flag, BG.GroupID as BoundaryGroupID, BG.Name as BoundaryGroupName FROM SuperPeerContentMap as SPCM INNER JOIN v_R_System as S ON S.ResourceID = SPCM.ResourceID INNER JOIN BGB_ResStatus as BGBRS ON BGBRS.ResourceID = SPCM.ResourceID INNER JOIN BGB_LiveData_Boundary as BGBLB ON BGBLB.ResourceID = SPCM.ResourceID INNER JOIN BoundaryGroup as BG ON BGBLB.BoundaryGroupID = BG.GroupID INNER JOIN BGB_NetworkInfo as BGBNI ON BGBNI.ResourceID = SPCM.ResourceID WHERE BGBRS.OnlineStatus = '1' AND BGBNI.IPAddress NOT LIKE '%:%' ORDER BY SPCM.ContentID
Test #5: Branch Cache Enabled, no Pre-caching
Since BranchCache is the only P2P technology I know of that can share content to other peers while in WinPE, I thought it was relevant to included a test with just BranchCache enabled, but no pre-caching done to any other clients in the Chicago office. The result:
Total Deployment time: 1 hour and 37 minutes
Total traffic over the WAN: 20.86 GB
Included in the WAN traffic was 0.07 GB from Active Directory (domain join, GPO), and 0.54 GB from the ConfigMgr MP (ConfigMgr policies, client registration).
Test #6: BranchCache with one Peer
BranchCache enabled, and one extra machine in Chicago already having the Windows 10 task sequence packages in its BranchCache cache.
Total Deployment time: 1 hour and 27 minutes
Total traffic over the WAN: 7.74 GB
Included in the WAN traffic was 0.08 GB from Active Directory (domain join, GPO), and 0.57 GB from the ConfigMgr MP (ConfigMgr policies, client registration).
Note: An interesting observation was that the extra machine in Chicago peered about 140 GB of the content. The remaining 60 GB GB was peered in between the machines while being deployed.
Test #7: BranchCache with two Peers
BranchCache enabled, and two extra machines in Chicago already having the Windows 10 task sequence packages in their BranchCache cache.
Total Deployment time: 1 hour and 25 minutes
Total traffic over the WAN: 6.52 GB
Included in the WAN traffic was 0.07 GB from Active Directory (domain join, GPO), and 0.58 GB from the ConfigMgr MP (ConfigMgr policies, client registration).
Test #8: BranchCache with three Peers
BranchCache enabled, and three extra machines in Chicago already having the Windows 10 task sequence packages in their BranchCache cache.
Total Deployment time: 1 hour and 23 minutes
Total traffic over the WAN: 6.5 GB
Included in the WAN traffic was 0.07 GB from Active Directory (domain join, GPO), and 0.53 GB from the ConfigMgr MP (ConfigMgr policies, client registration).
Interresting article. We have just recently implemeted BranchCache in OSD using the deployment toolkit and it works great.
Did you make any benchmark on OSD to all 25 Chicago machines simultaneously with BranchCache enabled? Ideally that should be more or less the same as installing only one with not local peers.
Yes, all tests were done deploying the 25 machines at the same time. But deploying one without local peer will still download over the 155 mbit WAN link, so a local peer will beat that.
are you recommending to deploy PeerCache to the whole OSD-collection? Is my assumption correct that if i have 2 clients currently running a Tasksequence, the second client will only start downloading content from the first client if it (the first) is finished running through the tasksequence? The client-policy enabling peer-cache will only be applied after finishing a tasksequence, right?
For Peer Cache I recommend just selecting a few machines in each location as peer cache sources, and deploy to them first.
Hi Johan, This is a really useful article and comes at the perfect time for me, I'm investigating peer cache for my environment and setting up our TS seeding content for about 45 models, every time I see one of your posts on BranchCache I'm asking myself is Peer cache the right solution. (Oh and zipping driver packages is on my list to implement 🙂 ) One issue I'm facing at the moment is specific packages never make it into the cache on a nominated source, I tried using other peer cache sources across win 7 & 10 but the… Read more »
If pre-caching, you need to make sure the task sequence deployment is configured to download all content prior to running the task sequence.
Hi Johan, Super Great article! I've got 1 question and 1 suggestion for an additional test if I may… Question: When you enabled BranchCache, did you do so on the DP and on the client? Or just 1 of them (if so which one)? Suggestion: Given that BranchCache is limited to 1 submit but Peer Cache can share data across subnets in the same Boundary Group, an interesting additional test would be to have 2 subnets in Chicago that are members of the same Boundary Group and test Peer Caching with 1 Peer Source on 1 subnets. Then 2 Peer… Read more »
BranchCache have to be enabled on the DP as well as on the clients. I have a guide on setting up BranchCache for ConfigMgr here: https://deploymentresearch.com/setup-branchcache-for-configmgr-current-branch/ For the other question, configuring all machines as peer cache sources is a terrible idea, since ConfigMgr always return the full list (up to 50) of sources for the boundary. We had customers accidentally turn on peer cache sources on every client, at that went pretty bad. The ConfigMgr team confirmed the randomization selection not happening is a bug, and are working on a fix. I can certainly test having one peer cache source… Read more »
1 more question if I may…
If turning on peer caching as a source on all machines is a bad idea (to which I agree 100%), how do you turn it one on 1 machine since you need to enable it at the client settings level and deploy it to a collection; Have that 1 device in that collection is how you would go about it or would you do it differently?
You create a Peer Cache Sources collection in which you include at least a few clients in every location. In my lab I have three main locations, Seattle, Chicago, and New York. I picked 1-3 clients from each of those locations, and added to my Peer Cache Sources collection. If you have many locations, you can do that selection via script, or dynamic query on the collection.
Any update on the Peer Source selection bug? I have a client who has this issue, and wondering if this was ever addressed. I am guessing it has something to do with the MP_GetSuperPeerContentLocations stored procedure ordering, but obviously don't want to be tweaking the database adhoc. Any updates or info on that issue would be appreciated.
Sorry, no updates that I've stumbled across. Using BranchCache is typically the better option.
I also see no bug fixes and with the 2211 version it still doesn't randomization. I tested it with 300 clients and 6 sources. Peer Cache was servicing 300 clients from 1 source and that didn't end well.
Where did you find the issue? Do you have a open issue URL from Microsoft?
The option with BranchCache looks nice but the links to the OSD Toolkit from 2Pint Software are dead.
I hope to hear from you.
I haven't seen any fixes for Peer Cache over-loading a source, and I don't have any active cases. None of our customers are currently using it. They are all using BranchCache instead of Peer Cache.
I have updated the link to the OSD Toolkit for BranchCache, thank you for letting me know.