Thinstation logo

Thinstation FAQ

Please submit any corrections/suggestions/additions to the FAQ directly to me. Please do NOT submit any questions about installation, usage or problems directly to me - these should go to the mailinglist, where you can get support.

This FAQ is edited by Mike Eriksen (km_eriksen at Contributed by many people. I'm nothing but an editor.

The most recent version of this FAQ is always at (in case you are reading a distributed version).

Document revised: 28-Feb-2005




This is the FAQ for Thinstation 2.0. The FAQ for Thinstation 0.9 and 1.0 can be found here.


Neither this author nor the project contributors are in any way responsible for physical, financial, moral or any other type of damage incurred by following the suggestions in this text or using the programs. Both this document and the Thinstation program and supporting programs are presented "as is" without any warrenty concerning functionallity or security.

Any trademark belongs to the owner.


What is Thinstation

Thinstation is a basic and small yet very powerful Open Source "thin client" operating system and some programs which make it possible to connect to servers via a network. Thinstation is mainly intended for office, company or department use. Being a private individual with just one PC you will have little use for Thinstation.

Thinstation is based on Linux, but users may actually never see Linux at all if you decide to connect directly to a Microsoft Windows server, a Citrix server or a Unix server! The user will feel he/she connects directly to the server. But if you want to, you can have a Linux interface - a blackbox window manager to be exact.

Thinstation also supports a MS Windows-only environment and REQUIRES NO UNIX/Linux KNOWLEDGE (but it doesn't harm :-).

Thinstation runs on ordinary PC hardware (x86) and is based on Linux, which itself is Open Source and free. You may either reuse older computers or save a lot of time on workstation administration. Or both! An old Pentium 100 MHz with 16 MB RAM or better will be a perfectly useful workstation. And you don't need a hard disk - you can boot off the network and even have a fairly silent workstation.

But even with brand new hardware Thinstation is advantageous, saving a lot of administration time (I personally did assamble a new small mini-itx PC from its boxes AND connected to Word on a Windows server within 19 minutes!). You can save money too, as you can just buy entry level or mini-itx computers and still have fast program execution (as your server permits). With a new cpu and psu fanless and diskless mini-itx PC you may have a powerful and completely silent workstation (and cool too, if you have to think about air conditioning expenses).

Thinstation is able to connect to:

  • Citrix servers using the ICA protocol (on top of MS Windows Server, SUN Solaris and IBM AIX)

  • Microsoft Windows Servers using the RDP protocol by rdesktop (Windows NT4TSE, W2k Server, W2k3 Server, even XP as single user only)

  • Tarantella servers

  • Unix servers running X

  • VNC Servers (actually tightVNC)

  • Telnet and SSH (Secure SHell) servers

You just need a decent server for the users. An ordinary quality PC with a ~2 GHz/"2000+" cpu and 1-1.5 GB ram will easily support 20-30 users on a Windows server with, e-mail and Word/Excel or any similar typical applications. However, it will not work well with Auto-CAD/3D Studio Max or other heavy duty programs.

Thinstation features:

  • Linux kernel 2.4.24

  • XFree86 4.3

  • Boot media: etherboot, pxe, CD, hard disk, compact flash

  • Small image size - typically 6-9 MB

  • Support of more than 30 locales (national languages)

  • Two client side web browsers - Dillo, Mozilla Firefox

  • Network booting using DHCP and TFTP (for etherboot and pxe)

  • Samba and NFS file access

  • Supermount (e.g. automatic mount) of client floppies, HDs, CDs, USB storage

  • Sound on clients (if supported by the server) and client connected printers (LPT and USB) - as well as server and network printers

  • PS/2 and USB keyboards and serial, ps/2 and USB mice

  • Scroll wheel mice

  • Support for syslog server (to monitor the clients). Remote or local

  • Enhanced Shell with command line editing and history

  • Telnet, web and VNC access to clients so the admin can login and check logs in /var/logs and if necessary reboot the workstation remotely. Or kill processes.

  • Debug package. This stops the inittab entry from working so you start in a console mode regardless what packages you choose, adds strace which is useful for seeing where a program fails. When in debug mode, you can start the session manually by going start-session 0

Hardware requirements:

  • Pentium Classic 100 MHz with 16 MB RAM or better (8 MB i special cases).

  • NIC: among others: Realtek 8139, NE2000(isa/PCi), VIA Rhine I/II, SIS 900, 3com 903/59x, Intel eepro100, tulip... (see build.conf for a comprehensive list).

  • VGA: VESA. Who needs more for a terminal anyway? OK then - also S3 (incl. virge and savage), ATI (Radeon and earlier), Matrox, Cirrus Logic, i740, i810, NVidia, Trident, National Semiconductor, Tseng, VIA and more (see build.conf for a comprehensive list).

If you are a bit handy with Linux any NIC supported by the kernel and any VGA supported by the current X-server can be supported by Thinstation.

Where does Thinstation come from

Thinstation was founded by Miles Roper as a fork from Francisco Castro's Netstation project. With Thinstation 2.0 not much original code resides, but the concept does.
If this project interests you, so might PXES (another Netstation fork) and Diet PC by Paul Whittaker.

Where to get Thinstation and more information

Thinstation is hosted by as You'll find two mailing lists there. You may download both precompiled images (for use in MS Windows-only environments), a fully configurable Linux version and the entire source for all Open Source parts.

How to install Thinstation

We expect you to be an adminitrator or to have similar knowledge (or plenty of time!).

Thinstation offers both prebuilt images for use in a MS Windows-only environment and a fully configurable setup if you have access to a Linux box (any current distribution will do).

The prebuilt MS Windows solution allow you to connect Thinstation clients to one or more MS Windows server (NT4TSE, win2k, win2k3) without the need of any unix/Linux knowledge, but still get all the client-server benefits! Read about the prebuilt solution in by Paolo Salvan.

To build your own image you need a Linux box. First get Thinstation from Unpack  Thinstation-<version>.tar.gz by
tar xvfz Thinstation-<version>.tar.gz

Next edit build.conf to reflect your client hardware. Make it as simple as possible in the beginning, and make it better/more complete once it works with a basic setup. Now you build the client image: type ./build.

What to do next depends on how you want to boot Thinstation:

(NOTE: thinstation.conf is a generic term - the is no file just named thinstation.conf. See the details in the section Configuring Thinstation).

- network boot with a NIC with a boot ROM:

A boot ROM is a small chip on your NIC. They are not common.

  • Copy everything from boot-images/etherboot and a thinstation.conf to your TFTPD root directory.

  • Edit the thinstation.conf to match your terminal's configuration.

  • Add <TFTPD root dir>thinstation.nbi as the boot file to your DHCP server's configuration.

- network boot with a NIC w/o a boot ROM using a boot floppy:

You may compensate for the lack of a boot ROM on the NIC by making a bootable floppy. This solution is probably the most common.

- network boot with a NIC w/o a boot ROM using a harddisk:

You may also boot using a harddisk instead of a floppy. See Alexander Heinz's excellent guide on

- network boot with a PXE-aware NIC:

  • Copy the files and directories in boot-images/pxe to your TFTPD root directory.

  • Edit the thinstation.conf to match your terminal configuration.

  • Add <TFTPD root dir>pxelinux.0 as the boot file to your DHCP server's configuration.

- boot from local storage media (hard disk, CD, Disk-on-Chip/CF...)

Booting off local media gives you the choice of two methods: sys/iso-linux or loadlin (DOS only). Please note you do still need the TFTP server to deliver the thinstation.conf file unless you adapted the thinstation.conf.buildtime correctly and make an unique image for each computer or you use the STORAGE_PATH option in thinstation.conf.buildtime and have a local thinstation.conf.user directly on the media as STORAGE_PATH/thinstation.profile/thinstation.conf.user. This only makes sense for RW media, whereas a RO media as a CD depends on thinstation.conf.buildtime


  • Burn the file boot-images/iso/thinstation.iso as an image (NOT a file!) with your favorite tool (cdrecord thinstation.iso under Linux is one suggestion...).



PKG packages:

PKGs are plain Thinstation packages in tgz format that is added after boot of the core system. This allows you to exceed the 16 MB image limit. You may load PKGs both from the TFTPD and from local media. Most packages may be PKGs. The environment variable "PKG_PATH" in build.conf" let you set a subdirectory to store the .pkg files.

Configuring Thinstation

(Contributed by B.J. Kramer - bj AT rentec com)

All client configuration is done in a thinstation.conf.<something> file. It is possible to have multiple thinstation.conf.<something>s - 'conf' files are looked for in this order:

  • thinstation.conf.buildtime (puts config directives in the boot image)

  • (default config, pulled from tftp server)

  • thinstation.hosts (contains host, MAC, and group mappings)

- if thinstation.hosts exists, the following file(s) are looked for (careful! Note where to use "." and where to use "-"):

  •<groupname> (there can be multiples of these)

Next - or if no thinstation.hosts was found - these files are requested:
  • thinstation.conf-<hostname> (e.g. thinstation.conf-my_pc)

  • thinstation.conf-<IP ADDRESS> (e.g. thinstation.conf-

  • thinstation.conf-<MAC ADDRESS> (e.g. thinstation.conf-112233445566)

  • thinstation.conf.user (locally stored configuration, placed as STORAGE_PATH/thinstation.profile/thinstation.conf.user)

Each file that is found is downloaded, and then the client looks for the next file in the list. So a client will start with whatever you had defined in thinstation.conf.buildtime when you built the image. Then it checks the TFTP server: the first thing is looks for is (which typically exists), and it reads in all of its settings. Then the client requests thinstation.hosts. If there is a thinstation.hosts on the TFTP server, the client will read in all available group config files (one at a time) that are found on the line matching the host's name and MAC address; Otherwise (or next, if thinstation.hosts was found), it will check for a hostname-specific conf file; then an IP-specific conf file; and finally a MAC address-specific conf file.

A few notes about this process:

  • conf files are NOT mutually exclusive. All valid conf files that are read during the boot process are used. So you can, for example, define some sessions in, some special application for certain users in, and add additional video driver parameters for the one user with a super-high-resolution video cards in thinstation.conf-hirezmachine. Things only start to get tricky when you realize that you can have the same configuration directive(s) in any or all of the conf files the client reads; then you need to know the order in which they were read to figure out which one's directives will take precedence (which will be the last one read).

  • All conf files EXCEPT thinstation.conf.buildtime and thinstation.conf.user are stored on the TFTP server:
    - thinstation.conf.buildtime is part of the Thinstation distribution; it only gets read when the boot image is first created. The directives in this file, if included, become the defaults for Thinstation, but will likely be overridden by any of the other conf files.
    - thinstaion.conf.user is stored on local media (e.g., the hard drive of the client computer with the path STORAGE_PATH/thinstation.profile/thinstation.conf.user), and its configuration directives override ALL other conf files. The client will only know to look for this file if thinstation.conf.buildtime is properly configured with the STORAGE_PATH setting.
    - you can change where on the TFTP server the other files are kept by changing the 'basepath' value in build.conf, and you can even change the names of all of these files from thinstation.conf* to somethingelse.conf* by changing the basename value in build.conf.

  • Creating a thinstation.hosts file is necessary in order to take advantage of using conf files for machines specified by name or groups. If all of your clients are exactly the same and your users have the same needs, you can probably just create a single and put all the configuration settings in there, and you're done. Most users, however, will probably want the thinstation.hosts file. Take a look at thinstation.hosts.example; you'll notice that you can have multiple groups associated with each host. The groups' conf files are read in the order they are listed on that line, so the 'later' on the line the group is, the more significance it has.

  • Beware you can't add features in a thinstation.conf<something> not already build into the image (pre-built or defined by your own build by build.conf)! (ie, defining an ICA session in a config file won't help you if you didn't include the ICA package in build.conf).

And now to Qs and As:

Booting Thinstation:

NIC, video and peripheral questions:

Thinstation as a workstation:

Unix servers:

MS Windows/Citrix servers:


Q: Can I have individual configuration files for different clients?
A: Yes. In your TFTP server's download directory you just create a configuration file named thinstation.conf-<ip address> (e.g. thinstation.conf- or thinstation.conf-<MAC address> (e.g. thinstation.conf-12AB34CD56EF). A file just named will be the default configuration.

If you have made a thinstation.hosts file (which maps MAC addresses to host names) you can name the configuration file thinstation.conf-<host name> (e.g. thinstation.conf-peter). Much easier to remember.

Q: Can I have individual image files for different clients?
A: Easily - if you boot off a local media, but it is not so easy with network boot. Usually the DHCP server tells the client to ask the TFTP server for one specific image. However, you can let the DHCP server detect the clients MAC address first and then hand out a specific ip address AND a unique image file name to the client. This way you lose some of the flexibility of using DHCP, but you get a more secure network, since you are in control of which NICs are acceptable to get net access. Normally you should be able to make a comprehensive image which covers any clients and then use the conf file to select the needed modules for the individual client. However, please note that you do have a size limit for the image file of 16 MB. If you get too close to 16 MB, then make some packages "pkgs" - that will place them outside the image but still work as included

Q:Which mouse protocol to use ?
A:For a traditional serial mouse (rhombic 9 pin connector) you probably need the MICROSOFT protocol. Mice with a PS/2 connector (small round one) needs ... PS/2 :-). However, wheel PS/2 and USB mice need the IMPS/2 variant. For unsual mice see

Q: How do I get the scroll wheel on my mouse to work?
A: Assuming the server and the server software application supports the scroll wheel, all you have to do is to change one line in the thinstation.conf:
Remember to hard reboot your Thinstation afterwards.

Q:How do I get my USB mouse to work?
A: You will need to use X_MOUSE_DEVICE=/dev/input/mice in thinstation.conf to support a USB mouse, in addition to including the "usb-hid" in build.conf.

Q: The X font server doesn't work
A: Make sure you use the right tcp port on the font server e.g. X_FONT_SERVER= (at least Red Hat uses port 7100 but check with your distro) in thinstation.conf.

Q: I can't connect to a unix server using X (just black screen and mouse pointer)
A: Make sure XDMCP is running on the server and accepts connections. There is a good step-by-step procedure at (not Red Hat specific).

Q: The Thinstation X server doesn't start - it keeps on trying and trying.
A: First make sure you have setup the mouse correctly. A misconfigured mouse can prevent X from starting! Go figure... Next make sure you have built in the correct driver in the image. Try the VESA driver alternatively (any video card should be VESA compatible). Make sure X_HORIZSYNC and X_VERTREFRESH in thinstation.conf has the correct values. X servers can be very picky about this! If you have trouble finding the right modes, have a look at

Q: Poor colors and no sound connecting to a MS Windows server with RDP (rdesktop)
A: NT4TSE and Windows 2000 Server only support 8 bit (256) colors. Windows 2003 Server support 24 bit color (16. millions) and XP 16 bit (65536) colors. Make sure to have a "-a 24" or "-a 16" as command line option in thinstation.conf.
However, make sure you run the Thinstation client at at least 16 bit color. You may get strange results if both the Thinstation client and the MS Windows server use 8 bit color maps.
Windows 2003 support sound redirect (if configured properly). Use the "-r sound" command line option.

Q: Psychodelic colors when using 8 bit colors with RDP (rdesktop)
A: This happens when both the Thinstation client and rdesktop is configured to use 8 bit color. The problem is that with that few colors (256), a palette is used to define the color scheme, and this has to be share among all applications. The solution is to run the Thinstation client in either 15, 16 or 24 bit color depth.

Q: Faulty keyboard layout with MS Windows server using RDP (rdesktop)
A: Rdesktop has a few problems with some non-US keyboards. Check out the rdesktop CVS to see which has already been fixed.
If you report a keyboard problem to the mailing lists, please follow this guide: keyboard-guide.html

Q:Flickering display with animated content in MSIE
A: See this knowledgbase entry. Easy in IE6, but requires a registry hack in 5.5. Thanks to Chris McKeever for this one.

Q: My BFG9000-Pro mk. III-c (or whatever) graphics card ain't supported by Thinstation. But XFree86 supports it!
A: If there is a driver for for your video card and it is for the same XFree86 version as Thinstation use (currently 4.3) and if it is compiled with GCC 2.95 (this is common), then support it yourself :-) Create the directory structure
Put the driver itself (<name>.o) there and chmod it into -rwxr-xr-x. Edit build.conf and add xf4-<name> as a module and rebuild. And done!
If there isn't any XFree86 support you still might still try the VESA driver, though.

Q: My NIC does support PXE but PXE boot doesn't work
A: If you have an early PXE implementation, it might be buggy. See Version 2.0 or newer is preferable. Most NIC manufacturer make update to the PXE bios, which may be upgraded.
However, double check your DHCP/TFTPD setup.

Q: My NIC doesn't support PXE and making/buying a boot ROM for it is out of the question. Can't I just boot off a hard disk?
A: Sure. Make a small DOS (FAT12 or FAT16) partition and use loadlin or syslinux to boot (loadlin is simple, syslinux offers more candy). See How to install Thinstation.
    Sub-Q1: How much disk space do I need then?
    Sub-A1: 8 to 10 mega bytes if you can afford it.
    Sub-Q2: So little!? Couldn't I use a USB keyring or a Compact Flash Card instead?
    Sub-A2:Yes - see Lars Karlslund's contributed Compact Flash card + syslinux boot HOWTO.

Q:Can I boot off a CD (KNOPPIX style)?
A: Yes. That's what the Thinstation boot CD does! You can use Thinstation without ever touching your PC's harddisk.

Q: Can I boot off a CD if my BIOS/CD doesn't support boot?
A: Yes, with a little help from a boot floppy: Smart Boot Manager.

Q: Can I boot off just a floppy?
A: Well, you can mimic etherboot with a floppy even if your NIC doesn't have a boot ROM. This mean you can use a floppy to connect to the DHCP and TFTP server and download the rest. Maybe a bit slow during boot, but it works well.

Goto and download an image for your NIC. Follow the instructions on that site to make a net bootable floppy.

Q:Can't I avoid the TFTP server?
A:Yes, but obviously only if you boot from local media. If you don't need any reconfiguration of Thinstation once it is built, you just hardwire all configuration with thinstation.conf.buildtime
Otherwise you have to set STORAGE_PATH=... correctly in thinstation.conf.buildtime and supply a thinstation.conf.user with the path STORAGE_PATH/thinstation.profile/thinstation.conf.user.

Q:Can't I avoid the DHCP server?
A:You must boot from a local media then. Setup all the network parameters in thinstation.conf.buildtime build the image.

Q: Cool! I just run MS Windows on a server and save all the licence money!
A: Well, that would be illegal.

In order to connect with terminal services to your Windows server from Thinstation, each client must have:

  • A CAL (Client Access Licence - you get 5 or 10 CALs for "free" with the MS server licence).

  • A TS-CAL (Terminal Server CAL.)

(note the difference between CAL and TS-CAL. A TS-CAL is more expensive than a CAL). Please read here for a more detailed and authoritative answer:

Also, Brian Madden has a good page on Windows 2003 licensing.

So, using Thinstation you save:

  • The money for the client operating system itself (you just have to pay for the CAL and the TS-CAL)

  • Really a LOT on client administration


Q:How do I use 128 bit encryption with ICA?
param icaencryption true
to build.conf and
ICA_ENCRYPTION="RC5 (128 bit)"
to a thinstation.conf.

Q: Can Thinstation be a light Linux workstation - or how do I get root access?
A:Well, if you really push it, yes you can have a workstation, sort of. At least you can have a stand alone Linux unit. You'll have very few tools and no compilers etc, though. To login in text mode you have to press Ctrl-Alt-F2 (even if you are in rdesktop or ICA mode or what-ever). Login as root. The password is pleasechangeme as default (Change it!!! - see below). If you prefer a X interface, boot up in blackbox and make a telnet to localhost.

Q: How do I change the root password - and should I change it?
A: YES! You really must change it! Why? Hmmm - only you, me and the rest of the internet know the default root password is pleasechangeme... And you shouldn't trust me :-)
The password is set in build.conf

Q: Can the clients have a /etc/hosts file the usual unix style?
A: Yes and no. There is no traditional editable hosts file, but you may tweak the Thinstation setup to support the same functionallity. Edit the file packages/base/etc/init.d/network at line 283 (just before # Add Mac Address to .conf file) and add:
echo " my_server1" >> /etc/hosts
echo " my_server2" >> /etc/hosts
(use your own relevant numbers and names). Note the double >>. You can add as many as you need. Rebuild.

Q:How are the clients named networkwise when using DHCP?
A: As default they are named ts_<MAC address>. "ts_" is defined in thinstation.conf by the NET_HOSTNAME entry. You may change this, but if you use more than three characters the MAC address will be truncated.

However, you may make the file thinstation.hosts in the root directory (where the kernel and the image is) to link a name with the MAC-address. The syntax is:

# You can have any amount of spaces/tabs between names
# HOST      MAC           GROUPS        COMMENTS
bigboss     000103014152  printer hires # On Miles Desk
daffy       0060082FCBE8                # Daffy's workstation
donald      00A02403B0BE  printer       # Donald's workstation

This will name the clients bigboss, daffy and donald.

Q: What is the group configs about?
A: Imagine you have a LOT of Thinstations. Some are old Pentium Classics, some are newer and have a printer attached and some have a good VGA and large, new monitors. Instead of making individual config-files for all your Thinstations you can group them with thinstation.hosts and create a<group name> (e.g A<group name> is just another thinstation.conf with a different name (as is thinstation.conf.buildtime). Be careful with all these "thinstation.conf" variants: the latest read will overrule an earlier read. See Configuring Thinstation

Q:Why does TS try to download the config file from a TFTP server when I boot from a local media?
A: Because you did not set NET_USE_TFTP=Off in thinstation.conf.buildtime!

Q: Do you have more docs on ICA, rdesktop, tarantella, blackbox...
A:We don't really doc the connectivity packages (ica, rdesktop...) since the guys and gals behind them has more knowledge and does it much better than we can do. Search at the parent package's homepage and get better advice.

Q:My keyboard layout isn't supported or is broken
A:See the keyboard request guide. However, see also Faulty keyboard layout with MS Windows server using RDP (rdesktop)

Q: Can I add my own package to Thinstation?
A:Yes. It requires some Linux/programming skills, though.
Make a folder in packages and make a copy of the package template and distribute all your files in the directory layout the Thinstation style, i.e. packages/<your app>/bin and packages/<your app>/lib. Don't use sbin, put everything in bin. Also, don't use var, or usr, these are just symlinks to tmp, everything in temp is created through the etc/init.d/XXXX scripts. Use /etc/init.d/XXXX scripts to do all your initilization as only tmp is writable. All other files are read-only, so anything which needs to be changed, needs to be a symlink to a file in temp. You need to link against glibc 2.1.3 (available precompiled from the thinstation-developer source code).
You'll find ldd very useful to determine dependencies.


DHCP- and TFTP-Server configuration

Thinstation normally needs (at least) three servers to work: a DHCP, a TFTP server and one or more application server(s). These may very well be the very same computer hardwarewise. But if you boot from local media you can avoid the DHCP and/or TFTP server. However, if you have many clients you would probably prefere both a DHCP and a TFPT server to make your life easier.

DO NOT INSTALL ANY SERVERS ON YOUR NETWORK UNLESS YOU ARE ALLOWED TO DO SO! They may conflict with existing servers on your network making you very unpopular...


A DHCP server (or "daemon" in the unix/Linux world) hands out an ip number for your client upon request and names the TFTP server as well as the name of the download directory and the client image on the TFTP server.

Windows 2000/2003 DHCP servers works fine, but if you use a Windows NT4 server you need Service Pack 4+ (you should have SP6 anyway). Any current Linux DHCP daemon is fine IFAIK, but you would probably choose DHCP3 by Paul Whittaker has a great piece on Windows 2000 and DHCP here. And there is a fine Linux guide at


The TFTP server manages the download of the boot image to the client.

The TFTP server must support the "tsize" option when using PXE boot. The Red Hat 7.3 TFTPD does not support this option. atftp does. Newer Red Hat versions should be ok.

Stolen directly from Paul Whittaker's (May 2003):
Now install and activate the TFTP server on your designated boot server. UNIX-like operating systems will come with a TFTP server package (although it may not be installed by default), but you may have to obtain a third party package for other O/Ss. See the Windows 2000 Etherboot HowTo for TFTP options available for Windows platforms. To activate the TFTP server on Red Hat Linux, install the TFTP server RPM, set disable=no in /etc/xinetd.d/tftp and restart xinetd using "sh /etc/initd.d/xinetd restart". Set "umask 022" to ensure world-readability, create your TFTP root directory (usually /tftpboot) if required.

The MS Windows servers come with a build-in TFTP server called "Remote Installation Service". However, it needs a domain controller to work, unless you use a hack by Morgan Simonsen (mind you - you still need a valid MS Windows server licens).

An other possibility to get a small and simple combined DHCP and TFTP server for MS Windows is (supports "tsize" for PXE boot). To run it automatically as a service, use FireDaemon (free for non-commercial purposes).
Check out Zack Forsyth's excellent guide Running a non-RIS TFTP server as a service in MS Windows server concerning this.