Microsoft is significantly improving SMB compression in Windows 11, here is how

A couple of days ago, Microsoft rolled out an optional update for Windows 11 in the form of KB5016691 and a similar update for Windows Server 2022 through KB5016693 a bit earlier. Although the former will eventually make its way to consumers generally in next month's Patch Tuesday (September 13), the Cumulative Update contains a few new features that early adopters can get their hands on right now.

Both updates mention Server Message Block (SMB) compression improvements in their changelog but don't really go into the details. Fortunately, Microsoft's Ned Pyle has talked about all the enhancements that SMB compression is getting in a dedicated blog post.

For those unaware, SMB compression in client-server environments allows admins, users, and applications to request file compression as content is being transferred over the network. The benefit of this approach is obviously the reduced consumption of bandwidth but it comes at the cost of increased CPU usage as the hardware attempts to compress and decompress files as they are being transferred over the network. If that still doesn't make SMB compression and its use clear enough to you, try checking out the embedded video below:

Up until the arrival of KB5016691 and KB5016693, SMB compression behaved in a weird way, to say the least. Basically, it utilized a default algorithm which attempted compression only on the first 500MiB (Note: 1MB = 1000KB but 1MiB = 1024KB) of a file, any content smaller than this threshold would never be compressed, even if it was very "compressible".

And there was an additional caveat too. During its reading of the first 500MiB of a file, if the algorithm detected that less than 100MiB of the file could be compressed, it would not attempt to compress the rest of the file at all. Imagine there is a 10GiB file that is extremely compressible but only 80MiB of the first 500MiB can be compressed, the SMB compression algorithm would just give up compressing the file altogether and you'd end up sending pretty much the same 10GiB over the network. The only way to force-compress would be to override certain default registry settings, and editing those isn't really what you should do unless you know exactly what you are doing.

It's a very odd behavior and one that has likely impacted a lot of use-cases. However, the good news is that Microsoft is doing away with the restrictions in the algorithm completely. Essentially, SMB compression will now try its best to compress any and all files that you request compression for.

Obviously, that does not mean that SMB compression should be used in every use-case. Pyle has highlighted that some formats like JPG, ZIP, and DOCX are already compressed but the removal of these restrictions will certainly benefit other formats like VHDX, ISO, and DMP, among others.

Microsoft isn't just stopping here, though. It is introducing new PowerShell, Group Policy, and registry settings that make it easier to control the two behaviors. All those details and associated commands are mentioned in the blog here, if you're interested.