Deploying Windows XP, Using the Windows PE

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

At some point, nearly every system administrator in a large computing environment will be faced with the challenge of automating the setup of a new operating system. While an upgrade is typically an easier option to implement, it does not provide the same flexibility as a new installation and typically leaves systems vulnerable to issues inherited from legacy software and configuration options.

The benefits gained from an install make the effort worthwhile and allow the admin to considerably limit time spent setting up new computers and ensuring each of them is configured to the same set of standards. Fortunately, a significant part of the installation — dealing with core operating system and its main components — is well documented (DEPLOY.CAB file, included with the installation CD of every Windows version located in the SUPPORTTOOLS folder provides detailed information on deployment tools as well as “Guide to Unattended Setup” detailing Answer File parameters) and augmented by Microsoft (the same file contains the utilities Setup Manager and SYSPREP.EXE, which assist with the creation of answer files, creation of distribution share points, and cloning), which greatly simplifies its automation.

On the other hand, implementing two remaining stages in this process, one immediately preceding the operating system installation and one that follows it, require extra creativity and can vary greatly from one environment to another.

The next few articles of the “Deploying Windows XP” series will explore some of the more common ways of dealing with both of these stages, starting with the initial one.

Deployment Methods

In essence, there are two basic methods of deploying Windows on larger scale: scripted installation, which automates and customizes standard setup process using Windows source files and cloning (also known as imaging), during which a drive containing operating system installation is replicated and transferred to the hard drive on a target computer (this type of operation is made possible through use of such utilities as Ghost from Symantec, RapiDeploy from Altiris, ImageCast from Innovative Software, or TrueImage from Acronis). Source files or images can be located in one of three places:

Removable Media: Typically a CD-ROM, the system being installed must have the ability to boot either directly from this media or from another device (such as a floppy drive) and load necessary drivers to be able to access device where operating system source files reside.
Network Share: This is the most traditional and best documented method. A network link is used the distribute the files from the server for installation. This can be accomplished two ways: 1) by initiating connection from a client machine (by either booting from a removable media, such as a floppy or CD-ROM disk and loading necessary network adapter drivers and network protocols, or by using the network boot feature, present in overwhelming majority of systems produced today), or 2) by employing solutions, such as virtual floppy disk or Wake-on-LAN (which remotely trigger boot process on target computers using functionality provided in Advanced Configuration and Power Interface-compliant hardware and firmware).
Local Drive: This method typically involves cloning, but it obviously requires the image be first copied from its original location on removable media, network share, or via a direct link to another hard drive.

Each of these methods has benefits and drawbacks with respect to such features as hardware dependencies (introduced by need-to-load appropriate network adapters in case of network-based installation methods or incompatibilities between images required for different types of systems when using cloning), ease of maintenance (e.g., the ability to apply modifications), or time required to complete an installation. The issues with hardware support are probably most acute when dealing with network installations. The most traditional approach involves booting from an MS-DOS-based floppy disk, loading appropriate network adapter driver, connecting to a network share containing source files, and launching the setup (or image copy).

Unfortunately, unless all your computers have identical hardware, to implement these few simple steps you must develop a mechanism for customizing floppy disk content to match every network card on the systems to be deployed (and, potentially, provide support for mass-storage devices, whenever required). This can be a challenging task considering you not only have to locate necessary 16-bit drivers (the availability of which might be limited), but also must fit them on a floppy disk.

You can, however, use a Windows 98-based bootable CD, which practically removes media-size restriction. Another network-based installation method that became available starting with Windows 2000 is to use Remote Installation Services (RIS). In this case, a connection to a RIS server where operating system images are stored is established by booting from Preboot Execution Environment (PXE) capable hardware and firmware (network adapters and BIOS) or from a floppy disk created with Floppy Disk Generator (one of the utilities included with RIS installation), which loads appropriate network card drivers.

As the result, a designated image is loaded from the RIS server and executed on the local computer (launching the boot process and starting installation). However, although PXE technology is available on the majority of newer computers, older systems are unlikely to support it. Similarly, Floppy Disk Generator has limited selection of available network card models (which, in addition, is not updatable). Furthermore, the solution works only in environments that have implemented an Active Directory infrastructure with DHCP-based IP addressing.

Enter WinPE

Fortunately, the majority of the issues described above can be resolved by employing a technology called Preinstallation Environment (or simply Windows PE or WinPE), which Microsoft has recently made available. It is a stripped-down version of the Windows operating system designed specifically for deployment scenarios.

Windows PE includes built-in features intended to prevent its use as a client operating system (and thus ward off licensing violations), such as forced reboot after 24 hours of uptime and a significantly limited feature set (which also resulted in faster and more compact code). In particular, Microsoft decided not to include a number of programming interfaces, such as the Active Directory Services Interface, DirectX, and OpenGL. Missing also is support for applications developed with the .NET Framework or 16-bit code relying on the WOW32 subsystem.

This is because the standard version of WinPE is implemented in 32-bit code based on the Windows XP Professional kernel (although there is also a 64-bit Itanium version) and as such, it natively supports only 32-bit programs. On the other hand, this also means it works with the same set of network and mass storage device drivers as its full-featured counterpart, which eliminates the need for the lengthy process of updating bootable media to connect to a server containing installation source files or to access a local hard drive, as it is the case with floppy-based installations. Note, however, that some modifications might be needed when dealing with hardware that requires vendor-specific drivers.

