How 1E PXE Lite provides the lowest cost network booting solution. It eliminates the need for local servers and the associated costs of managing them.

1. PXE LOT OR PXE LITE
HOW 1E’S PXE LITE PROVIDES THE LOWEST COST NETWORK BOOTING SOLUTION. IT
ELIMINATES THE NEED FOR LOCAL SERVERS AND THE ASSOCIATED COSTS OF MANAGING
THEM.
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.
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 author s 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 Madr id protocol.
NightWatchman is a registered trademark in the US and EU.

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 2

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 3

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 4

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
2
local network (or more accurately the local subnet) . 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
3
many subnets, routers are configured with an IP Helper that allows these specific DHCP broadcasts 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.
DHCP PXE
Subnet C
Router with
IP Helper
Router with
IP Helper
Subnet A
Subnet A
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 5

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 6

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 7

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 that provides the interface
between the PXELite Local systems and the Configuration Manager database 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 8

9. PXELite
DHCP Central
Subnet C
DHCP DISCOVER
DHCP response
PXE Server Response
Router with PXELite Control
IP Helper PXELite
Local
Subnet A
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 9

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)
© 1E 2010 10