Make Windows images smaller, easily

Back in March, I posted about the actual size of Windows 10 images over time, which resulted in the table below.

Windows 10 release	WIM size
Windows 10 Enterprise 1511	3.75GB
Windows 10 Enterprise 1607	4.20GB
Windows 10 Enterprise 1703	4.15GB
Windows 10 1709 multi-edition	3.71GB
Windows 10 1803 business editions (VL)	4.17GB
Windows 10 1809 business editions (VL)	4.23GB
Windows 10 1903 business editions (VL)	4.05GB
Windows 10 1909 business editions (VL)	4.28GB
Windows 10 2004 business editions (VL)	4.10GB
Windows 10 20H2 business editions (VL)	4.67GB

And then in April, I posted about going through additional attempts to reduce the overall size of Windows 10 images, without much success.

But that doesn’t mean there aren’t other ways to reduce the size. Let’s look at a specific example, working with Windows 10 Enterprise from the Windows 10 21H1 business editions ISO. The install.wim file on that media start off pretty big:

But we can shrink it by extracting only the Enterprise image like so:

That saves a few hundred megabytes. An improvement, but still not great (e.g. it still doesn’t fit on a FAT32 USB key). So maybe it can be compressed better. First, let’s look at how it’s compressed, which sadly is most easily done using the (very) old IMAGEX.EXE utility, which is still included in the ADK:

OK, so it’s using LZX compression with a 32K chunk size. But how does that map to the available compression types of “fast”, “max” and “none”? If you go back to the Microsoft white paper that describes the WIM file format (which yes, is still published as an RTF file), it talks about these:

• LZX = maximum compression
• XPRESS = fast compression
• none = no compression at all

So based on that, if we export that image but specify a different compression type, it should take longer (because it has to decompress and recompress the entire content), but the resulting size should be different:

So this confirms the above: Exporting as “max” gets the exact same file size, “fast” gets a little bigger, and “none” is huge. (The fastest export was “max” too, making it obvious that it wasn’t recompressing the content in that case.)

So we’ve achieved nothing from this exercise, so why do it? Well, there’s one more compression type listed in the DISM documentation called “recovery”. So what happens if we try that?

Now we’re talking. The “recovery” WIM is reduced by over a gigabyte, down to 3.4GB. So how is that possible? Compression algorithms can certainly squeeze out some minor percentage improvements, but that’s not minor. So how did it do that? Let’s inspect it a little more:

OK, so this is using a different compression algorithm, LZMS. Some of you might remember this compression algorithm that appeared around the time of Windows 8.1, and is now used in the WIM files that are published on Windows Update with a different extension, .ESD. So, exporting with “recovery” creates an unencrypted ESD file, which is still a WIM file. There’s one other limitation with these files: they can’t be mounted. So why not? It’s because they are compressed using what is, at least informally, called “solid compression.” With solid compression, instead of compressing each file individually (which is what enables WIM files to be mounted and modified — just add a new file to the end and invalidate the file in the middle) they are all streamed together and compressed as if they were one big file.

If you ever looked at how compression algorithms work, or even observed what happens when you add a whole bunch of small files to a zip file, you would see that the compression ratios aren’t the greatest. And you should recognize that Windows installs aren’t the best case for compression algorithms because they are made up of so many small files. If you merge them all together as one big “blob” of a file, they compress much better. But in that situation, the only way to get to individual files is to start decompressing from the beginning until you find it — perfectly fine when applying the entire image, but really bad when you just want to tweak “one little thing” (e.g. mounting, modifying, committing).

Alright, so you can export your own file. But can you make your favorite deployment tool use them? It depends on what that tool tries to do with the images. If they just try to get image metadata out of the file, it will work fine. But if they try to mount or extract a file from the WIM, it will fail miserably. So results might be unpredictable. But let’s try a couple of simple cases just to see. First, does DISM handle applying one of these “solid” WIMs (ESDs) itself? The easiest way is to try it.

So DISM works just fine. Let’s try to make things a little more interesting and try it with MDT. The first step would be to import the new WIM:

It failed very quickly because it’s trying to extract the registry file to look at what languages are included in the OS, but that won’t work. So we can’t import the recovery/ESD WIM directly. But we can fool it. Let’s first import the original 21H1 WIM file:

And then let’s go behind MDT’s back and swap that file out for the solid (ESD/recovery) file.

Since we’ve already proven that DISM can apply the WIM, and we know that MDT uses DISM, it’s safe to say that the rest of the process will work just fine.

If you want to try it with any other deployment/management tools, feel free. All use the same WIMGAPI.DLL to apply the image, so that part should work. There are just potential complications like we saw with MDT. In general, you:

• Can’t mount the WIM.
• Can’t extract files from the WIM.
• Can’t service the WIM (since that requires mounting).

So, it would be best to have a workflow that looks something like this:

• Capture a new image, or grab the latest install.wim from the Windows 10/11 ISO.
• Service it if necessary (but keep in mind that you won’t be able to get it as small as Microsoft did).
• Export it using /compress:recovery.
• Re-import/re-add it to your management tool.

For more reading on this particular topic, I highly recommend reading the documentation page for wimlib, an open source implementation of the WIM file format that runs on Windows and non-Windows platforms (Mac, Linux, etc.). It provides a good background on the topics I discussed above.