New information has been added to this article since publication.
Refer to the Editor's Update below.

System Management

Getting Started with Windows PE

Wes Miller


At a Glance:

  • The history of Windows PE
  • How Windows PE can stand in for MS-DOS
  • How to customize Windows PE
  • Windows PE Q&A

Download the code for this article: WinPE2006_09.exe (155KB)

Chances are you don't know much about the Microsoft Windows Preinstallation Environment, or Windows PE as it's usually called, even though it shipped the same day as Windows XP. Windows PE was

designed to allow Windows® setup or a 32-bit imaging program to run on a PC even with no version of Windows installed. The idea was to make things easier for OEMs. Windows PE has evolved over the years and, as you'll see, it can make your life easier as well.

For quite some time, MS-DOS® played a big part in Windows installation and setup, but eventually that became problematic. As both Windows and hardware grew more sophisticated, MS-DOS couldn't keep up. Its shortcomings as a setup initiator for doing a custom setup were plentiful. Performance was a big issue, so was driver availability. These problems became the key impetus for replacing MS-DOS for OEMs and eventually enterprise customers.

A developer on the Windows setup team came up with the idea of integrating the different components of setup into one solution so that a simple boot CD could provide a minimal environment that would let 32-bit setup run, eliminating the problems with MS-DOS. With that, Windows PE was born. Originally, the Windows setup CD included both a prebuilt version of Windows PE and a toolset that let you create your own build. Today, Windows PE is shipped only as the toolset; you need to build your own copy.

Eventually, Windows PE spread beyond the OEM community it was designed for. ISVs, enterprise, education, and government customers all took advantage of it, and they used it for far more than the deployment scenarios we initially envisioned. They used it for recovery and diagnostics as well. Today, Windows PE is available for customers with Software Assurance, as well as Enterprise Agreements, Campus Agreements, and as a component of several other licensing agreements with Microsoft.

