Tags

 

So we all know Windows PE is good for things like capturing images with imagex, using USMT for migrating offline profiles, troubleshooting, repairing missing files, and so on.  Windows PE has become the default jumping off point for many things, including installing Windows, as of Vista and Server 2008.  The default Windows PE environment is great for doing some basic tasks, but I wanted some more options .  While this version we are about to customize is no where close to Microsoft’s DaRT (Diagnostics and Recovery Toolset), its good for my current needs and can be improved upon with a little more effort. 

The first step to getting a Windows PE environment is to download and install the Windows Automated Installer Kit (WAIK) from the Microsoft Download site (http://go.microsoft.com/fwlink/?LinkId=136976).  Once installed the documentation walks through setting up a basic PE environment – there are plenty of places walking through the setup and I’m not going to repeat it here.

Once we have our PE directory setup, we are going to customize it – note I’m using the x86 PE since its cross platform for imagex and USMT.  Before we get down to the details it will be easier to download the two suites, we are adding to our image, now. 

First go to http://www.emsisoft.com/en/software/download/ and grab either the Emsisoft Free Emergency Kit or the Emsisoft Commandline Scanner.  I downloaded the Emergency kit, only because some of the tools would be useful removing malware inside Windows; however, to save a little space the command line version is what we’ll be setting up to run in PE.

Next head over to Sysinternals (http://technet.microsoft.com/en-us/sysinternals/default.aspx) and download the Suite – getting the suite is optional.  If you have no need for any of the tools skipping this saves a little bit of space. Make sure to download the utilities to somewhere memorable. 

While the tools download, we are going to mount our boot.wim – in the deployment tools command prompt, execute (substitute the correct paths to the boot.wim and mount point):

imagex /mountrw Isosourcesboot.wim 1 mount

While boot.wim mounts, we need to unzip our downloads – hopefully, the downloads are finished, if not get some coffee and come back later — and get ready to copy them into our image. Once the wim is mounted and our tools are unpacked we can either copy the tools into mountProgram Files, isoTools, or both depending on the need.  I put mine in both places; if the tools are placed only inside boot.wim, they will only be accessible while Windows PE is running or the image is mounted – putting them in both takes up more space, but gives a little more flexibility.  Of course, it is possible to put them in the Tools directory and use a script to add the dynamic location to the PATH variable.   

At the command prompt, still, use the following commands to put the tools in the correct place – robocopy puts copies in Program files of PE and the moves the souces files to IsoTools

robocopy /e sourcesa2usb mountProgram Filesa2usb

robocopy /e sourcesSysInternalsSuite “mountProgram FilesSysInternalsSuite”

move sourcesa2usb isoTools

move sourcesSysinternalsSuite IsoTools

I, also, put USMT and Imagex into my PE imagex by following the directions included with the WAIK, however, I put the x86 USMT and imagex into my boot.wim Program Files too. 

     

Optional — To remove “Press any key to boot from cd” prompt,  delete or move bootfix.bin from isoboot or leave it.  I like my disc or UFD to boot without having an extra key press.

With our new tools in place, we need to write a couple of scripts and add some files to the PE image. First thing, add the HTA-Scripting package, which will allow the Emsisoft (was a^2) command line scanner to run. To add the package execute:

dism /image:C:winpe2mount /Add-Package /PackagePath:”C:Program FilesWindows AIKToolsPEToolsx86WinPE_FPswinpe-scripting.cab”

dism /image:c:winpe2mount /Add-Package /PackagePath:”C:Program FilesWindows AIKToolsPEToolsx86WinPE_FPsen-uswinpe-scripting_en-us.cab”

If both packages are not added, Windows PE will BSoD at boot. 

Optional – If drivers were needed during the Windows 7 setup, then drivers will probably be necessary for Windows PE to run – especially chipset and RAID drivers.  I stored all my drivers in a specific directory broken down by architecture – i.e. driversx86 or driversx64 so I add the whole x86 directory with dism /image:c:winpe2mount /add-driver /driver:c:driversx86 /recurse

Set scratchspace – defaults to 32MB and maxes out at 512MB:  dism /image:c:winpemount /set-scratchspace:256

 

Up till now, we have been adding drivers and customizing the PE environment to run the way we’d like it.  There are a few things to make the environment easier to use with our newly added tools.  The first is setting up the PATH environmental variable so our new tools are accessible from anywhere in PE.  First we need to create a directory under mount called ‘scripts.’  In this directory, we’ll put our scripts to customize the environment. 

 

Adding directories to the PATH environmental variable is a straight forward task.  From the command line run, set path=%path%x:xxx;  which will add a specific directory to the path.  To view the path, echo %path%.  Of course, we don’t want to manually set our path variable every time PE is started – at least, I don’t because I’ll forget every single time.  The easiest thing is to write a batch file and call the batch file from startnet.cmd located in mountPointWindowsSystem32, where mountPoint is wherever the wim is mounted..  A default startnet.cmd, only contains the command wpeinit – required to get the PE environment running and provide a command prompt.  Before we add our script to startnet.cmd, we have to write it, or add it then create a batch file with the same name; at the deployment command prompt, run notepad mountscriptssetPath.bat to create a new file in Notepad. Choose “Yes” when asked to create a new file.  Generally, Windows PE is going to mount boot.wim to x: and assign other drive letters in order of discovery – this means the offline root directory most likely will not get the drive letter of c: without user or script intervention – something I’ll try to cover in a later post.  Right now, we just need to know x: is normally where we our boot.wim ends up, which means we can script our path based off this information.  The thing to know about setting the path variable is the command processor is only going to look for executed files in directories explicitly set in the path variable, other programs or scripts have to be in the current working directory or called with an absolute path.

Basically, we put our tools in Program Filesa2usb and Program FilesSysinternalsSuite and to add these to the path we run set path specifiying the new directories.  I’ve also put the scripts, Program FilesUSMT, and Program FilesWaik – Waik only contains x86 imagex.

So our script will look like:

set path=%path%x:Program Filesa2usb;x:Program FilesSysInternalsSuite;x:Program FilesUSMT;x:Program FilesWaik;x:scripts;

Optionally, @echo off can be added to hide the script execution from the user.

Our final setPath.bat script should look the image.

 

Next, we need to add a call to our script in startnet.cmd.  All we have to do is add x:scriptssetPath.bat before wpeinit. 

 

Now we’re pretty much all set for our program execution.  We still need to add the ability to change the screen resolution.  There are several different ways to approach controlling resolution.  Many people choose to download and bundle setRes.exe into their boot.wim, and other choose to use unattend.xml files to control WinPE.  I’m going to use unattend.xml files.  Why you ask.  Just because I felt like it seemed cooler. 

Using an unattend.xml to control the resolution is pretty straight forward.  All which is to change the settings inside the file and call wpeinit /unattend:file to set it.   Again, we are going to try to simplify life a little more. 

A basic unattend.xml looks like this for our purpose:

 

 

By changing HorizontalResolution and VerticalResolution, we get new resolutions. So what I did was create two unique xml files – 1024×768.xml and 800×600.xml with the matching settings inside.  From this I created a basic batch file with a menu to change resolutions on the fly.  My batch files looks like the following image.

 

Unmount and commit changes with : imagex /unmount c:winpe2mount /commit

Don’t forget to commit the changes made up to this point, or you’ll get the experience of doing everything a second time – or more in my forgetfulness. 

I wanted to also have the x64 WinRE on my boot medium, since most PCs are becoming x64 based.  I put the x86 WinRE on here too, however it could be easily added to WinPE with a few additional packages.

To change the boot description of the default boot entry:  bcdedit /store bcd /set {default} description “WinPE x86”

Adding WinRE x64 to boot menu.

To add WinRE to the boot medium, we need to get a copy from the install medium.  Mount the wim from the install source and copy windowssystem32Recoverywinre.wim from install source to winPEsourcesboot directory.

 

Adding the new wim to the BCD by copying the default settings to a new entry:

bcdedit /store c:winpe_x86isobootbcd /copy {default} /d “WinRE x64”

 

Make sure entry was added and acquired GUID

bcdedit /store c:winpe_x86isobootbcd


My GUID is {e1d420a1-a189-11df-80d1-001fd09210dc}

The following commands set the device and so options for the new boot entry.

bcdedit /store c:winpe2isobootbcd /set {e1d420a1-a189-11df-80d1-001fd09210dc} device ramdisk=[boot]sourceswinReX64.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}
bcdedit /store c:winpe2isobootbcd /set {e1d420a1-a189-11df-80d1-001fd09210dc} osdevice ramdisk=[boot]sourceswinReX64.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}

 

 

My WinPE imaged turned out to be slightly larger than I wanted, so I optimized the .iso with oscdimg during creation: oscdimg –n –m –o –bc:winpe2etfsboot.com c:winpe2iso c:winpe2winPeX86.iso

Before Optimize After Optimize

Final shot of the boot menu.

Now we have a basic customized WinPE environment. Many things still can be done to improve this process, but it works for a basic starting point.  The one major improvement would be to script adding the Tools directory to Path environmental variable instead of duplicating the files in two places – a major waste of space. 

— Edit —

I forgot to mention a major point.  When scanning with a2cmd.exe, a page will need to be created a volume, else a2cmd will crash very quickly after starting the scan.  I determine where to create my pagefile by using the list volume command inside diskpart.  This lists all the volumes attached to the unit.  I use the information to determine, which volume is the offline windows directory, and then use wpeutil createpagefile /path=pathToPagepagefile.xyx /size=xxx  where pathToPage is wherever the pagefile will be and xxx is pagefile size in MB.  Both switches are optional, but the path is highly recommended.  

Advertisements