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. 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 http://pxes.sourceforge.net/
- Etherboot software http://etherboot.sourceforge.net/
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. 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. 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. 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. 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 http://pxes.sourceforge.net.
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 http://fohs.bgu.ac.il/downloads/pxes/pxes-base-
dependencies.zip)
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-1.4.1.2.90-45.i386.rpm
Glade-Perl-0.60-1.noarch.rpm
can be downloaded as
http://fohs.bgu.ac.il/downloads/pxes/Glade+dependencies.zip
libglade-0.17-15.i386.rpm
libxml-1.8.17-9.i386.rpm

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
http://fohs.bgu.ac.il/downloads/pxes/Gtk+dependencies.zip
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/PxesconfigGUI.pm
(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 http://sourceforge.net/forum/message.php?msg_id=2846169 for full patch.

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 http://fohs.bgu.ac.il/downloads/pxes/pxes-
patch.zip)
BUG C. mke2fs syntax change in fedora code 3 from core 2
See
https://sourceforge.net/tracker/index.php?func=detail&aid=1096869&group_id=45684&
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
http://fohs.bgu.ac.il/downloads/pxes/pxes-patch.zip
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
http://www.mail-archive.com/rdesktop-users@lists.sourceforge.net/msg00000.html
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. 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 http://www.etherboot.com/
A. Preparing and Checking Hardware:
For our Intel NICs we updated the NIC’s BIOS with the latest Intel Boot Agent.
(see http://www.intel.com/support/network/adapter/pro100/bootagent/sb/cs-008362.htm)
The machine BIOS was configured to boot from network.
Different NIC cards need different settings.
We used http://www.rom-o-matic.com 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
http://www.noblegeorges.com/pjcity/dosware/pci.zip .

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:
http://support.microsoft.com/?kbid=228905
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. 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. Find key “netbootGUID” double click to edit it enter the GUID as
hexadecimal couplets separated by a space (00 00 00 …).

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. 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. 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. 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 http://thinstation.sourceforge.net/MSRIS-HOWTO.html
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. Artl..no 302467
iv
Diego Torres Milano <diego@in3.com.ar>