[**Editor's Update - 8/22/2006:**Windows PE is only available as a Software Assurance benefit with certain types of license agreements. See the Microsoft Volume Licensing Web site for more details, or contact your Microsoft licensing specialist.]

When running, Windows PE looks like Figure 1. You'll note that it doesn't include Windows Explorer, and as such does not have any of the regular Windows shell available. It's truly a bare-bones installation.

Figure 1 Default Configuration of Windows PE Booted to the Command Shell

Figure 1** Default Configuration of Windows PE Booted to the Command Shell **

What You Get

As you can see in the sidebar "Windows PE Releases," there have been a number of upgrades. The basic functionality of Windows PE was broadly expanded to allow OEM partners and enterprise customers to perform WMI queries on hardware and to initialize classes of devices that no one originally had expected would be used under Windows PE. Windows PE was initially designed to boot from CD; network boot via PXE was an afterthought, and the hard drive method came very late in development. The intent with Windows PE was always to allow for a 32-bit environment with TCP/IP networking, hard disk access to enable imaging or scripted installation of Windows, and basic video support. Windows PE always uses the same basic VESA mode video driver regardless of the card in use. This lets it display very good color depth and resolution on modern VESA-compliant hardware, though some older hardware may default to a very unpleasant (though usable) color depth and resolution.

From the beginning Windows PE had only very basic Win32® API support, meaning that the Microsoft® .NET Framework, DirectX®, TAPI/MAPI/SAPI, audio, and many other high-level Windows APIs would not be available. Windows PE users began to regularly request a number of additional features. We were unable to officially engineer these features into the product, but we did provide a script that would allow a Windows PE admin add ADO connectivity to a Microsoft SQL Server™, and HTML for Applications (HTA) and Windows Script Host (WSH) support to an image. These provided a handy framework of tools that have enabled some creative deployment and recovery solutions. Windows PE 2.0, which is scheduled to ship with Windows Vista™, will add notable new capabilities.

Booting Windows PE

When you're starting with Windows PE, one of the first considerations is how you want to boot. Over the years the number of boot mediums supported by Windows PE has grown (see Figure 2).

Figure 2 Windows PE Boot Options

  • PXE (Pre-boot eXecution Environment) using RAMDisk boot technology
  • RIS (the Microsoft proprietary PXE implementation, which is traditionally used to launch Windows setup over the network)
  • Hard Disk (either directly or via a RAMDisk)
  • CD (or an ISO-formatted DVD)
  • RAMDisk (this allows for some very interesting scenarios which I’ll describe in depth in an upcoming article)
  • USB Flash Drive (UFD)

Technically, Windows PE can also boot from an LS-120/LS-240 disk, though I'd never recommend it due to serious performance issues. USB Flash Drive boot is something we worked hard on for Windows PE 1.6. It works very well, though it's only supported by Microsoft when an OEM provides it with a new system because there's no reliable way to ensure that systems would have the necessary capabilities. This method requires BIOS-specific functionality that must be provided by the PC manufacturer, as well as USB 2.0 support.

Your particular needs will determine how you can best use Windows PE. The important thing to remember is that you can basically reuse the same technology across multiple boot methods, no matter which one(s) you choose.

Before you begin creating your build of Windows PE, you'll need to make some decisions. A key question you'll need to answer is who's in charge. Will this be a self-service reinstallation solution that non-technical users will execute, or will it be used by your technical or IT support staff?

This is a critical question, since it will dictate whether you'll have corporate branding on the user interface, whether you need to build protections in to keep users from running the installer accidentally, and many other issues. Here roaming user profiles or a separate user data partition for Documents and Settings can come in handy.

You'll also need to decide if you'll build in some help and support for your users, and whether the solution should run completely hands free.

Deployment and recovery solutions with Windows PE can be as simple or as highly engineered as your requirements deem necessary. I've seen some incredible solutions developed on this platform, including hidden partitions, getting build information from SQL Server or a network share, and mixing and matching PXE and CD/DVD boot mechanisms. The best part about Windows PE is the countless ways in which you can configure it to do your bidding.

Windows PE Q&A

Send your Windows PE questions to and I’ll answer them as time allows.

Q Doesn’t using Windows PE completely violate the NTFS security of Windows? Under Windows PE, the user runs all tasks as System, which is more powerful than local administrator.

A It turns out this really isn’t an issue. Law number 3 of the 10 Immutable Laws of Security says, "If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore.". The point is that if someone can physically access your computer, there are numerous other methods besides Windows PE (a parallel install of Windows, an NTFS-capable install of Linux or even Mac OS X, or physical removal of the drive to another system running Windows) to remove or potentially destroy your data. True, Windows PE makes this more convenient. To counter this threat—as well as Law number 3 as a whole—you should either physically secure your system at all times or use EFS to at least secure your data, or a full disk encryption product, which will secure your data and even your entire system volume. This is something you should be doing with your mobile systems anyway if they are storing any sort of confidential data.

Q Can I PXE-boot Windows PE from anything besides RIS?

A With the RAMDisk boot capability in Windows PE 2005, yes. I’ll show you how in an upcoming article.

Building Windows PE

Building Windows PE generally requires two things: Windows PE build tools and a matching set of Windows media. The rule of thumb is that Windows PE build tools require a copy of Windows from that build of Windows (same service pack and product family) or the one immediately preceding. So for Windows PE 1.5, the build tools will check for either Windows Server® 2003 RTM media (either the Standard or Enterprise Editions) or Windows XP Service Pack 2 (SP2) integrated media. Note that the WMI features in 1.5 require Windows XP SP2, and the RAMDisk and USB Flash Drive features in 1.6 require Windows Server 2003 SP1.

To create a build of Windows PE 1.6, then, you will want to have the 1.6 build tools as well as a copy of Windows Server 2003 SP1 integrated media. Launch a command prompt and go to the directory where you copied the Windows PE build tools. At the prompt, type the following (the last four arguments are optional):

mkimg.cmd [source] [destination] [ISO Image] [/PNP] [/WMI] [/NOWF] 

Let's say your Windows Server 2003 SP1 integrated media is on your D: drive; you want to build in C:\Staging and add WMI support; and you don't want to create an ISO image immediately. Enter the command

mkimg.cmd D:\ C:\Staging\ /WMI

and you'll end up with a CD-ready layout of Windows PE with WMI support in your

C:\Staging\ directory.

Now let's add HTA and WSH support. At the same command line, enter:

buildoptionalcomponents.vbs /S:D:\ /D:C:\Staging\ /HTA

You don't need to specify WSH; the script implicitly adds it because it's required by HTA. (You could also add ADO, but you don't need it for the samples here.) Once this build has completed, be sure to add the optional components installation command to the startnet.cmd file (the "autoexec.bat" of Windows PE, if you will—it's the file that automatically executes every time Windows PE boots after Win32 has started). Open the startnet.cmd file in Notepad (be careful not to execute it on your PC as it can cause an errant machine rename). To the bottom of startnet.cmd, add the line:


This batch file will install HTA and WSH support once Windows PE has booted.

Now you can add the sample HTA-based wizard that's available on the TechNet MagazineWeb site to your Windows PE image. Just download the ZIP file, open it, and copy all the files to your C:\Staging\I386\System32 directory. I've designed these scripts so that the most destructive parts are placeholders that show you what the command should be, but they don't really repartition, reformat, or reinstall anything. If you want the wizard to run automatically upon boot, add wizard1.bat after the OC.bat line. See Figure 3 and Figure 4 for a view of what the finished utility wizard looks like. This is merely a simplistic HTA example I'll build on in future articles, but the basics are here to allow you to begin a user-initiated setup procedure.

Figure 3 Windows PE Wizard

Figure 3** Windows PE Wizard **

Figure 4 Choosing a Task

Figure 4** Choosing a Task **

Once you have added the HTA files and any drivers or other files you want on your CD, you can easily create an ISO image by entering the command:

OSCDIMG -n – C:\Staging\ C:\Staging.ISO

Note that you must include the -n parameter in this command or the names of the WinSxS directory (containing Windows side-by-side assemblies) will be trimmed and basic elements of Windows PE, such as Notepad, will silently fail.

After you create the ISO, you can burn it to a blank CD or DVD. Remember that the CD-burning software built in to Windows XP won't work for this—you'll end up with a coaster with a copy of the ISO on it. You need either a third-party software package that will burn ISO images directly to media or use the freely available solution called ISO Recorder. You can download it at ISO Recorder.


When we first shipped Windows PE in 2001, I thought people would have to maintain it periodically to install new drivers. The ubiquity of IDE drives and standard 10/100 Ethernet meant that the driver set we shipped with Windows XP was huge. The set that shipped later with Windows Server 2003, while more refined (it dropped some NIC and storage controllers that are more consumer-focused), still covered most systems unless they had SCSI storage or gigabit or other high-end Ethernet. The proliferation of Serial ATA and Gigabit Ethernet (and other high-end storage and networking) means that adding drivers to Windows PE isn't something reserved for the datacenter build team anymore. Adding network controllers used to be quite complicated. Since Interim Windows PE, all that has changed, thanks to DRVInst.

To add a new driver now, all you do is run drvinst, specifying the class of drivers you want to install, the source, and the destination Windows PE install. To add all network drivers from any Windows CD that have not been included yet, run:

drvinst.exe /OSCD:D: /onlyclass:NET C:\staging

Adding the operator /q to this command will cause it to run without asking for any verification. Only network drivers (they have class=Net in their .inf files; most also have names that begin with "net*" but you can't count on that) are installed post-boot for Windows PE. If you want to add any other driver types, you can use drvinst to add them to your Windows PE image, but you'll also have to add the /PNP command when building Windows PE, or Windows PE won't initialize them.

Alas, mass-storage controllers aren't so easy. You either need to press F6 very early as Windows PE boots and specify a floppy disk that contains a txtsetup.oem file and the driver to use or use the following steps (specific to the Windows PE install we've been building) to add the driver. (Note that you can't use a USB Flash Drive or any other kind of media here.)

  1. Create a directory called Driver1 under C:\Staging\I386\System32.
  2. Copy the entire contents of the floppy disk/image provided by your vendor to the Driver1 directory. This is the best way to ensure you don't omit any DLL or other files required by the driver in order for it to load.
  3. Using Notepad, open C:\Staging\I386\system32\winpeoem.sif.
  4. Remove all semicolons from the [OEMDriverParams] section (three lines total).
  5. Add Driver1 to the OEMDriverDirs line. Do not include quotes, and if you need to repeat the first step for multiple drivers, add them here as well, separated by commas.

Note that you may have to edit the vendor's txtsetup.oem file to ensure the device you are trying to load is the one specified in the [Defaults] section of txtsetup.oem. Only one default can be specified.

Next Up

In my next article I'll take a look at two of Windows PE's boot options: RAMDisk boot and USB Flash Drive boot. I'll discuss their benefits and limitations and also see how they can help us build a more powerful deployment solution.

Windows PE Releases

Here are the five releases of Windows PE, along with the name used to refer to each and its new features.

  • Windows XP RTM (Windows PE). This version included PXE boot, CD boot, and a complicated boot from hard drive method that used the Windows Recovery Console as a bootstrap. You could build it from Windows XP Professional RTM media.
  • Windows XP SP1 (Windows PE 1.1). It supported standalone Distributed File System (DFS) roots, improved boot from hard drive technique. You could build from Windows XP SP1 media.
  • Windows Server 2003 RTM (Windows PE 1.2). This version could build from Windows XP SP1 or Windows Server 2003 (Standard or Enterprise Editions) media.
  • Windows XP SP2 (Windows PE 2004/Windows PE 1.5). This version had support for WMI, the ability to add additional classes of drivers, the ability to cause plug and play rescan after boot, and the Windows Firewall. It could build from Windows XP SP2 or Windows Server 2003 media.
  • Windows Server 2003 SP1 (Windows PE 2005/Windows PE 1.6). RAMDisk boot capability, USB Flash Drive boot capability, WMI, Drivers, PnP, Windows Firewall. It could build from Windows XP SP2 or Windows Server 2003 SP1 media (RAMDisk and UFD only supported with Windows Server 2003 SP1 Windows PE).

The last two releases became known as "Interim Windows PE" or simply iWinPE for short. They delivered a collection of features often requested by enterprise customers and OEM partners that simply could not wait for the arrival of Windows Vista.

Wes Miller is the Product Technology Strategist at Winternals Software in Austin, Texas, where he focuses on all Winternals products, including Protection Manager, the Winternals Enterprise Security product. Previously, Wes worked at Microsoft as a Program Manager and Product Manager for Windows enterprise deployment.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.