Windows Vista

Getting Ready for Windows PE 2.0

Wes Miller

At a Glance:

• Microsoft Windows Imaging technology
• Driver updates and servicing
• Unattended setup customization

In the last two issues of TechNet Magazine, I discussed the history of the Windows Preinstallation Environment (or Windows PE), covering various design decisions, and how you can use Windows® PE today. In this article, I am going to focus on Windows PE 2.0, which is the version that will ship simultaneously with Windows Vista™. This is not an in-depth look at how to use the individual features. Instead, this article aims to provide an overview of the new features and capabilities you'll find in Windows PE 2.0. While I'll give you some hands-on information, detailed discussions about how to use Windows PE 2.0 will come in future articles.

As work began on Windows Vista, the Windows setup team (which I was a member of at the time) was focused primarily on building an entirely new setup architecture, creating a new imaging tool to help with deployment, and designing a replacement for Remote Installation Services (RIS). But then our attention shifted to the interim Windows PE and Windows XP Service Pack 2 (SP2) and then to Windows Server® 2003 SP1. This meant holding off on our development efforts for Windows PE in Windows Vista for a bit. But the interim Windows PE update allowed us to deliver some of the functionality we had originally planned to include in the Windows PE 2.0 release, so our efforts had not been completely sidetracked.

The Windows PE team focused pretty intensely on the sustainability and the typical use cases of the Windows PE user when defining the new features we wanted to include (see the "New to Windows PE 2.0" sidebar). Let's drill into the key new features.

Working with Images

There are some basic concepts you must understand regarding Microsoft® Windows Imaging (WIM) technology and Windows Deployment Services. WIM was designed from the ground up to be used for deploying Windows as images (historically referred to as Sysprep images). Rather than being sector-based, as most imaging tools are, WIM is file-based. This means that instead of replicating every single sector of a hard disk, WIM picks up each file and the metadata associated with it (access control lists, short and long file names, and so on) and stores the data in a single file.

One of the key benefits of WIM images is that a single WIM file can store a copy of more than one volume (each is referred to as a volume image). And regardless of how many are captured, each single file is only stored once. This is referred to as Single Instancing. In function, the technique is similar to that used by Remote Installation Services, though the technology used is very different. The tool for creating WIM images is called ImageX. (Note that it had been referred to as XImage at one point, but the name has since changed.)

As we were developing Windows Vista and its new image-based setup engine (which would use Windows PE to deploy the operating system), we saw that we might be able to use some tricks in order to save space on the media. At the time, we were not sure whether Windows Vista would be shipping on CD or DVD and therefore we were driven to minimize the disk space taken up by the setup itself. Since the version of all of the files comprising Windows PE on the CD was identical to the files in the WIM file sitting right next to it, we started to think about including Windows PE in the WIM file itself and booting from it. Thanks to some impressive work done by an architect on the Windows Core operating system team, our idea became a series of prototypes and was integrated into the product before the Developer Preview of "Longhorn" (now Windows Vista) released at the Professional Developers Conference in 2003. Today, Windows PE lives in one WIM file on the media (boot.wim), and the installation media exists in another (install.wim). Though the single instancing between Windows PE and Windows that we had originally envisioned isn't a part of the install media any longer, Windows PE still benefits from the reduced space it gains by being compressed on disc. With the integration of the RAMDisk boot functionality delivered in Windows PE 1.6, the ability to swap media (to remove the initial boot CD/DVD after boot-up is complete) was also added since the early WIM boot work was completed.

