Now that Windows 8.1 Update has been released, we want to talk about a new way that Windows 8.1 can be installed on Windows 8 logo-certified devices (since UEFI is a requirement) with smaller disks, e.g. devices with 16GB or 32GB SSDs or eMMC storage, while still ensuring that there is plenty of storage left for apps and data.
This new deployment option, called Windows Image Boot (or WIMBoot), takes a different approach than traditional Windows installations. Instead of extracting all the individual Windows files from an image (WIM) file, they remain compressed in the WIM. But from the user’s perspective, nothing looks any different: You still see a C: volume containing Windows, your apps, and all of your data.
This is supported with all SKUs of Windows 8.1, with the Windows 8.1 Update. (Remember, we’re not talking about a different version of Windows, just a different way of installing it.)
So how does this work? Effectively, you copy the WIM file into a separate “images” partition (just like you would for a recovery image), then use DISM to create pointer files from the standard C: operating system volume into the WIM file. These pointer files are completely transparent, and Windows knows how to boot the operating system (keeping all the files in the WIM) when configured in this setup. Behind the scenes, the disk looks something like this:
So let’s assume the WIM file (INSTALL.WIM) is around 3GB and you are using a 16GB SSD. In that configuration, you’ll still be left with over 12GB of free disk space (after subtracting out the size of the WIM and a little bit of additional “overhead”). And the same WIM file (which is read-only, never being changed in this process) can also be used as a recovery image, in case you want to reset the computer back to its original state.
How does that compare to a non-WIMBoot configuration? Well, on that same 16GB system there might be only 7GB free after installing Windows – and then only if you don’t set up a separate recovery image.
If you want to try this out yourself, the necessary process for setting this up on a computer are discussed in the ADK documentation. The basic steps:
Make sure you understand the requirements and pre-requisites for doing this, as discussed at http://technet.microsoft.com/en-us/library/dn621983.aspx. And recognize that at this point in time, existing deployment tools like WDS, MDT, and Configuration Manager do not include any native support for deploying Windows using WIMBoot, so this may be more of a manual process.
Expect to see new tablet devices in the coming months that come pre-configured using WIMboot.
Michael Niehaus, Senior Product Marketing Manager, Windows Commercial
I have access to a working image created for my registered, activated, 32GB 3 week old 8.1 tablet created by another gentleman. Is there a problem with me using the image he created? Thanks
Michael, I'm sure you have thought about other potential uses for wim boot. I would love to hear your thoughts on those if you have a minute.
One of the things I thought of was the ability to consolidate images (taking advantage of single instance storage in wim images), or multiboot (pick what OS you want to boot to). Are there other uses that you have thought of (or anyone reading this)?
If I purchase a Surface 2 today will it have this feature implemented? If not, will some future update enable it to reduce OS capacity use OR is there a way I can rebuild said Surface to make use of this tech?
Good implementation by a user on a 32 GB Toshiba Encore here..
As Niehaus indicated, apparently it uses copy-on-write to handle file updates. For example, when file X is updated, it creates a new local copy on the C drive, replacing the prior symlink into the compressed image. Therefore the WIM image never has to be updated, which would be a very expensive operation. Thus, the install footprint will grow over time, depending on how many updates are applied. This does complicate matters a bit, as I wonder how it will handle those file updates when the WIM image is replaced. The symlinks could simply be reset, deleting the updated files, I suppose.
This isn't intended for VDI scenarios, just for the 16GB/32GB UEFI scenarios described above.
Could this be used in a VDI scenario? i.e., is the Images partition non-unique per OS install, so multiple virtual machines could use the same partition. If so, then one would save around 3Gb per virtual machine, which could add up to quite a saving with many VMs.
Obviously, would need to ensure that partition is on fast storage, but that's usually not a problem with a good VDI setup. Would also need to consider the processor overhead, but that's just a trade-off for storage space.
We don't have any formal benchmarks on the performance impact. But since this focuses on new smaller, cheaper tablet devices that typically have plenty of CPU power and don't typically run a lot of desktop apps, the impact is not expected to be noticeable.
So.. if you swap the WIMBoot image out for a patched one at a later date I'm guessing you will still need to migrate the user settings etc. and let the mini-setup wizard run? As you would for a normal OS refresh.
It would be awesome if there was a way to swap out the underlying WIMBoot image, clean up patches etc. on the 'C: drive' and just have it work - however the engineering for that would be non-trivial ... at best!
Although it's aimed at pc/tablets that have small ssd or eMMC drives, it is still attractive to those who use desktop/laptop PCs with limited-size SSDs to run their system and softwares/games faster.
So how much will it impact on performance, is there any benchmark test results? If it just makes first-time loading time of system files a little longer, it's totally acceptable.
Seems like we'll still see decay without getting updates rolled into this WIM. Is that something the OEM will own?
This is not something currently used with Windows To Go. Sorry, we can't comment on possible future plans.
Is this setup utilized while using a Windows to Go drive created with 8.1 Update? If not, is that in the plans for the future? Windows to Go drives are generally going to be similarly storage-constrained. Besides that, I can't think of something much more useful than a USB drive that could both run my image of Windows as well as be used to deploy Windows.
The WIM file is always read-only. Updates are applied to the "real" C: drive. So there will be some increase in the Windows footprint over time.
BitLocker is supported on the "real" C: drive, encrypting all the added files: apps, data, and all the other changes. But it is not recommended on the images volume.
I have more or less the same question as Martin, what about update packages: Are they merged into the WIM image and as such keep the total Windows footprint limited or are they sitting next to the WIM image and as such overtime expand the total Windows OS footprint on the device?
does / how does BitLocker work on / with WIMBoot?
There is some performance impact, which is why this only targets new computers with small SSD or eMMC-based hard drives.
The user profile, apps, Windows updates, and anything else applied to the OS after it is initially installed ends up on the "real" C: drive (the WIM is read-only), so there is no relocation needed.
If you injected the security updates into the WIM used to set this up, then a reset would include those. But if they were added after the machine was up and running (via Windows Update) then the reset would require reinstalling those.
Are there any performance implications to running Windows from the WIM image?
Also how are the user's personal files affected? At the moment there is limited ability to relocate a user's profile, and app data folders (at least within the Windows UI).
What about Windows Update packages... Do they get saved along with WIM so that performing a PC Refresh or Restore updates to the latest version of Windows with all windows updates released to date?