Deploying Windows XP, Using the Windows PE

By Marcin Policht (Send Email)
Posted Feb 15, 2008


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.

SWatch Reader Favorite! Life is filled with challenges for a sys admin rolling out a large-scale operating system install. Windows Preinstallation Environment, a stripped-down version of the OS designed specifically for deployment, simplifies the process.

Discuss this article in the ServerWatch discussion forum

Unsure About an Acronym or Term?
Search the ServerWatch Glossary
 

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 SUPPORT\TOOLS 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

Original date of publication, 06/01/2005

Page 1 of 2


Comment and Contribute

Your name/nickname

Your email

(Maximum characters: 1200). You have characters left.