Including a Windows PE image in a WIM is as easy as using ImageX to pick up the files (I'll discuss this in detail in an upcoming article) and denoting the image as bootable by providing the /boot flag to ImageX. Think of this as the boot sector. When the Windows Boot Manager loads the WIM file, the marker included with the /boot flag states which image (whether there is one or more than one) in the WIM file is bootable. Note that only Windows PE can boot from a WIM file. You can't boot all of Windows Vista from a WIM. The WIM is also, as in the case of a CD or DVD, read-only. Thus, you can't boot from a WIM image of Windows PE and modify any of the files. To make any changes to Windows PE, you must modify the WIM itself.

Dealing with Drivers

With Windows PE, we've always paid attention to mass storage and networking device support. Yet there were still occasions when Windows PE lacked support for certain devices on new systems. Windows PE 1.5 included some improved support for adding device drivers, but Windows PE 2.0 further streamlines this ability. All types of devices are now supported and they just work on boot—no factory.exe or drvinst.exe magic is necessary. To add a new device driver to Windows PE 2.0, simply run the new peimg.exe tool and it will add the drivers. The syntax, shown here, is simple:

peimg.exe /inf drivername.inf builddirectory\Windows

Just replace drivername with the name of the .inf (wildcards, like net*.inf, are acceptable) and replace builddirectory with the name of the directory where your Windows PE image is being built.

Scratch Space

A problem often faced by applications running under Windows PE is that many Windows applications (and even many components of Windows itself) expect to be run on writable storage. Many react in unpleasant ways when running from read-only media, such as a CD-R. For example, when I first tried getting Microsoft Internet Explorer® to run under Windows PE (and eventually when I tried just the MSHTA, or Microsoft HTML Application, components of Windows), key DLLs would not register because they required writable storage for some of the tasks they needed to complete as part of the registration process.

In Windows PE 2.0, this is not a problem since there is now up to 32MB of scratch space available for file system writes. As a result, components that previously didn't work due to the read-only nature of Windows PE will now work since they can perform the writes to disk that they require. This is different from a RAMDrive for scratch space (as has routinely been utilized by Windows PE users) in that the scratch space is on the same volume as the boot volume—as opposed to being another temporary drive.

Optional Components

As with previous versions of Windows PE, the new version provides optional components that can be used to add more functionality. (Of course, these add size, which is why they are optional.) Support for Windows Script Host (WSH), Windows Management Instrumentation (WMI), and MSHTA is still available. You can now add support for MSXML, the Windows Vista Recovery Environment, additional Windows fonts, and formal Microsoft Data Access Components (MDAC), which replaces the earlier ADO for SQL support that included some, but not all, MDAC support). The most important change here, though, is how easily these components can be added. Instead of being implemented via a rough WSH script, the components can be easily added or removed using peimg.exe—the same tool I discussed earlier used for adding drivers.

Language Packs

One of the original key tenets of Windows Vista was to take the concept of the Multilanguage User Interface (MUI)—a concept that was introduced in Windows 2000 and improved upon in Windows XP—and implement it throughout the operating system. In Windows 2000 and Windows XP, you can specify a language other than English but MUI itself relies on the English version of the operating system to begin with. That is, you can have any other language you want, as long as English is there as well.

That has changed in Windows Vista. While I won't drill into all the specifics, I must note that this change is significant for Windows PE. There was no formal support for MUI under earlier versions of Windows PE. You had to build from the localized language of Windows that you wanted language support for. Now, adding or changing language support works in the same way as with any other optional component—using peimg.exe to add or remove language packs to meet your specific Windows PE needs.

Better Servicing

Earlier versions of Windows PE also lacked support for servicing. To add a service pack, you had to rebuild Windows PE entirely. To add a hotfix, you had to improvise it manually—if you dared to. Given the fact that Windows PE was small, included limited Windows functionality, and didn't run for an extended period of time, we didn't see this as a problem. That is, not until the infamous Blaster vulnerability. Since remote procedure call was included in Windows PE, under the right circumstances the vulnerability could hit and cause Windows PE to continuously reboot.

This is what led us to include the Windows Firewall in Windows PE 1.5. And after that, the team set out to ensure that future versions of Windows PE could be serviced just like a full release of Windows. One key area of focus for Windows Vista was improved serviceability. Windows PE inherits from this. And like with its other optional components and languages, Windows PE uses peimg.exe to perform updates. Updates will be provided via the Windows Download Center.

