Skip Ribbon Commands
Skip to main content



WinPE: Automatic Image Applicaiton

Documentation and logs for UVM OS and application distribution methodologies
This is a rough outline of how our current UFDs boot WinPE and start a batch file to apply an image stored on the boot drive.

Begin by preparing a bootable drive (in this case a Universal Flash Drive, aka. Thumbdrive) with a Generic WinPE 2.0 image.  The generic image does not jump into any application as do the Discover, Capture and Light Touch images.  It simply leaves you at a command prompt after wpeinit completes.

Mount the boot.wim image file with read and write capablility.
imagex /mountrw e:\sources\boot.wim 1 c:\mount1

In the folder \Windows\system32\ at the mount point,  you will find one .ini file named winpeshl.ini that designates a shell to call after the boot process is complete.

Replace this with a call to your batch file for applying a .wim image:

Here, I'm creating batch files in the root of the Windows directory.  This can be anywhere (and probably should be elsewhere), but I was looking for a location that was already on the %PATH% of the default image, thus \windows.

The application process I'm using has four parts:

  1. Quick format the C: volume to NTFS.
  2. Make sure the drive letter for the boot device (i.e. the UFD you started PE from) is consistent.
  3. Apply the .wim image on the boot device to the C: volume.
  4. Shut down the system.

The control logic of the image.bat file looks like this:
diskpart /s %SYSTEMROOT%\formatc.txt
timeout 3
diskpart /s %SYSTEMROOT%\setdriveletter.txt
timeout 3
call applyimage.bat
timeout 3
%SYSTEMROOT%\system32\wpeutil shutdown

Diskpart.exe is used to manipulate the drive and is itself controlled by simple scripts (thus the /s switch).  Timeout.exe is a program included with Windows Vista that I have placed on the PE image in the \windows folder to allow the introduction of short delays before moving on to the next command.  This was necessary to compensate for an as yet unexplained delay in diskpart finishing the previous operation.

Here are the diskpart control scripts:

select disk 0
select volume c
format fs=ntfs quick

The rescan may be unnecessary, but doesn't seem to hurt anything.  The hard drive of the sytem always seems to appear as Disk 0.  Diskpart allows selection of data volumes by name, thus no need to select disk, partition, and volume by number.  The disk and partition would probably always be 0 and 1 respectively, but the volume number seems to be variable.  The selecting of disk 0 also seems to be redundant and can probably be removed.

select disk 1
select partition 1
assign letter=I

This was the tricky part.  You can't place a multi gigabyte drive image inside the boot.wim, and thus in the X: drive ramdisk -- it just won't fit!  You need to have access to the .wim file you want to apply to the C: volume, but the drive letter it appears in varies depending on what the PE OS detects and assigns at boot.  This can usually be E:, F:, G:, etc. by default depending on the number of other drives (hard, optical, removeable, etc.). 

The PE boot drive always seems to come up as the next disk after the local hard drive, thus disk 1.  This would proabably be different for a more complicated system (i.e. more than one hard drive), but fortunately, we don't sell those types of systems 99.9% of the time.  Setting a drive letter too low in the alphabet can cause conflicts, thus the final issue was resolved by forcing the volume to use the letter I.

At this point we have our PE OS running off the ramdrive (X:), and the UFD we booted from accessable as the I: drive.  All we need to do now is call imagex to apply the .wim file to the C: volume and then do a clean shutdown.

imagex /apply I:\2007-07-09_LAT_D820_STU_SYSPREP2.wim 1 c:

the .wim file name will of course depend on the actual name, the above is just an example.

Finally, we call wpeutil with the shutdown argument to power off the system after the image is applied.