This info is copied from the CHM file provided in the 8.1 update ADK.
This is a reference post and will likely just confuse you if you don't know what you're doing.

Formatting info:

Format the drive with the WIMBoot partition layout

1. Boot the reference PC into Windows PE 5.1.
2. Format the drive using the following partition layout:

• System (EFI System Partition): Size: 100MB.
If the primary drive is less than 16GB, you can use a minimum size of 32MB.
If the primary drive is an Advanced Format 4K Native drive (4-KB-per-sector), the minimum size is 260 MB.

Note
If you plan to make changes on the factory floor in the custom.wim file, be sure to leave enough space for these additions. But try not to add too much free space, especially on devices with limited drive space, because this partition can’t be resized after you've added files to it.

To work around this problem, you can set up this Images partition later. For more info, see Deploy WIMBoot Images: If you don't know the size of the images upfront.

Sample Diskpart script

The script temporarily assigns these drive letters: Windows=C and Images=M. If you’re deploying to PCs with unformatted hard drives, you might want to modify this script to use a drive letter that’s near the end of the alphabet, such as W, to avoid drive letter conflicts. Do not use X, because this drive letter is reserved for Windows PE. After the PC reboots, the Windows partition is assigned the letter C, and the other partitions don’t receive drive letters. We've added volume names to the partitions, but they aren’t required.

1. Create a folder called "Windows Images" on the Images partition. This folder name is required.

Code:

md "M:\Windows Images\"

2. Copy the Windows image from the USB or network drive (N) to the Windows Images folder. Rename the Windows image to install.wim if necessary.

Code:

copy N:\Images\install_update1.wim "M:\Windows Images\install.wim"

3. Apply the Windows image to the Windows partition (drive C), using the /WIMBoot option.

Recommended: create a temporary scratch folder for DISM to avoid issues related to short file names. To prevent capturing the DISM logs in your image, choose a location that is in your DISM Exclusion list. For more info, see DISM Configuration List and WimScript.ini Files.

When you use the DISM /Apply-Image command with the /WIMBoot option, the ImageFile location and ApplyDir partition must be on the same hard drive.

Note
When you apply the Windows image using /WIMBoot, DISM adds pointer files from the Windows partition to the Images partition. These pointer files make the PC appear and function as if the Windows files were stored on the Windows partition. But they still primarily reside inside the install.wim file in the Images partition. Do not remove the install.wim file after applying the image.

4. Create boot files and set them to boot to the Windows partition.

Code:

C:\Windows\System32\bcdboot C:\Windows

5. Copy the Windows RE file to the Images folder. Note that Winre.wim may be a hidden file. Use robocopy or xcopy to copy the file. In this example, the "echo f" command suppresses the xcopy "File or Directory" prompt:

7. If your partition configuration is different from the recommended configuration listed above, create a ResetConfig.xml file and include it in the M:\Windows Images\ folder to enable your users create bare metal recovery media. For more info, see ResetConfig XML Reference.

Create WIMBoot Images
Windows image file boot (WIMBoot) helps you save hard drive space by booting to a WIM file rather than a set of uncompressed Windows files. For more info about WIMBoot images, see Windows Image File Boot (WIMBoot) Overview.

To save room on the images, separate the Windows Recovery Environment (Windows RE) image from the main Windows image. Otherwise, this image will take up 200 MB or more of extra drive space in your image and will otherwise never be used.

This image is stored inside the main Windows image at \Windows\System32\Recovery\winre.wim, and might be a hidden file.
This page focuses on a method to create WIMBoot images that use a minimum of drive space. It also discusses other methods to create WIMBoot images to reduce the total number of Windows images that you manage.

Recommended Method: Create a WIMBoot-optimized imageCreate a temporary copy of the install.wim image
• Copy the install.wim to a new temporary file. You'll use this copy of the file to create your WIMBoot image.

Code:

Copy C:\Images\install_updated.wim C:\Images\install_temp.wim

Separate the Windows RE image from the main Windows image

1. Create a mount directory for your install.wim files and mount the image.

Optimize the Windows image for WIMBoot
• Optimize the image for WIMBoot to gain free drive space in the final image.

Note
Don't optimize the image using the /WIMBoot option for traditional (flat-boot) PCs, or for images used in enterprise deployments. The optimization process removes features for on-demand installation that might be needed for these PC deployments. For more info, see To remove Windows features for on-demand installation.

Code:

Dism /Optimize-Image /Image:C:\mount\Windows /WIMBoot

• Unmount the image and commit the changes.

Code:

Dism /Unmount-Image /MountDir:C:\mount\Windows /Commit

Boot the image to apply the updates and to clean up the image

1. On your reference PC, boot to Windows PE 5.1, apply your Windows image, and then boot the PC again. For more info, see Samples: Applying Windows, System, and Recovery Partitions by using a Deployment Script.
2. Press CTRL+SHIFT+F3 at OOBE to enter audit mode.
3. Clean up the Windows image to gain additional free drive space in the final image. Use /StartComponentCleanup to clean up the superseded components and reduce the size of the component store. If you've already used the /ResetBase option when creating your base Windows 8.1 Update image, you don't need to run it again. To see the file size reduction, you'll need to either recapture or export the image.

Code:

Dism /Cleanup-Image /Online /StartComponentCleanup

4. Use Sysprep to generalize and shut down the PC.

Code:

C:\Windows\System32\Sysprep\sysprep /generalize /shutdown /oobe

5. Boot the PC to Windows PE 5.1. If the PC starts to reboot to Windows, you'll need to let it finish booting and then use Sysprep to generalize and shut down the PC again.
6. Recommended: Create a temporary scratch directory, for example, C:\Recycler\Scratch. Choose a location on a physical drive to avoid issues related to capturing files with long file names in the default Windows PE virtual scratch space. Choose a space that’s in the DISM Exclusion list to prevent capturing the DISM logs in your image. For more info, see DISM Configuration List and WimScript.ini Files.

Code:

md C:\Recycler\Scratch

7. Recapture the Windows image. This captures the applied updates and removes any files that were marked as superseded during DISM /Cleanup-Image. Use the /WIMBoot option to save the image as a WIMBoot image. Save the file to a location on a USB drive or your network (example: N:\Images), and give the image a name (example: Enterprise_x64 with 8.1 Updates).

Method 2: Add WIMBoot support to a standard image
• To quickly add WIMBoot support to a standard (flat-boot) image to a WIMBoot image, you can either capture or export the image. The final image size will be larger than if you had optimized the image using the instructions on this page.

You’ll also need a separate, updated Windows RE (winre.wim) file. For more info, see Install the Windows 8.1 Update.
Example:

Note
If you don’t optimize the image (Dism /Optimize-Image /WIMBoot), you can use this image for both standard and WIMBoot PCs. This can help you manage fewer images in your deployment process.

Additional notes
• Don’t append images into an existing WIM file, because WIMBoot only supports using the first Windows image in the file (index value of 1).

Prepare a WinPE 5.1 image:

