All rights reserved. No part of this document shall be reproduced, stored in a retrieval system, or transmitted by any means, electronic,

mechanical, photocopying, recording, or otherwise, without permission from 1E. No patent liability is assumed with respect to the use of the

information contained herein. Although every precaution has been taken in the preparation of this document, 1E and the authors assume no

responsibility for errors or omissions. Neither is liability assumed for damages resulting from the information contained herein. The 1E name is a

registered trademark of 1E in the UK, US and EC. The 1E logo is a registered trademark of 1E in the UK, EC and under the Madrid protocol.

NightWatchman is a registered trademark in the US and EU.

PXE LOT OR PXELITE THE LOWEST COST NETWORK BOOT SOLUTION

DAVE FULLER

1E

JANUARY 2011

ABSTRACT: Being able to boot PCs from the network is a must-have requirement for any zero-touch Operating

System deployment solution, especially where new (‘bare-metal’) machines are being delivered, or you need to

rebuild a broken PC that can’t otherwise boot up. We are convinced that the best solution for deploying Microsoft

Windows desktop operating systems is Microsoft System Center Configuration Manager. However, to achieve a

comprehensive zero-touch solution with System Center requires servers to host the Pre-Execution Environment (PXE)

service that enables booting from the network. This paper demonstrates how 1E’s PXELite solution eliminates the

need for these servers and the associated costs of managing them, providing the lowest cost PXE solution for all

distributed IT environments.

© 1E 2010 2

Contents

The need for Network Booting ......................................................................................................................................... 3

What is PXE? ..................................................................................................................................................................... 3

PXE in the real world ........................................................................................................................................................ 4

What is PXELite? ............................................................................................................................................................... 6

Operating System Deployment 101 .................................................................................................................................. 6

How PXELite works ........................................................................................................................................................... 8

Nomad Enterprise – content for the masses .................................................................................................................... 9

Resources........................................................................................................................................................................ 10

© 1E 2010 3

The need for Network Booting

You are no doubt already familiar with the concept that applications cannot be successfully updated on a PC while

they are running. Software updates nearly always involve updating executable code files that the application uses.

When an application is running, the executable code files are held in memory, so changing them on the disk while a

different version is in memory causes the application to become unstable. Some applications share files with other

applications, making the update process even more risky if any of those applications are running. When you attempt

to update such an application you will typically be prompted to close down the associated applications before

continuing.

Well, an Operating System is similar in that much of its executable code is in memory when it is being used, however

the problem of shared applications is much bigger as every application and process that runs on the PC uses some of

those files. So we need to close the Operating System down to get it out of memory so that we can copy all the files

from the new operating system to disk, then we can start the new Operating System back up again and load it into

memory. However, the Operating System provides all the core functions, most importantly the communication

between the network and the hard disk to enable the new Operating System files to be copied. If we close the

Operating System down, we lose the ability to copy the new Operating System files to disk. What we need is a

‘temporary’ Operating System that we can load into memory once the ‘real’ Operating System has been closed

down.

This is where Windows PE (Pre-installation Environment) comes in. Windows PE is a cut down version of Windows

that includes all the necessary components to install the new Operating System to a point where it can boot up and

finish the process itself. So how do we boot up a PC to Windows PE once we’ve shut down the ‘real’ Operating

System? We need some boot media.

In the old days we used floppy disks, now we use CDs, DVDs or USB drives. This boot media contains the Windows PE

Operating System (in the form of a WIM file) and a couple of extra ‘boot’ files that are required to load Windows PE

into memory. Once the Windows PE Operating System is loaded into memory, we can do what we want with the files

that are on the hard disk. We can back up user files, completely wipe the disk and then install the files required by

the new operating system. When we’re done, we simply remove our boot media and reboot the PC from the local

hard disk.

Great! Except this requires someone to insert or connect the boot media, reboot the machine to the chosen boot

device (CD, DVD, USB), wait for the WinPE process to finish then remove the boot media so the PC can boot to the