Connectivity must be established via TCP/IP and is limited to outgoing connections only (resource sharing is disabled).

WinPE is part of the Microsoft Windows XP OEM Preinstallation Kit (OPK), which, besides the WindPE CD, includes a number of supplemental utilities, including Setup Manager and System Preparation Tool (these are full-featured versions, considerably more enhanced than their counterparts located in the DEPLOY.CAB file included with the retail Windows products). They enable the full automation of the process of installing Windows 2000, 2003, and XP. You can use the original CD to load the operating system, connect to a network share containing Windows XP, 2000, or 2003, and launch their installation. However, to fully realize the power and flexibility of Windows PE, you must customize its content.

The initial steps required to accomplish this are described in the Microsoft Knowledge Base article How to create a custom startup WinPE CD-ROM in Windows XP and involve copying WinPE source files to a local folder, placing Windows XP Professional (or Windows 2003 Server) CD in a CD-ROM drive, and running the MKIMG batch file (included with WinPE) with parameters, which designate their paths. The resulting files are stored in the same location as the original copy of WinPE (it is also possible to generate an ISO image that can be used to burn a custom-bootable CD). If you intend to further modify WinPE by adding any type of 32-bit utilities, batch files, or scripts, you must store them in the same location. At that point, you will probably also want to enable support for Windows Script Host, Windows Management Instrumentation, ActiveX Data Objects, or HTML Applications by running the BuildOptionalComponents.vbs script included with WinPE.

To take advantage of additional software and scripting capabilities, modify the content of STARTNET.CMD (since this is the first batch file that is loaded when the WinPE operating system starts). This file invokes other batch files, scripts, and utilities. For example, FACTORY.EXE is responsible for plug-and-play enumeration and configuration of networking settings, which, in turn, rely on values stored in the WinBOM.ini file (alternatively, network settings can be managed with the NETCFG utility). Other common changes include adding or removing network adapter and mass storage controller drivers.

For more detailed information on these (and other) WinPE utilities, refer to the “Windows Preinstallation Environment User’s Guide,” which is in the WinPE.chm help file stored in the Docs folder on the original installation CD).

Once all customizations are completed, you must execute OSCDIMG.EXE utility, which generates a new ISO image (providing the source for another bootable CD). Following this procedure, you can perform unattended installation of an operating system using Windows PE in one of three ways:

Booting from a Windows PE CD (or DVD) which contains a copy of the operating system source files.
This method has one major drawback, which is in the area of change management. Practically every modification to the installation process forces you to replace existing source media with new ones, making version control difficult and time consuming. It is, however, the only option that can be used with stand-alone systems or the ones on the remote end of a slow network link (although it is also possible to use a variation of this method, involving a USB or FireWire-attached external bootable hard drive).
Booting from a Windows PE CD and connecting to a network share where target operating system files are stored.
This approach eliminates issues inherent to the one listed above, since majority of changes can be made on the server containing operating system files (and other custom components) while the boot media can remain the same. In addition, you are not limited to the capacity of a single CD (although if your computers have bootable DVD drives, this is probably not a relevant factor). On the other hand, this method is not suitable for stand-alone computers or systems in remote locations connected via slow WAN links.
Using PXE functionality to connect to a RIS server containing a WinPE-based image.
This provides a superior degree of automation and ease of maintenance, since installation can be triggered by simply rebooting a target computer (which can be done remotely, providing that Wake-on-LAN functionality is supported), and all files are stored on an installation server, where they can be easily modified. On the other hand, this solution is subject to the previously discussed limitations inherent to Remote Installation Services, such as dependencies on Active Directory infrastructure and PXE-compliant network adapters. It, too, cannot be used to install an operating system on stand-alone computers.

Regardless of which approach is taken, the installation process is significantly improved compared with solutions discussed earlier. This results in the following changes:

Significantly increased bootable media size (in the case of network-based installation) removes the capacity limit of a floppy disk (the downside, however, is WinPE cannot be used on systems that do not boot from CD-ROM drives).
Increased installation speed renders MS-DOS-based installations slower due to a number of factors, such as a 16-bit execution environment, the need for additional reboots, and use of WINNT.EXE (instead of WINNT32.EXE) for launching Windows installation.
Hardware support is inherent, as Windows PE and Windows XP use the same set of network adapter and mass storage device drivers. This means that the need to include additional drivers should be relatively rare.
Enhanced scripting capabilities are available in addition to the out-of-the-box capability to process standard Windows batch files (and some of Windows XP utilities, such as DISKPART, which allows you to automate disk management tasks). Windows PE can be configured (as mentioned earlier) to support WSH (Windows Scripting Host), WMI (Windows Management Instrumentation), and ADO (ActiveX Data Objects) object models as well as HTA (HTML Applications) functionality.

Unfortunately, Windows PE has one major drawback. It is available only through Microsoft Authorized Distributors — although it is provided by default to Enterprise Agreement (EA) and Software Assurance Membership (SAM) customers. Licensing for it is also included in the Operating System Deployment Feature Pack, which in turn is free of charge for current Microsoft Systems Management Server users. For more information on licensing requirements of WinPE, refer to the Volume Licensing section of the Microsoft Web site.

Original date of publication, 06/01/2005

This article was first published on ServerWatch.com.