Unattended File Support

You may be familiar with winbom.ini, which was used in earlier versions of Windows PE to drive a small application called factory.exe. These have been replaced in the new version. There is now a new XML infrastructure that you use to customize Windows PE (this is the same XML mechanism used for unattended setup in Windows Vista) and a new application named wpeinit.exe.

Wpeinit.exe uses the standard unattend.xml format in Windows Vista to specify Windows PE customizations and actions. Figure 1 shows a sample unattend.xml file that could be used to customize Windows PE. The format for the unattend.xml file is documented as a part of the Windows OEM Preinstallation Kit (OPK) and Windows Automated Installation Kit (WAIK), which I will discuss in a moment.

Figure 1 Architecture of an unattend.xml File

<ComputerName>MyWinPEMachine</ComputerName>

<Restart>Shutdown</Restart>

<RunSynchronous>

<RunSynchronousCommand>   
	  <Order>1</Order> 
	  <Path>notepad.exe</Path> 
</RunSynchronousCommand>

<RunSynchronousCommand>
	<Order>2</Order>
	<Path>cmd.exe</Path>
</RunSynchronousCommand>

</RunSynchronous>

<EnableFirewall>true</EnableFirewall>

<PageFile>
	<Size>1000</Size> 
	<Path>C:\pagefile.sys</Path> 
</PageFile>

<LogPath>C:\mylog.txt</LogPath>

Windows Deployment Services

As I mentioned earlier, one of our main goals was improving network-based setup by moving to a unified infrastructure whether setup was started from CD, DVD, or the network. Unfortunately, there is quite a bit of extra work that goes on during setup when performing an RIS-based installation of Windows. We wanted to remove that complexity and redundancy as much as possible and in order to do that, we built Windows Deployment Services.

Like RIS, Windows Deployment Services is a PXE-based installation. But unlike RIS, it starts Windows PE over the network and utilizes the same image-based setup infrastructure as a normal CD or DVD-based setup, while providing the same type of centralized enterprise installation infrastructure that RIS has delivered since Windows 2000. There's a lot to discuss about WIM and Windows Deployment Services and not enough room in this article. But don't worry, I'll look at these in more depth in an upcoming article—so stay tuned!

Using WAIK

At this point, you may be wondering just how you can get started with Windows PE 2.0. The first step is to get the WAIK. Earlier versions of Windows PE shipped as a part of the Windows OPK or as a part of Software Assurance media. Since Windows PE 2.0 is scheduled to be available for all licensed Windows customers, Microsoft has created WAIK for non OEM customers.

WAIK provides all of the Windows PE build tools needed to create your own copy of Windows PE 2.0. You can currently obtain WAIK as a part of the Windows Business Desktop Deployment (BDD) 2007 beta. In addition to WAIK, the BDD provides guidance on how to use WAIK and its tools. Of course, it goes without saying that the best way to really become familiar with Windows PE 2.0 and all of the other new setup and deployment technologies included in Windows Vista is to start experimenting with them as soon as you can.

New to Windows PE 2.0

Windows PE 2.0 includes all the features found in Windows PE 1.6 and adds a number of new capabilities and components, including:

• Booting from within a Microsoft Windows Imaging (WIM) image
• Driver injection and real-time Plug and Play Support
• Writable scratch space (even when booted from CD)
• Easily added optional components—Microsoft Core Extensible Markup Language Services, Windows Recovery Environment, Microsoft Data Access Components
• Language Packs
• Unattended file support
• Improved tools for building and updating Windows PE

Wes Miller is a Development Manager at Pluck (www.pluck.com) in Austin, Texas. Previously, Wes worked at Winternals Software in Austin, and at Microsoft as a Program Manager and Product Manager for Windows. Wes can be reached at technet@getwired.com.

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