SMB compression behavior & settings changes

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

Heya folks, Ned here again. As you know from a previous post, we released an end-to-end SMB compression capability with Windows 11 and Windows Server 2022. You can learn all about it at SMB Compression | Microsoft Docs. 

There was an idiosyncrasy in the initial design that we changed with the release of Windows Server 2022 update KB5016693 (OS Build 20348.946) and Windows 11 update KB5016691. From now on, if you request compression over SMB, we will attempt to compress the file regardless of its size or seeming suitability for compression. It doesn't matter how you request compression - robocopy, share setting, registry values - we will try to compress the file.  

For those playing SMB Trivial Pursuit edition: previously, SMB compression used a default algorithm where it attempted to compress the first 524,288,000 bytes (500 MiB) of a file during transfer and track that at least 104,857,600 bytes (100 MiB) compressed within that 500-MiB range. If fewer than 100 MiB was compressible, SMB compression stopped trying to compress the rest of the file. If at least 100 MiB compressed, SMB compression attempted to compress the rest of the file. This means that very large files with compressible data - for instance, a multi-gigabyte virtual machine disk - are likely to compress but a relatively small file - even a very compressible one - would not compress. It meant you had to set registry overrides if you wanted files under 100MiB to compress, which of course didn't happen, that's way too esoteric for folks to know. Now we just assume if you try to compress, you want to compress.

This does mean that transferring some smaller, less-compressible files will now get some useless CPU time spent trying to compress them, but the solution is to just know your files. JPG, ZIP, DOCX, etc. formats that are already compressed see no advantage from SMB compression no matter their size. VHDX, ISO, DMP, and other large files with lots of whitespace will compress quite well.

This demo shows the ways you can use compression as an IT pro or have your users get compression without having to train them. It's only about 4 minutes and worth a watch. 

Furthermore, we now have a set of Group Policy, PowerShell and registry options to control the legacy behaviors and to let you avoid editing the registry by hand for configuring client compression. 

Group policy

\Computer Configuration\Administrative Templates\Network\Lanman Workstation

Disable SMB Compression

Use SMB Compression by Default

\Computer Configuration\Administrative Templates\Network\Lanman Server

Disable SMB Compression

Request traffic compression for all shares

These all write to the following location and will override the 'native' registry settings as usual with group policy:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation\parameters

PowerShell for SMB client

Set-SMBClientConfiguration [-EnableCompressibilitySampling <bool>] [-CompressibilitySamplingSize <uint64>] [-CompressibleThreshold <uint64>] [-DisableCompression <bool>] [-RequestCompression <bool>] 

-DisableCompression $true or $False - never compress even if server or application requested 
-RequestCompression $true or $false - always request compression even if server or application didn't specify it 

-EnableCompressibilitySampling $true or $false - control legacy sampling behavior 

-CompressibilitySamplingSize 1- 9,007,199,254,740,992 - size in bytes of range to sample in a file looking for compressibility

-CompressibleThreshold - 1- 9,007,199,254,740,992 - size in bytes of compressible data that must be found within that range

You shouldn't need to touch the sampling settings without a good reason. Maybe hit me up in the comments first if you're feeling the urge to touch those. :) A keen-eyed reader might notice that a range of 9,007,199,254,740,992 is not the Uint64 in the PowerShell. That's because the real limit in the code is 9PiB, not the 184,467,440,737,095,551,615 bytes of a UInt64 value we had to set in the Posh. If you've got individual files bigger than 9 petabytes, I would love to hear your story, regardless! 

These values are stored in the registry under: 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\LanmanWorkstation\parameters

PowerShell for SMB Server

 Set-SmbServerConfiguration [-DisableCompression <bool>] [-RequestCompression <bool>] 

-DisableCompression $true or $False - never compress even if client requested 
-RequestCompression $true or $false - always request compression even if client didn't specify it

These values are stored in the registry under: 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\LanmanServer\parameters

I'm updating SMB Compression | Microsoft Docs & PowerShell Help to cover all this too, don't worry. 

You should get huge benefits from SMB Compression in many day-to-day operations, it's a time saving, bandwidth saving, and - now- very easy to use feature. More improvements are coming, this isn't the end.

Until next time,

- Ned "Squishing" Pyle