Create a bootable Windows PE 5.1 Drive:(Note that everything you do here needs to be done with a cmd prompt that has ran the DandISetEnv.bat in the adk install folder.
There's a link to a cmd /k version on your start menu after installing the 8.1 update 1 ADK)

Create a bootable Windows PE 5.1 drive by adding the Windows 8.1 update package to Windows PE 5.0, and then cleaning up the image.

(This resetbase step didn't work for me with the 17025 leaked msu files because of pending flags, but perhaps in the rtm version it will)

4. Unmount the Windows PE image.

Code:

Dism /Unmount-Image /MountDir:"C:\WinPE_amd64\mount" /commit

Create media

1. Create bootable media, such as a USB flash drive.

Code:

MakeWinPEMedia /UFD C:\WinPE_amd64 F:

(It's what the chm says. You can do the iso file for working with a vm if you prefer, just run makewinpemedia.bat without arguments and it will list the optional arguments and format)
2. Boot the media. Windows PE starts automatically. After the Windows PE window appears, the wpeinit command runs automatically. This may take a few minutes.

On the winpe5.1 I personally don't prefer to use the makewinpemedia.bat because it doesn't have a pause in the boot option.
Use the oscdimg.exe command from my example in post 1 if you want the press any key to boot prompt.

First, create a custom machine and tell it to use win8 x64
The rest of the details are not very important, but should be left at default settings.
The hard disk settings should be set to scsi and defaulted with the exception of the actual vmdk file or files.
Those are going to get deleted, so I'd recommend to switch it to single file for easier deletion.

After finishing the system setup, go ahead and exit VMware and open the \my documents\Virtual Machines\Windows 8 x64\ or whatever it's called
Edit the Windows8.vmx (again doesn't matter what it's called, just edit the vmx) You can do this in notepad or any other text editor.
Find the lines relating to the vmdk. It should be something like this:

Add the line corresponding to the scsi number to reflect the following:

Code:

scsi0:0.VirtualSSD = "1"

Also, somewhere in the vmx file you need to add the following:

Code:

firmware = "efi"

(Dont use = "EFI" - uppercase doesn't work)

Now you will have the 2 requirements for wimboot setup for testing.

Step 2) Create a VHD file with diskmgmt.msc:

You now should create a VHD disk image in diskmgmt.msc (I believe you might need admin permissions to run that)
Click Action menu item and select Create VHD.
I'd suggest creating a dynamically expanding vhd of at least 25 gigs.
When done creating your vhd, right click on it in the disk listing and select Initialize.
This may or may not be required, but I seem to remember it being needed.
Anyway, select GPT partition scheme. You don't need to format. Windows setup will do that.
right click on the vhd drive and select disconnect (detach?)
You can now cut/paste that vhd image and put it anywhere; literally anywhere.

Now go back into VMware and modify the system options.
Click on the VMDK and click remove (it won't delete it, you can do that manually though)
Now click the add button and select hard disk, but this time choose the Use an Existing Disk option.
Select your VHD that you created and finish up your settings.

Now select a win81 install media iso and boot that bad boy. (No you're not done, you have work to do)
Install your desired install index that you're going to use on your target wimboot system. (Note that any product keys you enter may save sensitive data, so be careful what you share)
Select the disk and proceed through setup until the user creation page. At this point you have 2 options, but I'll give you the longer recommended way.
Create a temporary user account. You can call it anything (tempy, murphy, whatever)
Proceed through setup and choose whatever options you want. They don't matter, you're going to be deleting this account anyway.
(murphy you a**hole, are you serious? Yep.)

So the reason you create a temporary account is that certain things do not work properly in Audit mode.
Windows/Microsoft Update is the main thing we're concerned about here. I've tested it, and it STILL doesn't work in Audit mode, even after adding all the KB files to date.
So, what we need to accomplish here is very simple. You need to install the Update KB files from the 8.1 update (wzor leak or later rtm versions)
How you do this is by plugging in a usb flash drive with the files on it, and clicking the little connection button in vmware or putting all of the msu files on an iso (just poweriso it or something easy)
Install the 3 or 4 updates and do whatever else you want to do on your install image, but know that the smaller the better when it comes to this image, so I'd recommend avoiding adding large programs like Office.

I personally add the updates and then run Windows Update and download all the rest of them (pre-release leak. RTM may not require previous rollups and such)

Step 4) Go audit or go home:

When you're finished and satisfied with the way you've prepared things, run admin command prompt (winkey+x, a)
In admin prompt run this command:

Code:

%windir%\system32\sysprep\sysprep.exe /audit

This will reboot your system into audit mode. (You need to do this to delete the temporary account info from the registry and such)
Once in Audit mode, ignore the sysprep box for now
Open the User Accounts menu in control panel.
Navigate to the delete user account option and delete your temporary account you created

Now cleanup things a bit before we're done:
Run cleanmgr and get rid of some junk files like icons and such.

*WARNING - Do not use this following command if you intend on using the Pre-Release updates as you will be locked into them and be unable to upgrade to newer versions*
Run this dism command to finalize and shrink the winsxs folder:

Code:

dism /online /cleanup-image /startcomponentcleanup /resetbase

That command is essential for reducing the size of your image, but unless you are absolutely certain about being locked into a pre-release, you should take care to only use it with RTM files.

Anyhow, now that you're done cleaning up, go back to the sysprep window and select your choices.
If you choose the generalize option, it will delete any hardware settings from your system, but may or may not remove product keys. (Be careful with sharing again)
Choose the shutdown option and let it work.

Step 5) Attach the VHD, clean it up, and capture it:

When the VMware system is shut down properly, go back into diskmgmt.msc and now Attach VHD on the vhd you created.
It will likely bring up like 4 new drives. We're only interested in the main one (This is the main partition. The others are gpt partition scheme ones and will likely appear blank if you don't have sys files avail for view)
Open the windows drive and delete the following folders:

Now you're ready to capture the disk, but we still have a few things to do:
1) Remove the \windows\system32\recovery\winre.wim and stuff it somewhere for images like c:\images or something*
*winre.wim is a system file and may not be viewable. Also, I think UEFI setup moves the file to a different partition or something.
*when you mount the vhd, you might need to turn on system file view ability and hunt the different vhd partitions for it.
2) Run the following dism command and point it at the disk you are about to capture:

Code:

Dism /Optimize-Image /Image:Z:\ /WIMBoot

Obviously change z:\ to whatever the disk is with all of the files.

To Capture the WimBoot image you can use the DandISetEnv.bat environment in the 8.1 S2014 ADK. (There's a shortcut in start menu after installing it):

You're done once it's finished capturing. Stowe that install.wim somewhere you won't lose it. You can right click and detach the vhd in diskmgmt.msc at this point.

That's it for the VM instructions on how to create the image.
Now use that image in the instructions on post 1 and you can use the same Virtual Machine to test it out before trying it on a real system.

Like seriously, my Father's chromebook boots in like 10 seconds, tops; and that's a conservative estimate.

Click to expand...

Um, that's not very impressive, seeing as how a clean boot (not "fast startup") for my UEFI+SSD W8.1 systems is around 10 seconds. Get a modern system with UEFI and SSD and then wonder how you ever lived without them.

I'm also skeptical that it would be able to speed up boots substantially. Yes, it reduces I/O, but since this is available only on SSDs, the I/O should already be pretty fast. Booting is also a somewhat CPU-intensive process, and using WIM will increase the CPU strain. It is entirely possible that this would result in the bottleneck shifting from the I/O to the CPU and thus limit the potential speed improvements.

Anyway, I think this is something that is really aimed at products like Windows tablets such as my Dell Venue 8 Pro.

* Space is at a major premium in these sorts of systems. My DV8P has only 32GB of storage, and most of that is taken by the OS. If the OS can live as a compressed WIM image, that would save a substantial amount of space.

* If the WIM is kept read-only, then this would make recovery much, much easier. It would be like Android, where the OS lives secluded in its own read-only partition and everything else, even updates for the apps that were bundled in the core OS, are put into a separate partition, which means that resetting a system to a pristine factory state is trivially easy--just nuke the writeable partition. Right now, the built-in reset feature in W8 isn't as robust as wouldn't be able to guarantee that the system would be in a 100% cleaned state because it doesn't have that kind of firm line in the sand. This sort of OS-as-an-image approach would resemble that of other tablets and is well-suited for the kind of casual consumption usage pattern of tablets. It's seems less well-suited for general computing.

Um, that's not very impressive, seeing as how a clean boot (not "fast startup") for my UEFI+SSD W8.1 systems is around 10 seconds. Get a modern system with UEFI and SSD and then wonder how you ever lived without them.

I'm also skeptical that it would be able to speed up boots substantially. Yes, it reduces I/O, but since this is available only on SSDs, the I/O should already be pretty fast. Booting is also a somewhat CPU-intensive process, and using WIM will increase the CPU strain. It is entirely possible that this would result in the bottleneck shifting from the I/O to the CPU and thus limit the potential speed improvements.

Anyway, I think this is something that is really aimed at products like Windows tablets such as my Dell Venue 8 Pro.

* Space is at a major premium in these sorts of systems. My DV8P has only 32GB of storage, and most of that is taken by the OS. If the OS can live as a compressed WIM image, that would save a substantial amount of space.

* If the WIM is kept read-only, then this would make recovery much, much easier. It would be like Android, where the OS lives secluded in its own read-only partition and everything else, even updates for the apps that were bundled in the core OS, are put into a separate partition, which means that resetting a system to a pristine factory state is trivially easy--just nuke the writeable partition. Right now, the built-in reset feature in W8 isn't as robust as wouldn't be able to guarantee that the system would be in a 100% cleaned state because it doesn't have that kind of firm line in the sand. This sort of OS-as-an-image approach would resemble that of other tablets and is well-suited for the kind of casual consumption usage pattern of tablets. It's seems less well-suited for general computing.

Click to expand...

Yah, honestly I don't know how fast that chromebook boots up. I didn't wanna look like an ass saying it was 5 seconds if it was closer to 10. I think it's probably a lot closer to 5.
I'm definitely looking forward to getting an ssd. Money has been tight for me. I refuse to do what a lot of those scumbags on the internet do and post a lot of illegal downloads on sites and work out a deal with a file hosting site.
That just seems sh**ty to me and I'm not down for actually taking money for something that wasn't mine in the first place.

Edit: As far as the read-only I believe it allows expansion as long as the partition is large enough, but I seem to recall reading somewhere that there was a partial image file or something...
There's a lot of info to digest. Right now I'm going through it step by step trying to actually do it, before doling out advice.
Pardon me if I'm a bit unresponsive whilst churning through the steps...

* If the WIM is kept read-only, then this would make recovery much, much easier. It would be like Android, where the OS lives secluded in its own read-only partition and everything else, even updates for the apps that were bundled in the core OS, are put into a separate partition, which means that resetting a system to a pristine factory state is trivially easy--just nuke the writeable partition. Right now, the built-in reset feature in W8 isn't as robust as wouldn't be able to guarantee that the system would be in a 100% cleaned state because it doesn't have that kind of firm line in the sand. This sort of OS-as-an-image approach would resemble that of other tablets and is well-suited for the kind of casual consumption usage pattern of tablets. It's seems less well-suited for general computing.

There is no speed increase possible with this (not sure why you even think so?), instead its a speed decrease and of course you need a SSD, on a HDD this isn't viable. It's really only interesting to save space, not so much if you want speed.

[SIGPIC]Windows[/SIGPIC]​

Stop hovering to collapse...Click to collapse...Hover to expand...Click to expand...

There is no speed increase possible with this (not sure why you even think so?), instead its a speed decrease and of course you need a SSD, on a HDD this isn't viable. It's really only interesting to save space, not so much if you want speed.

Click to expand...

How do you figure? We don't even know much about the /wimboot option in dism yet.

There is no speed increase possible with this (not sure why you even think so?)

Click to expand...

As I noted in my earlier post, I don't think a speed increase is likely (or if there is, it would be very small), but this sort of thing is not unprecedented. Firefox, for example, keeps all of its core files in one giant zip file (omni.jar). Why? To speed startup. CPU cycles are abundant. I/O is scarce. Even with SSDs, I/O is often still the bottleneck.

For the kinds of systems that I suspect WimBoot is targeted for (tablets), the storage is usually eMMC and isn't very fast. It's still solid-state storage, so it doesn't have a huge random access penalty (which is what the SSD requirement is really about), but these things aren't very fast. Meanwhile, the Bay Trail CPU is surprisingly muscular.

Anyway, until we see this in action in the real world, it's hard to predict how things will pan out performance-wise. I think a large speed increase is highly unlikely, but I'm also not ready to say that it will be a speed decrease.

As I noted in my earlier post, I don't think a speed increase is likely (or if there is, it would be very small), but this sort of thing is not unprecedented. Firefox, for example, keeps all of its core files in one giant zip file (omni.jar). Why? To speed startup. CPU cycles are abundant. I/O is scarce. Even with SSDs, I/O is often still the bottleneck.

For the kinds of systems that I suspect WimBoot is targeted for (tablets), the storage is usually eMMC and isn't very fast. It's still solid-state storage, so it doesn't have a huge random access penalty (which is what the SSD requirement is really about), but these things aren't very fast. Meanwhile, the Bay Trail CPU is surprisingly muscular.

Anyway, until we see this in action in the real world, it's hard to predict how things will pan out performance-wise. I think a large speed increase is highly unlikely, but I'm also not ready to say that it will be a speed decrease.

Click to expand...

I could see lower-end SSD drives and tablets gaining more benefit, but who knows exactly what it does?
Do I think someone would shave 50% off their boot time? Unlikely; but 20% doesn't seem unreasonable.
Is it worth the hassle? For most people no. For system builders and tech saavy people, I'd say yes, it's worth it; depending on the performance gain.

Even if we successfully test this with the pre-release build, it won't matter until we re-do the test with the actual RTM build.

That would explain the slack of 50 megs in the partition instructions. Obviously the wim can fluctuate, but is not meant to do so very much.
They seem to be limiting the size of logs for the wim so that it cannot balloon too much.

Got it to work on VMware Workstation...
I used the 17025 leak and it seems to work, though I cannot tell if there's any speed improvement because its a vm and the disk image in on my rotary drive.
I'll see if I can work up some instructions to clarify things.
The sysprep seems to be the only highly involved part.
The rest is just in the preparation...

Once you have the scripts and everything is setup correctly, it's relatively easy.
I'll post a small 7z of the scripts

Guess I'm the one who gets the cookie.
(>'O')>( : : ) NOM NOM NOM

Edit: lemme edit these screenshots so you guys don't see the embarrassing games I play in my free time...