new Operating System. If you have 200 offices, each with 50 PCs to be upgraded to Windows 7, you are going to

need an engineer to babysit 10,000 boot-ups for around 10 minutes per PC. If an engineer costs $30 per hour you are

going to spend $50,000 just getting Windows PE loaded. We need to do this without physical boot media or devices

being connected. This is where PXE comes in.

What is PXE?

PXE (pronounced ‘pixie’) stands for Preboot-Execution Environment and is a standard that is included in PC hardware

to enable the PC to use the network as a boot device. The Windows PE Operating System image, along with the initial

boot files, is stored on a PXE Server. The process of booting a PC from a PXE Server is typically referred to as PXE

booting.

© 1E 2010 4

PXE booting is dependent on the Dynamic Host Configuration Protocol (DHCP). DHCP is commonly used in business

and home networks to dynamically allocate a unique IP addresses to each device that connects to the network.

When a PC starts up, it broadcasts a DHCP DISCOVER request on the local network, and a DHCP server will respond

with an IP address. When a PXE Server is installed on the network, it will also respond to each of these DHCP

DISCOVER requests with the IP address and name of the PXE Server, and also the name of the initial boot file that the

PC needs to download1.

Under normal circumstances the PC would boot up whatever Operating System is installed on the local hard drive;

the PXE client process would not be initiated and the response from the PXE server would be ignored. Typically, the

PXE client process is initiated by the user pressing the F12 key while the PC is starting up (before Windows starts to

load from the hard disk). This presents a ‘boot options’ menu and the user can select ‘Boot from network’ or a

similarly-named option. Alternatively the PC can be configured to always PXE boot first by configuring the order of

boot device options in the PC BIOS (this configuration is necessary to support true zero-touch deployment of an

Operating System to a bare-metal PC).

So, if the PXE client process has been initiated, and the PXE Server has responded to the client and provided its

identity and the name of the first boot file, the PXE client downloads that file into memory and executes it. This

program will typically prompt the user to confirm they want to continue with the PXE boot by pressing F12 again

(although this can also be automated for true zero-touch deployment) and then continue to download the other

