Deploying Windows 7 – Part 19: Building a Custom WinPE Tools CD

If you would like to read previous articles in this series, please go to:

Tip:
You can find more information about automating LTI deployment in the Windows 7 Resource Kit from Microsoft Press. I am the lead author for this Resource Kit and I also maintain the Unofficial Support Site for the Windows 7 Resource Kit with answers to questions posted by readers, as well as links to the latest resources on Windows 7 deployment, administration and troubleshooting.

In Part 18 of this series you learned how to create a WMI script that can be used to determine the UUID of a computer. The reason you may want to do this is because you wish to use the MDT database to customize the deployment of Windows 7 based on the UUID of each target computer (see Part 16 of this series for how to do this). Now, you can of course run this script on a computer that has a Windows operating system installed, but how can you determine the UUID of a bare-metal system, that is, a computer that has no operating system? The simple answer is to build a Windows PE “tools” CD that includes the script. Then, using this CD you can boot a bare-metal system, run the script, and display the system’s UUID. And that is what this article is about.

Note:
The steps for building a custom Windows PE image have changed in Windows 7 from Windows Vista. To learn how to build Windows PE 2.1 (Windows Vista SP1 and later) see my earlier article titled Deploying Vista – Part 11: Working with Windows PE.

Step 1: Create the Build Environment

To create the Windows PE 3.0 build environment, log on to a technician computer on which Windows AIK 2.0 has been installed. Then click Start, All Programs, Windows AIK, right-click on Deployment Command Prompt and select Run As Administrator. The Deployment Tools Command Prompt opens (Figure 1):


Figure 1: The Deployment Tools Command Prompt

In this walkthrough, we will set up a build environment for creating a 64-bit Windows PE image. To do this, type the following command:

copype.cmd amd64 C:\BUILDPE

Here \BUILDPE is a folder that will be created on the root of C: drive on our technician computer. This folder will be used to contain our build environment. The output of the command is shown in Figure 2:


Figure 2: Creating a folder to contain the build environment

Let us examine the build environment in Windows Explorer (Figure 3):


Figure 3

The folders and files in the root of our build folder are as follows:

  • \ISO folder contains the files needed to build an .iso file of Windows PE that we can burn to a CD
  • \mount folder is an empty folder where we will mount our image using DISM.exe so we can service it
  • etfsboot is a program we can use to create the boot sector for our Windows CD
  • efisys.bin is used instead of etfsboot on systems that boot using Extensible Firmware Interface (EFI)
  • efisys_noprompt.bin is used instead of etfsboot on IA64 systems
  • winpe.wim is a base Windows PE image file which we can customize as desired

To finish setting up our Windows PE build environment, use the copy command like this:

copy C:\BUILDPE\winpe.wim C:\BUILDPE\ISO\sources\boot.wim

This command copies the base Windows PE image (winpe.wim) from the root folder \BUILDPE to the \ISO\sources folder and renames it boot.wim (Figure 4):


Figure 4: Copying the base Windows PE image to the \ISO\sources folder and renaming it boot.wim

Let us verify the result using Windows Explorer (Figure 5):


Figure 5: Copy of the Windows PE base image.

Step 2: Mount the Base Image

Before you can service your Windows PE image, you need to mount it using the DISM command. To do this, we use the /mount-wim command-line option as follows:

dism /mount-wim /wimfile:C:\BUILDPE\ISO\sources\boot.wim /index:1 /mountdir:C:\BUILDPE\mount

The above command mounts the Windows image contained in the boot.wim file to the \mount folder of our build environment (Figure 6):


Figure 6: Mounting the Windows PE base image so you can service it

Tip:
For more information about the DISM command which is new in Windows 7, see Part 2 of this series.

Let us examine the mounted base Windows PE image in Windows Explorer (Figure 7):


Figure 7: The mounted base Windows PE image

Note that the folder structure of a mounted Windows image looks just like that of an installed Windows operating system.

Next, we are going to service (customize) our mounted base Windows PE image in two ways:

  • By adding support for running WMI scripts
  • By adding our UUID scripts to the image

Step 3: Add support for running WMI scripts

Before you can run WMI scripts from within Windows PE, you must add packages that provide such functionality to Windows PE. We will begin by adding the WinPE-WMI Feature Pack, which provides support for Windows Management Instrumentation (WMI) from within Windows PE. To do this, you need to use the /add-package command-line option of DISM. You also need to know where this package is located within the Windows AIK folder structure on your technician computer. Here is the command you use to do this:

dism /image:C:\BUILDPE\mount /add-package /packagepath:”C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\winpe-wmi.cab”

This command adds the package contained in the file winpe-wmi.cab to your mounted Windows PE image. Figure 8 shows the result of running this command:


Figure 8: Adding WMI support to Windows PE (step 1)

In addition to adding the package, you must also add the corresponding Language Pack (winpe-wmi_en-us.cab) for that package. For US English (en-us) this is done as follows:

dism /image:C:\BUILDPE\mount /add-package /packagepath:”C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\en-us\winpe-wmi_en-us.cab”

Figure 9 shows this being done:


Figure 9: Adding WMI support to Windows PE (step 2)

Although we have now finished adding WMI support to our Windows PE image, we still won’t be able to run WMI scripts from within Windows PE unless we also add the WinPE-Scripting Feature Pack (winpe-scripting.cab) and its corresponding Language Pack (winpe-scripting_en-us.cab) to our image. Figure 10 shows how this is done:


Figure 10: Adding scripting support to Windows PE

We can use the /get-packages command-line option of DISM to verify that the packages have in fact been added to the image (Figure 11):


Figure 11: Verifying that the packages have been added to the image

Note that the state of each package is displayed as Install Pending. This is because the changes we are making have not yet been committed to the image.

Step 4: Adding the Scripts to the Image

Let’s now add the two scripts (UUID.vbs and UUID.bat) we created in the previous article of this series to our mounted Windows PE image. We can use the copy command to do this by copying the scripts from a USB flash drive to the \Windows\System32 folder within our mounted image (Figure 12):


Figure 12: Copying the scripts to the mounted Windows PE image

We can use Windows Explorer to verify that the scripts have been copied to our mounted image (Figure 13):


Figure 13: The two scripts have been copied to the \Windows\System32 folder of the mounted Windows PE image

Why copy these scripts to the \Windows\System32 folder? Because that way the scripts will be included as part of the Windows PE RAM disk that is loaded into memory and accessible as X: drive from the Windows PE command prompt. If we copied the scripts instead to the \ISO folder of our build environment, the scripts would be included as part of the Windows PE CD and we would need to change to the CD drive letter before we could run the scripts from within Windows PE. So copying them to the \Windows\System32 folder makes it easier to run the scripts from within Windows PE.

Note:
If the scripts or tools you are adding to Windows PE require additional memory, use the /set-scratchspace command-line option of DISM to allocate 64, 128, 256 or even 512 MB of additional memory to Windows PE (the default allocation is 32 MB).

Step 5: Commit changes and dismount the image

We have now serviced (customized) the base Windows PE image by adding packages and scripts to the image. We can use the \unmount-wim command-line option of DISM to do this:

dism /unmount-wim /mountdir:C:\BUILDPE\mount /commit

Figure 14 shows the result of running this command:


Figure 14: Dismounting the image after committing the changes

Step 6: Create the Windows PE .iso image

We now need to transform our customized Windows PE image in the \BUILDPE folder into an .iso file that we can burn onto writable CD media. To do this, we can use the oscdimg command as follows:

oscdimg –n –bC:\BUILDPE\etfsboot.com C:\BUILDPE\ISO C:\BUILDPE\WMI-PE-CD.iso

This adds the CD volume boot sector to the Windows PE image and transforms it into an .iso file, which we have here named WMI-PE-CD.iso (Figure 15):


Figure 15: Using oscdimg to create an .iso file of Windows PE

Use Windows Explorer to verify that the .iso image has been created (Figure 16):


Figure 16: An .iso image file has been created using oscdimg from the customized Windows PE build environment

Now copy this .iso file to a computer that has a CD burner and burn it the file to the CD.

Step 7: Testing the Result

We are finally ready to test our custom WinPE “tools” CD. Turn on a bare-metal system, insert the CD and press a key when asked whether you want to boot the system from its CD drive. Once Windows PE has loaded and initialized, you will be presented with an X:\Windows\System32> command prompt. Simply type uuid at this command prompt and watch the UUID of the computer suddenly appear (Figure 17):


Figure 17: Using UUID.bat and UUID.vbs on a custom Windows PE tools CD to display the UUID of a bare-metal system

After performing Step 7 on a bunch of systems and copying down the results, you can create new entries in the MDT 2010 database that let you deploy customized Windows PE images to your computers—see Part 16 of this series for how to do this.

If you would like to read previous articles in this series, please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top