Howto Pxeboot


Published on

Published in: Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Howto Pxeboot

  1. 1. Converting old computers into thin clients In a network with Microsoft servers Or How-to Implement a pxe based boot thinclient deployment in a MS dominated environment. Benny Keshet David de Leeuw Medical Computing Unit Ben Gurion University of the Negev February 2005
  2. 2. Introduction We at the Faculty of Health Sciences at Ben Gurion University needed to deploy a set of 30 classroom computers to function as quot;thin clientsquot; to a MS Windows 2003 Terminal Server. We choose this solution because we - had the quot;oldquot; computers stations available, and not the funds to buy a brand new classroom - need to save on maintenance, especially manpower - wanted flexibility and speed on rolling out new programs: installing programs once (on the server) We wanted to use our old classroom hardware - Pentium III, 64MB RAM computers and we needed to retain use of floppy disk, CD-Rom and disk-on-key USB devices. All network cards were Intel pro 100ve. Our server infrastructure included - MS based RIS Server and DHCP server - Active Directory servers - Terminal server for the classroom applications To prepare the thin clients software we used a: - Fedora Core 3 server All our network is on - 100 Mb/s TCP/IP switched networking The free software we applied : - PXES software - Etherboot software a. How does this work: Before going into details what is needed to run quot;thin clientsquot; computers on our network, we will give a short background on the process.
  3. 3. a. Instead of running applications on the local computer, we are running them on a quot;terminal serverquot;. As with any project the quot;user experiencequot; should not be hurt, so the server should be able to serve 30 or more client stations in real time. Our present system is a dual 2.8 GHz Xeon system with 3 GB RAM. This is adequate for our purpose. Do not try to establish such a set up with an overloaded system, if you don't want to have the angry clients chasing after you. b. The workstation running the thinclient software doesn't need any operating system on its local disk. In fact, there is no need for a local disk at all. All the operations are network based. c. The component of the local computer that is all important is the network card (quot;NICquot;). This network card comes into action on boot of the computer. As a first step it identifies itself with its MAC address, gets an IP from the DHCP server, and applies to the Active Directory quot;prestaging processquot;. Here the computer system is identified according to the computer quot;GUIDquot;. This GUID, a 32 digit number is in newer and brand name computers provided by the BIOS. If the BIOS does not provide a GUID the MAC Address of the network card will be used. d. When the Active Directory quot;recognizesquot; the pre-staged computer it will provide a boot program specifically adapted to the network card. This program starts running at the local computer (in fact boots it) e. Now the boot turns to the DHCP Server, and besides the IP gets the name of a file, which is in fact a quot;condensedquot; linux operating system. This file, an quot;nbiquot;=quot;network based imagequot; is downloaded to the computer and expanded, and the computer quot;rebootsquot; according to the operating system in the file. So the station boots into Linux. During the boot it checks out details such a the hardware available etc. At the end of the boot a program can be run, such as quot;remote desktopquot; to access Windows servers, VNC or other applications. f. Once the boot is complete, we get the login to the remote server. Here we could run quot;remote desktopquot; or Citrix ICA, or VNC or a whole range of other packages.
  4. 4. b. Setting up the Microsoft infrastructure: Setting up the basic MS services is reviewed extensively elsewhere so I will only cover the modification needed for the deployment of pxe thinclients. A. Modifying the DHCP server One needs to define two entries to the DHCP User Classes Open DHCP.mmc right click relevant DHCP server select “Set Predefined Options…” In the resulting window Add: Option 66: Class: Global Name: Boot Server Host Name Data: String Code: 66 Description: TFTP boot server host name Then click OK finish
  5. 5. Option 67: Class: Global Name: Bootfile Name Data: String Code: 67 Description: Bootfile Name B. Modifying the RIS serveri ii Create a PXES directory structure. The exact structure is not that important. The RIS Server TFTP server’s root starts at the RIS server’s root folder. Ex. We installed our RIS to use D:RemoteInstall as it’s root. Folder structure is ‘D:Remoteinstall’ this is the TFTP root “” Setup OSChooser admin We created a folder SetupEnglishPXEBootPXETS – for the pxes boot images and SetupEnglishPXEBootBootROMs – for the EPROM boot images (see below).
  6. 6. Remark: The advantage to this folder structure is that it makes it easy to add the same pxe boot images to the regular RIS menu (using F12 network boot) just by adding a .sif file. IMHO it is also tidier. c. Creating PXE Boot images. We decided after much trial and error to use PXES created by Diego Torres Milano, version 0.9. This is an open source tool located at We encountered a number of problems installing this tool but the results were well worth the effort. A. Installing the pxesconfig tool: Platform: We installed the tool on a fedora core 3 server. The installation on this platform involves a number of dependency issues. First we want to install pxes-base-i586-0.9-1.i386.rpm dependencies: dhcp-3.0pl1-23.i386.rpm tftp-server-0.32-4.i386.rpm (can be downloaded as and then pxes-base-i586-0.9-1.i386.rpm Now we want to install pxesconfig-0.9-1.noarch.rpm dependencies (in this order): tcp_wrappers-7.6-37.2.i386.rpm ORBit-0.5.17-14.i386.rpm libpng10-1.0.18-1.fc3.i386.rpm gnome-libs- Glade-Perl-0.60-1.noarch.rpm can be downloaded as libglade-0.17-15.i386.rpm libxml-1.8.17-9.i386.rpm
  7. 7. gtkglarea-1.2.2-19.i386.rpm Gtk-Perl-0.7008-31.i386.rpm mknbi-1.2-6.noarch.rpm can be downloaded as and finally pxesconfig-0.9-1.noarch.rpm we then need to add a line to /etc/fstab /tmp/pxes.initrd /tmp/pxes ext2 loop.noauto,user,owner 0 0 Now the basic installation is done, but there are a number of bugs that need to be fixed. BUG A. Support for USB flash devices This bug means that even when “USB flash” is checked in the local resource screen – it does not function in the image. To fix this, edit /usr/lib/perl5/site_perl/5.8.5/Pxesconfig/ (This file appears in number of places – we fixed all of them, but this seems to be the one that matters – but this might vary from system to system) Line 828 $form->{checkbuttonOLDEnableUSBFlashDisk}->set_active($hd); Should be $form->{checkbuttonOLDEnableUSBFlashDisk}->set_active($ud); BUG B. smbpasswd syntax change from version 2.x to version 3.x This prevents pxesconfig from setting root password in image. This bug appeared on platforms with samba 3.x installed. See for full patch.
  8. 8. We worked around this by replacing our installed version of smbpasswd (from version 3.0.x) to a compiled smbpasswd from version 2.x. This works for us since we use winbind for authentication and don’t need the version 3 smbpasswd. But we could easily have created a script for pxesconfig to change this on the fly. (The replacement file can be downloaded as BUG C. mke2fs syntax change in fedora code 3 from core 2 See atid=443713 for full patch. Also here we just worked around it by using mke2fs from Linux Redhat 9 (Also this replacement file can be downloaded as Bug D. Pressing Left Alt key causes client to send Meta key As a result of this, pressing Alt+shift to change language in the RDP client causes windows server to perform an Alt Lock. The source of this problem is X11 keymaping that maps ALT_L to Meta_L. This is defined for pxes X11 in two files: /opt/pxes-0.9/stock/dist/etc/X11/XF86Config.tpl (XFree86 3.3.6) /opt/pxes-0.9/stock/dist/etc/X11/XF86Config-4.tpl (XFree66 4.x) Just replace all reference to Meta_L with Alt_L and save files. Recompile nbi image (initializing ram disk). Thanks to Gal Goldschmidt and his article at for leading the way to the solution B. Running the pxesconfig tool: After all this pxesconfig runs smoothly and we have to do is create the pxe boot images. Usage of the pxesconfig tool is documented elsewhere; here are just a few notes on images for connection to windows 2003 servers: 1. In the second screen – select “Network bootable image” deselect others.
  9. 9. 2 .In “Optional Local Devices” – select “uses samba to share local devices” and select all local devices you wish to share. 3. In “Session Selection” select “Microsoft Terminal Server…” 4. In “X Windows” our experience is that XFree86 4.3.0 works the best. 5. Fill the other screens as suitable (based on hardware requirements). Usually apply quot;detect automaticallyquot; 6. In “General Configuration” set root password if you intend to access local devices. The image is created by default in /tftpboot/pxes as a .nbi file. One needs to copy this file (only this one is really needed) to the RIS server tftp folder (in our case SetupEnglishPXEBootPXETSTServerA.nbi) Take note of the exact path and file name for later. We are now ready to setup specific stations to boot from pxes. d. Preparing stations to boot from PXE. We now need to pre-stage and deploy the stations. First we need to check the computer BIOS and NIC hardware that it supports booting from the network. Documentation about this available at A. Preparing and Checking Hardware: For our Intel NICs we updated the NIC’s BIOS with the latest Intel Boot Agent. (see The machine BIOS was configured to boot from network. Different NIC cards need different settings. We used to download the appropriate EPROM images. The EPROM image should be saved as PXE bootstrap loader format (.zpxe) on your tftp server (in our case these were saved in SetupEnglishPXEBootBootROMs on the RIS Server). Ex. For the Intel 100 Pro-ve NIC we downloaded a file “eepro100-1032 0x8086,0x1032 Intel PRO/100 VE Network Connection” and named it eppro100ve.zpxe Identifying the exact properties of the hardware can be helped a lot by a small utility called pci.exe created and maintained by Craig Hart (can be downloaded at .
  10. 10. B. Pre-staging the workstations. iii In order to have the stations boot automatically we need to define these stations in the active directory in such a way that they will know which EPROM to boot with. This process is called Pre-staging. Its significance in the Microsoft world is related to RIS installations. Computers once deployed with RIS will already be pre-staged. If the computers have not yet been deployed using RIS we can manually pre-stage them. ADSI Edit snap-in: If you installed windows 2003 support tools: Start RUN adsiedit.msc OK. Or create an mmc snap in console to ADSI Edit snap-in: Start RUN mmc file add-remove snap in … add ADSI Edit Add Close OK. Right click “ADSI EDIT” connect to… type in your domain. File Save enter name for mmc Globally Unique Identifier (GUID) For computers starting from a RIS boot disk, the GUID is the MAC address of the network adapter, padded with leading enough zeroes to ensure that the GUID is 32 characters in length. It is in the following form: e. g. {00000000-0000-0000-0000-00A2B38A7D07} For computers booting with a motherboard embedded PXE capable network card or computers from brand name companies (e.g. IBM, DELL, COMPAQ), the GUID is a string of 32 characters that can be found in the motherboard’s BIOS, label on the side of the computer case, or within the computer case. e. g. {921FB874-DE23-11B9-CD2E-BD0023F23198} The GUID can be seen when booting at the station – when the DHCP Server returns an IP address. See also: Pre-stage Method A: Stage 1: Create new Computer object in the “Active Directory Users and Computers” mmc , on the second screen of the wizard you will be prompted to enter a GUID/UUID.
  11. 11. Stage 2: Continue as in Method B - Stage 2 Pre-stage Method B: Stage 1: If your computer object already exists, but is not pre-staged, Open you ADSI Edit Navigate to the computer object right click, properties.
  12. 12. Find key “netbootGUID” double click to edit it enter the GUID as hexadecimal couplets separated by a space (00 00 00 …).
  13. 13. Stage 2: find the key “netbootMachineFilePath” edit it to reflect the location of the EPROM pxeboot strap image Ex. ‘SetupHebrewPXEBootBootROMseepro100.zpxe’ Replicate your AD The station should now boot using the EPROM image. But we have not finished – we now need to send the station to the appropriate pxe boot image. C. Referring station to PXE Boot image Open up the DHCP mmc snap-in. Remark: If all the computers will boot to the same image you can set the scope options as below and you won’t need to create specific reservations.
  14. 14. Create a reservation for the each thinclient. Enter the IP, Enter MAC address, Enter name. Save, and right click reservation configure options… go to “Advanced” tab find, edit and save option 066 – enter IP Address of RIS Server (or tftp server) option 067 – enter path to pxe boot image, ex. ‘SetupEnglishPXEBootPXETSTServerA.nbi’ Now reboot your stations – they should now boot with the pxe image and start a rdp session with the server of your choice! D. Mapping When all is set up and we finally log in, we wish to access our local devices: floppy disk, cdrom and USB disk. (Who needs the hard disk ?)
  15. 15. This is attained via device mapping. It is most practical to take care of these issues in a login script on the server. For this we need to know: - the client station name. We could simply use the environmental variable: %clientname% - the names of the devices: these are called cdrom, fd, flash - a username and password allowed to access the local devices. When we prepared the NBI file, we put in the account root, with a password, f.e. quot;3456quot;. So the script looks like: net use g: /delete net use h: /delete net use j: /delete net use g: %clientname%cdrom 3456 /user:root net use h: %clientname%fd 3456 /user:root net use j: %clientname%flash 3456 /user:root The user will see the devices under the list of network devices and not the local devices. E. All about USB We need to discuss somewhat more the accessing of USB devices. a. What is supported ? We found that regular memory sticks, such as disk-on-key work without problems. On the other hand special devices such as mp3 players didn't connect. This is dependent on support in the Linux thin client. b. After sticking in the memory stick on the thin station we have to reboot the station to make the device available to the server. If we replace the devices while working, the mapping doesn't work. [Maybe a solution for this will come up ..] F. Hardware In principle the thin clients software can deal with a large range of hardware. But we can never do better than the hardware allows. We had problems with various VGA adapters, and monitors. Apparently this is a matter of expecting demands to specifications. For example, lowering the resolution, the number of colors used, the refresh rate etc. If AGP cards are used it is recommended to install at least 96 MB RAM instead of 64 MB. G. Finally
  16. 16. If all works nicely, there is no use for the local hard disk (and for any RAM over 64 MB). And you may take it out and use else where! The local system won't be bothered any more with - viruses - security updates - ghosts and images - hackers The above instructions look complicated, but the trade off in investing in re-using old computers as thin stations is large. Thanks to Diegoiv, the developer of PXESCONFIG for the wonderful job he did. Benny Keshet David de Leeuw February 2005 i Here we got started with by Wolfgang Sauer ii See quot;How to setup and configure remote installation services in windows 2000quot; Microsoft Corp. Art. 298750 iii See How to Prestage a RIS Client Computer Using ADSI, Microsoft Copr. 302467 iv Diego Torres Milano <>