boot files and the Windows PE image into memory and boot up Windows PE from memory. (If you’re interested, the

protocol that the client uses to download these files from the PXE Server is the Trivial File Transfer Protocol (TFTP).

At this point, the PC is running Windows PE in much the same way as if we had booted from a CD, DVD or USB drive,

except we didn’t have to have someone inserting CDs or plugging in USB drives. Although the PXE client boot process

typically requires someone to be present to press F12, the Operating System Deployment (OSD) feature of System

Center Configuration Manager 2007 allows even this minimal step to be fully automated. If you configure the PC to

always boot to the network first, and then use Configuration Manager to manage the PXE Server so that it only

responds if an administrator has specifically ‘advertised’ a boot image to that PC, you can implement a true zero-

touch deployment solution. If the PXE server doesn’t respond with a boot file, the PC will simply try the next boot

device in the list – typically the local hard disk.

PXE in the real world

So we have established that we can boot a PC with a ‘temporary’ operating system (Windows PE) in memory to

replace the operating system on the hard disk without any costly engineers going near it. But what does this actually

look like in the real world?

Well, the first step is to get some PXE Servers installed on the network. In the Microsoft System Center Configuration

Manager world, Microsoft Windows Deployment Server (WDS) is used to provide the PXE Server service. WDS is a

component of the Windows Server operating system, so you need servers running Windows Server 2003 or 2008 if

you want to use PXE. But just how many of these servers are you going to need?

1 For the purposes of this paper, the interaction between the client, the DHCP server and the PXE server have been

simplified.

© 1E 2010 5

We have already seen that the PXE Server responds to a DHCP DISCOVER request from the client. This DHCP request

is in the form of a broadcast from the client, so normally it will only be ‘heard’ by a DHCP or PXE Server within the

local network (or more accurately the local subnet)2. It would therefore be reasonable to conclude that a PXE Server

would be required in each subnet, if it weren’t for the existence of IP Helpers. In large environments comprising

many subnets, routers are configured with an IP Helper that allows these specific DHCP broadcasts3 to be forwarded

to other networks, allowing the DHCP Server (and PXE Server) to reside on a different subnet than the client PCs.

Figure 1 shows such a network configuration. The green lines represent the DHCP broadcast and the blue lines

represent the reposnse from the DHCP server. The red lines represent the PXE t traffic, which includes the Windows

PE boot image.

Subnet A

Subnet C

DHCP

Subnet A

Router with

IP Helper

PXE

Router with

IP Helper

Figure 1. DHCP broadcasts forwarded to subnet where DHCP & PXE server reside

So we don’t need a PXE Server at each location then. We can use IP helpers to communicate with the DHCP and PXE

servers back at the data center. Great! But we haven’t considered bandwidth. The communication between the

client and the PXE server is all quite trivial, right? Isn’t the protocol used to download the boot image from the PXE

server even named Trivial File Transfer Protocol. Well, a typical Windows PE boot image will be in the region of 150-

250MB, depending on the number of hardware models you need to support (and therefore the number of hardware

drivers you need to include in the boot image). Not so trivial after all, especially when you take into consideration the

available bandwidth. Consider the following scenario, which one of our customers was faced with.

A drilling company based in Houston has among the sites that it needs to manage around 60 off-shore drilling rigs,

which use expensive satellite communications for data. These links provide a bandwidth of 128Kb (128,000 bits) per

second. Their Windows PE boot image is around 150MB (1,258,291,200 bits). Assuming the links are fairly efficiently

used at around 50% capacity (you wouldn’t purchase significantly more satellite bandwidth than you required), on

average they will be squeezing 64,000 bits per second down to each rig. So the Windows PE boot image is going to

take around 19,660 seconds (2 weeks) to reach the client when it PXE boots. This is before the new operating system

2 For security and efficiency, under normal circumstances routers do not forward broadcast packets to other

networks, so the broadcast is contained within the local subnet. 3 DHCP broadcasts are sent from source port 68 to destination port 67, so they can be identified by the router and

handled in isolation from other broadcasts.

© 1E 2010 6

image (which is typically in excess of 4GB, or 30-50 times the size of the Windows PE image) has even started to be

downloaded to the local hard disk.

Clearly this is not practical. In some circumstances we are simply going to have to place PXE servers outside of the

datacenter, especially in environments with many remote branch offices or retail stores. But in the Microsoft

Operating System Deployment environment, this would require a server (specifically a computer running a Windows

Server Operating System) in each location to host the Windows Deployment Server service.

In many cases, these remote locations may already have a server or two in place, performing important roles such as

file and print sharing, Active Directory services, but they may not have the necessary capacity or resources (memory,

processor etc.) to manage the additional load of the Microsoft Windows Deployment Server role. In fact many of our

customers, with the help of progressive technology from Microsoft in the latest versions of Windows Server, are

trying to reduce the number of services that require servers at remote sites, rather than adding new ones. Servers

are more expensive to purchase than workstations, they usually require secure storage facilities (racks, cooling etc.),

they typically consume more energy and their operational costs are higher than workstations. If only the PXE Server

could be installed on a workstation we could provide local PXE service without the overhead of managing a server.

This is where 1E’s PXELite comes in.

What is PXELite?

PXELite is a lightweight PXE server that can be installed on a Windows XP, Vista or Windows 7 workstation and

provides the same PXE functionality required during an operating system deployment as the Microsoft Windows

Deployment Server. PXELite is part of the 1E Nomad Enterprise solution and the two are inextricably linked when it

comes to deploying Windows Operating Systems to PCs in remote offices.

In the same way that PXELite enables a workstation to host the Windows PE boot image on the local network

without requiring a server, Nomad Enterprise allows other content such as Windows Operating System images,

hardware device drivers, applications, and software updates to be distributed and cached on workstations in each

location without the need for servers to host this content.

Before we can properly understand how PXELite works, it is necessary to understand some of the basic concepts of

the Microsoft Operating System Deployment (OSD) feature in Configuration Manager.

Operating System Deployment 101

The deployment of a new OS is automated using a Task Sequence. Unambiguously named, a task sequence is a

sequence of tasks that need to be completed in order to achieve a fully operational PC. Figure 2 shows a sample Task

Sequence that includes formatting and partitioning the disk, applying the new Operating System (Windows 7),

applying drivers and configuring the OS for first use. The PC is then rebooted to the new OS and applications that

have been assigned to it are installed.

© 1E 2010 7

Figure 2. A sample task sequence

Administrators prepare one or more Task Sequences, according to the different configurations that may be required,

during the initial implementation of the OSD feature. These Task Sequences are then advertised to one or more

Collections of computers. In Configuration Manager an Advertisement is the mechanism to target a Task Sequence or

Program to a Collection. An Advertisement can be mandatory, in which case the Task Sequence or Program will start

without the user needing to do anything, or non-mandatory, requiring the user to manually initiate the Task

Sequence or Program from a list presented to the user.

A Collection defines the target PCs that the advertised Task Sequence is to run on. Often Collections used for OS

Deployment are static using direct membership, where an administrator adds specific PCs by name or MAC address

to the Collection and they stay there until an administrator removes them. However a greater level of automation is

available using dynamic, query-based Collections. For example, an administrator may create a Collection based on

criteria such as ‘All Windows XP PCs in Belfast”. Using inventory information gathered by Configuration Manager

from the PCs, machines that meet these criteria are automatically added to the Collection. Conversely, if a PC no

longer meets the criteria (for example it has been upgraded from XP to Windows 7) it will be automatically removed

from the Collection.

With these building blocks in place, an administrator can initiate an OS deployment either by adding a PC into the

appropriate direct membership Collection, or the OS deployment will be initiated automatically if the PC meets the

criteria of a pre-defined targeted Collection.

© 1E 2010 8

How PXELite works

PXELite has two core components

PXELite Local is the PXE server component that resides on a workstation in the same local network and

serves the Windows PE boot image to other PCs on the network when they PXE boot. For resilience, the

PXELite Local component can be installed on two or three PCs in each subnet.

PXELite Central is a single, central component that includes a web service and a SQL database that the

PXELite Local systems communicate with to determine if the PC that has PXE booted needs to be served a

boot image

There is also another component – NomadPackageLocator - that is used later on in the Operating System

Deployment process to get the OS image, drivers, applications and updates from the Nomad cache on other PCs on

the local network (more on this later).

When a PC PXE-boots and broadcasts the DHCP DISCOVER, the PXELite Local PC ‘hears’ this and queries the PXE

Central server, which in turn queries Configuration Manager, to determine if an there are any Task Sequences

advertised to that PC. If not, the PC will continue to boot from the hard disk.

If PXELite Central determines that there is a Task Sequence advertised to the PC that has PXE booted, PXELite Local

will respond with its name, IP address and the name of the boot file that the PXE-booting client needs to load first.

The PXE-booting PC then downloads the boot file into memory, which in turn downloads into memory the Windows

PE image from the PXELite Local PC and the Windows PE operating system is started.

Figure 3 shows the network traffic generated when PXELite is used. The green lines represent the DHCP broadcast

from the PC and the blue line represents the standard DHCP response to that. The difference between this and

Figure 1 is the PXE Server response (and subsequent download of the large Windows PE boot image) represented by

the red line is all on the local subnet. There is a small amount of communication across the WAN between the

PXELite Local and PXELite Central components (represented by the orange line), but this is trivial compared to the

boot image, which would otherwise have to come across the WAN.

© 1E 2010 9

Subnet A

Subnet C

PXELite

Central

PXELite

Local

Router with

IP Helper

DHCP

DHCP DISCOVER

DHCP response

PXE Server Response

PXELite Control

Figure 3. Local and WAN network traffic when using PXELite

So far we have focused on getting the Windows PE boot image to the PXE-booting PC without sending it across the WAN each time. We still have to get that boot image to the nominated PXELite Local PC(s), and we also need to make a whole load more content available to the PXE-booting PC to enable it to install the new OS along with all the necessary drivers, applications and updates. This content is often in excess of 10GB. We need a way to get all this content down to the local subnet, in a controlled manner so that it doesn’t clog up the network and prevent critical business data from getting through. We could locate a Configuration Manager Secondary Site with a Distribution Point – a server that hosts this content – in each branch office, retail store or oil rig. But we want to avoid the need for a server in each remote location, however we also need resilience – we can’t rely on one PC always being available.

This is where 1E’s Nomad Enterprise comes in.

Nomad Enterprise – content for the masses

Nomad Enterprise was mentioned earlier when we introduced PXELite. Nomad Enterprise has a number of features

designed to address the specific challenges we are faced with here.

It does not need to be installed on a server, and in fact is installed on each PC in the branch office / retail

store / oil rig to provide maximum resilience

Whenever a Nomad client requires any content, it initiates an election to dynamically determine where the

content should be obtained from. The election is in the form of a broadcast, so all other Nomad clients on

the local subnet ‘hear’ this and check their own cache to see if they have the requested content.

If any client has the content already cached, it will become the master and the requesting PC will download

the content from the master. (If several clients have the content cached, one of them will be elected as

master based on various weighting criteria)

© 1E 2010 10

If no available client on the subnet has the content cached, (or perhaps some clients only have the content

partially cached), a master will be elected (again based on the weighting criteria that includes the

percentage of the requested content already cached) and the elected master will start to download the

content from the Configuration Manager Distribution Point across the WAN

When downloading content across the WAN, the Nomad client regulates its own network bandwidth usage,

constantly working out what bandwidth it has available and ensuring it only uses a configurable percentage

of that

As the master downloads the content across the WAN from the Distribution Point into its cache, the other

clients that requested the same content simultaneously download the content from the master’s cache into

their own cache. This behavior provides excellent resilience, because if for any reason the elected master

gets disconnected or switched off, another election is initiated by the other participating clients and a new

master is elected (based on the client that has the most amount of content already cached) and they simply

resume the download from the point they had cached before the first master went down.

So using Nomad Enterprise, we can safely download the Windows PE boot image to the PXELite workstation, as well

as the new OS image along with the necessary drivers, applications and updates from the Configuration Manager DP

back in the datacenter without clogging up the network and without using any servers in the remote office. It will

take time – it’s not about getting it there quickly at this stage, it’s about getting it there at minimal cost. This pre-

staging of the content can be planned as part of your implementation project so the content is established before

you need to use it. In extreme cases, where bandwidth is so low that transferring the OS images across the WAN

would take months, it can be pre-staged using physical media, physically shipped to the remote sites. The PXELite

Local PC, which is also a Nomad client, only needs to host the Windows PE boot image, and the other content can be

cached on any other PC(s) in the subnet, but in practice we usually pre-stage all the content on the PXELite Local

PC(s) as these have usually been selected for their available capacity.

Now we have all the content in the local subnet, we can PXE-boot any PC in the subnet and complete the installation

of a new Operating System and have the user back up and running with minimal disruption. We have achieved this

without the need for servers in every office, and have protected the network to ensure business critical data is not

hindered.

Resources

For further information on the subjects covered in this paper, refer to the following resources.

Automating Windows 7 Deployments using System Center Configuration Manager (Microsoft TechNet

Webcasts)

o Part 3: Adding Windows 7 Packages – video demo showing how to set up the OS image packages

and PXE Service Point ready for a bare metal deployment

o Part 4: Deploying Windows 7 to Bare Metal – video demo showing the bare metal build process

Planning for PXE initiated Operating System Deployments (Microsoft System Center Configuration Manager

2007 on TechNet)