PXE Lot or PXE Lite
2 likes1,645 views
1E's PXE Lite provides a cost-effective network booting solution for deploying Microsoft Windows operating systems without needing local servers. It simplifies the process by allowing PXE services on workstations, eliminating the costs and management overhead associated with traditional server setups. The solution also supports zero-touch deployments, making it efficient for large and distributed IT environments.
PXE Lot or PXE Lite
- 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