Archiving ConfigMgr package content using archivers like Zip, 7-Zip, or WIM, is especially popular for large applications, and for driver packages used for Windows 10 deployment and servicing. To summarize it nicely, if you want to get some deployment speed and P2P effectiveness during Windows 10 OSD, you absolutely must archive your packages.
For large applications, you usually don’t see too much of different BranchCache Data DeDuplication savings depending on compression algorithm, because their content is unique. This means, that for large applications, like Autodesk, or Adobe products, the WIM format is usually the best choice. Simply because it does not require you to extract the content locally, you can just have a wrapper script mount the WIM file, and run the setup.
But for driver packages, it’s a different story. Many of the driver packages are sharing similar files, and since BranchCache P2P works on a block level, any identical block in between the packages, means less download over the network, and disk space being used in the BranchCache cache on the client.
For this BranchCache blog post, we were verifying how effective various compression algorithms are from a network transfer and disk usage point of view. The compression platforms and algorithms tested were:
- Zip with Fastest compression level
- Zip with Optimal compression level
- 7-Zip with 7z format and Normal compression level
- 7-Zip with 7z format and Ultra compression level
- WIM format with Fast compression level
- WIM format with maximum compression level
- ZPAQ with Method 1 compression level
Lab Environment
For this test we were using a ConfigMgr 2006 primary site (CM01) with a dedicated distribution point (DP01), and we were testing pre-caching 20 driver packages from HP on machines in a branch office location. The purpose of pre-caching content, sometimes called seeding, is obviously that when you deploy machines in that location, the clients won’t have to download the content from a distribution point over the WAN link.
In our lab, each client had a 1 TB NVMe SSD. Both the ConfigMgr client and BranchCache caches were allowed to use 20 percent of the disk each, meaning that the cache disk space was not of concern for this test (which it normally is, hence the reason for this blog post). Between each test, the ConfigMgr cache, as well as the BranchCache cache, were completely wiped on the clients. Also, before each test was run, I used the BCMon.exe tool to verify that the publication cache hashes had been created.
The 20 driver packages we tested were Windows 10 1903/1909 driver packages for the below list of HP models. The uncompressed package size for these models was just a bit over 32 GB in total, with 25,600 files, averaging to about 1.61 GB uncompressed data and 1280 files per driver package.
- HP Elite Dragonfly Notebook PC
- HP EliteBook 1040 G3 Notebook PC
- HP EliteBook 745 G5 Notebook PC
- HP EliteBook 745 G6 Notebook PC
- HP EliteBook 850 G3 Notebook PC
- HP EliteBook 850 G6 Notebook PC
- HP EliteBook 850 G7 Notebook PC
- HP EliteBook 855 G7 Notebook PC
- HP EliteBook x360 1040 G7 Notebook PC
- HP EliteBook x360 830 G7 Notebook PC
- HP ProBook 445 G7 Notebook PC
- HP ProBook 450 G7 Notebook PC
- HP ProBook 450 G8 Notebook PC
- HP ProBook 640 G7 Notebook PC
- HP ProBook x360 440 G1 Notebook PC
- HP Z4 G4 Workstation
- HP Z8 G4 Workstation
- HP Z840 Workstation
- HP ZBook 15 G5 Mobile Workstation
- HP ZBook Fury 15 G7 Mobile Workstation
Test #1 – Precaching packages using Zip with Fastest compression level
When archiving the 20 driver packages using this algorithm, the total size on the DP was 18.5 GB. But thanks to BranchCache Data DeDuplication savings, precaching these on a client, only resulted in a 10.1 GB network transfer and a 10.1 GB disk usage on the client.
Test #2 – Precaching packages using Zip with Optimal compression level
When archiving the 20 driver packages using this algorithm, the total size on the DP was 17.8 GB. But thanks to BranchCache Data DeDuplication savings, precaching these on a client, only resulted in a 9.7 GB network transfer and a 9.7 GB disk usage on the client.
Test #3 – Precaching packages using 7-Zip with Normal compression level
When archiving the 20 driver packages using this algorithm, the total size on the DP was 11.3 GB. But thanks to the high compression, there were no BranchCache Data DeDuplication savings, in fact, quite the opposite, resulting in a 11.5 GB network transfer and 11.8 GB disk usage on the client.
Test #4 – Precaching packages using 7-Zip with Ultra compression level
When archiving the 20 driver packages using this algorithm, the total size on the DP was 10 GB exactly. But thanks to the high compression, there were no BranchCache Data DeDuplication savings, in fact, quite the opposite, resulting in 10.1 GB network transfer and 10.1 GB disk usage on the client.
Test #5 – Precaching packages using WIM with Fast compression level
When archiving the 20 driver packages using this algorithm, the total size on the DP was 16.6 GB. But thanks to BranchCache Data DeDuplication savings, precaching these on a client, only resulted in 8.7 GB network transfer and 8.9 GB disk usage on the client.
Test #6 – Precaching packages using WIM with Maximum compression level
When archiving the 20 driver packages using this algorithm, the total size on the DP was 15.6 GB. But thanks to BranchCache Data DeDuplication savings, precaching these on a client, only resulted in 8.3 GB network transfer and 8.5 GB disk usage on the client.
Test #7 – Precaching packages using ZPAQ with Method 1 compression level
When archiving the 20 driver packages using this algorithm, the total size on the DP was 12.2 GB. But thanks to BranchCache Data DeDuplication savings, precaching these on a client, only resulted in 8.8 GB network transfer and 8.8 GB disk usage on the client.
Summary
Long story short, the WIM format produced the best efficiency from a BranchCache point of view, and since WIM packages can be quickly mounted instead of being extracted. It’s a winner! That being said, Zip and ZPAQ did produce pretty good results as well.
Part Two is Here!
Some further reading: https://2pintsoftware.com/best-compression-format-for-branchcache-take-two/
Happy Deployment / Johan
The post Picking the Right Compression Algorithm for BranchCache appeared first on 2Pint Software.