!! This topic still under construction !!
Note - you will also need to view How to setup a BOOTP Server in my Home Server topic
What is meant by a 'Diskless Workstation' ?>
Essentially, a computer that can boot itself across a network and run from a RAMdisk. This means, of course, that anything the user wants to keep beyond the next power cycle has to be saved to a network share or a local USB stick etc.
Diskless Workstations are configured so that the Desktop and 'My Documents' folders are automatically 'redirected' onto a 'network share'
Why go 'diskless' ?
One of the main reasons for going 'diskless' is to prevent any permanent changes to the System. This means, for example, that it is 'impossible' to become infected with a Virus.
What's the difference between a Diskless Workstation and a Thin Client ?
A Diskless Workstation is simply a computer without a hard disk. It has all the normal Windows features and performance of a computer that has been booted 'normally' - in fact, because RAM is much faster than a hard disk, it may ever perform faster.
A Thin Client is a computer that is acting as a 'remote display' for Windows running on a Server. The Server runs your applications (not the local computer) .. the local computer is essentially a 'dumb terminal' of the Server.
Thin Clients are used when the local computers are so old that they could never actually run Windows locally - of course the Server has to be powerful enough to run multiple simultaneous 'sessions' of Windows, so this really only 'sort of makes sense' in a corporate 'mainframe' environment, where there is also some cost advantage in that you only need enough Windows Licences for the maximum number of simultaneous users (rather than one for each computer, irrespective of it's actual use)
How do I build a Diskless Workstation ?
First, remember that each installation of Windows must have it's own Licence & GUID / SID. This means you need to build a separate 'image' for each of your Workstations
SETI will only process a work-unit on the computer that 'fetched' it. Unless you want to loose the current wu to a power-outage, you had better not change the Windows System ID
Second, remember Windows wants to 'lock' itself to your motherboard / NIC card (to prevent 'piracy'). This means, in effect, you have to let Windows 'configure itself' on the motherboard it's going to run from.
Sysprep will allow you to take a pre-configured Windows system from a 'master' computer and 'depersonalise' it so it can be re-used on another PC
Third, remember that a Windows installed on an IDE drive won't run on a SATA drive, let alone a RAMdisk
One way to 'trick' the installer is to use a RAMdisk driver that 'emulates' a SCSI disk (see WinVBlock. This is possible because the standard windows installer 'pauses' before starting the install and asks if you want to 'load a SCSI driver'
Other approaches involve replacing the disk driver before 'cloning' the Sys-prep'd image
Finally, you have to learn how to use BOOTP (in 16 bit mode) to load Windows from the network and then 'switch' operations to the (32 bit mode) loaded image without re-booting
To be inserted here == building a Windows System for RAMdisk running
How do you boot across a network ?
Many methods exist, however I'm going to focus on the oldest, BOOTP
BOOTP is a simple way for a motherboard BIOS (or stand-alone Ethernet card) to locate and fetch the Operating System and load it into memory (RAM) in 'exactly the same way' as the Motherboard BIOS would normally fetch and load the Operating System from a (local) hard disk.
BOOTP is actually only used by the computer to obtain an IP address plus the location and name of the first 'bootstrap' file. The bootstrap file is fetched using Trivial File Transfer Protocol (TFTP). To support Diskless Workstations you thus need two Services running = BOOTP and TFTP
PXE is a 'more modern' (i.e. more pointlessly complex and harder to implement / get right / make work) version that uses DHCP instead of BOOTP to obtain the computers IP address
What happens after the bootstrap file loads ?
Typically, it will use DHCP to obtain a 'real' IP address (rather than the temporary one used by BOOTP) and then start loading the Operating System. The 'old method' is to create a RAM disk on the local computer and load Windows into the RAM disk and then start it running. The 'new method' (iSCSI) is to 'mount' a remote disk containing Windows and boot (start direct) from that.
What's iSCSI ?
iSCSI is a 'better network share' that can even 'run' across the internet. To support local iSCSI transfers, you need a Server that is running iSCSI 'target' software.
Unfortunately, iSCSI is 'aimed' at high-end data center 'Virtual Machine' (64 bit) systems and the 'cloud computing' garbage. Whilst simple local LAN support does exist, all the non-commercial / non-Microsoft implementations of iSCSI I have found assume that you are building a stand-alone NAS box .. so you are expected to have a 'bare box' onto which you load a LINUX/iSCSI build such as OpenFiler (or FreeNAS)
Note that Microsoft does not support remote booting of non-Server software i.e. MS is happy for you to net boot your Data Center Server but NOT your client computer diskless workstations. So if you want to avoid MS restrictions, you will have to go 'Open Source' for the net-boot sequence
Whilst it is possible to run both Windows and Open Source NAS on the same Hardware at the same time (by using virtualisation' - see here, using FreeNAS, this is a 'high end' solution, which comes with the usual MS restrictions.
To implement a low end iSCSI server you will need to dedicate a spare computer to that function only. I suggest using the OpenFiler ISO (boot CD) and make a bootable system disk.
To avoid the need for additional Hardware, I recommend sticking to the 'old' (RAM Disk) route instead.
It is possible to cut installed Windows XP right down to 150Mb (especially as the RAM disk can be setup as a NTFS compressed drive) and have it use no more than 50Mb memory when running. This means it is possible to run a SETI on Diskless node that has only 256Mb physical RAM.
How do I use BOOTP (& TFTP) to boot my computer ?
If you go into your Motherboard BIOS and open the 'Boot Sequence' (or 'Boot order') option, you will find 'BOOTP' (or 'Network Boot') listed as one of the choices (you may have to find the Network options first and enable BOOTP).
If you have an older Motherboard that does not support Network Boot, just plug in any PCI NIC and set the 'BOOTP' jumper (on older NIC's) or use the NIC card's software 'configuration' utility (which will run from a DOS boot floppy) to 'turn on' BOOTP.
If you enable Network Boot and place it at the 'top' of the Boot order list, your Motherboard will 'look for' a BOOTP/TFTP Server during power on. After a short delay, if no BOOTP (or TFTP) Server responds, your PC will then continue with booting from hard disk etc.
What if my network interface doesn't have a 'boot from network' (BOOTP / PXE) function ?
Create a bootable floppy disk that will perform the BOOTP functions. See Etherboot project.
Whats the 'best' motherboard for building a BOOTP Node ?
If your Server supports Gigabit Ethernet, plainly booting across the network will be faster if you have a motherboard with built-in Gigabit Ethernet. I thus recommend the Dell Optiplex GX range (for SETI, you need a motherboard with PCIe x16 slot (for a CUDA Graphics card), so that means the Optiplex GX280).
How do I provide BOOTP / TFTP Server services ?
If you have 10 or less computers that need BOOTP and want to avoid paying Microsoft for a Server Operating System (and then pay MS some more for Client Access Licences), just use an Open Source combined BOOTP / TFTP Service designed for remote boot support on an 'ordinary' XP Pro machine.
Ideally, your 'server' will be delivering boot 'image' files from a software RAID Mirror (which effectively doubles the disk speed as each disk only has to deliver half the file)
How does the BOOTP Server 'know' what bootstrap file a computer needs ?
You define a list of all the computers that will use BOOTP (identified by their 'MAC Address') along with the name & location of the bootstrap file they will be given. This list is held on the BOOTP Server.
If I have a BOOTP Server, do I also need a DHCP Server ?
Yes. Your computers Ethernet BIOS will use BOOTP to obtain an IP address for use during the TFTP boot sequence, however once control has been passed from the BIOS to the Operating System, DHCP will be used to obtain the computers 'real' IP address. You can thus use a totally different set of addresses for your BOOTP Server (and allow your Router to run DHCP 'as normal').
This means your Router can continue to issue DHCP addresses for all 'normal' operation whilst the Server issues addresses only for boot use
Note - if you are booting to 'RAM Disk' this is fine - if you are 'mounting' a 'remote disk' (eg. iSCSI), Windows will get very upset if you try to change the IP address :-)
How difficult is it to boot a Diskless Workstation across the network ?
How difficult is it to boot a Diskless Workstation across the network ?
A1. For LINUX etc., it's simple, straightforward and easy.
A2. For Microsoft Windows, it's complex, convoluted and difficult. Even MS themselves (with Win XP Embedded) 'cheat' by 'installing' Windows onto the RAM disk.
The first basic problem is that the Windows boot sequence is essentially 'dumb' with many 'hard coded' assumptions about 'where things are'. So whilst the motherboard Ethernet BIOS is perfectly capable of going out onto the network to find the first bootstrap file, any Microsoft boot files loaded will still insist on accessing fixed sectors on the local hard drive ... further, during the boot sequence Windows will insist on using, and making changes to, the Registry which it 'knows' to be on the local hard disk - so whilst booting from the network it will try to access files locally that have not yet been fetched from the network ...
One solution is to replace the dumb Microsoft bootstrap files with the LINUX equivalent (GRUB) ... the other is use a utility that will create a local RAM disk, load an 'image' of Windows onto that and then let Windows run itself from the RAM drive (this is the approach that MS takes with Win XP Embedded).
The second most basic problem is that each running Windows Operating System MUST have a unique identity (called a 'GUID') & Security ID (SID) - if two computers with the same GUID/SID exist that can 'see' one-another across the network, all MS networking functions for those machines will crash. This makes it impossible to use a single 'image' of windows on multiple workstations UNLESS the boot process modifies the GUID/SID before handing control over to the newly loaded Windows
Will I run into Licence 'activation' problems with my XP system 'image' ?
'Yes and No' = after installing on a (non-Dell) motherboard you have 30 days to 'activate' XP. Once 'activated', XP is 'locked' to the Motherboard ID + hard drive ID + Ethernet NIC ID. You can change one of the ID's without having to re-activate, but since Ethernet is typically built into the Motherboard, this means you can not 'migrate' a single build to multiple motherboards (unless they are all Dell).
Thus you must build (and activate) a SEPARATE image for each motherboard (and have each boot it's own image). If you stick to Dell motherboards, you don't need to 'activate' anyway.
'No' = if you use BartPE (or similar), then each time the Node is 'booted' you will ACTUALLY be performing a new install .. this means you can use a 'BartPE' system, with a separate licence for each motherboard, and if you re-boot every 30 days and you will never need to worry about 'activating'. The problem is, every time you reboot SETI will abandon any existing wu it is processing and fetch a new one for the 'new' computer
Why are Dell's different ?
The Dell System CD incorporates a special SLP Licence Key that works on any Dell motherboard without the need to 'activate'.... but that means your Windows XP System CD from Dell ONLY works on Dell motherboards.
Dell systems use 'System Locked Pre-installation' which means a Dell XP CD will install and run perfectly OK on ANY Dell motherboard without you needing to enter the individual Licence Key.
Note that, even if you are using Dell motherboards, you still can't use a system 'image' on more than one motherboard without changing the GUID ..
Corporates that 'roll out' operating system 'images' use the Microsoft Sysprep tool which will adjust the GUID/SID whilst installing the 'image' onto a new computer
How do I prepare my diskless workstation Operating System ?
This, of course, is the hard bit ....
OK, first you need to know that the 'original' tool for building a 'pre-install' XP was Barts PE. For cutting out the crap, the 'standard' is nLite, HOWEVER Bart's PE will complain about 'missing' files (& refuse to build) if you try to use it on a nLite reduced XP because Bart PE was designed for 'full' XP only.
Todays 'standard' for building 'reduced' XP pre-install CD's is LiveXP over WinBuilder
Why is it so hard to network boot a diskless workstation ?
The 'problem' with remote booting a 'compute Node' with an Operating System 'image' is that this can bypass the MS Licence restrictions. Needless to say, this is the core reason why MS goes out of it's way to prevent you building a remote bootable XP. The only 'legal' way to do it is using the 'Pre-install Environment' (PE) method which means each boot-up is actually a new Windows 'install' sequence (so a Licence number has to be provided).
XPLive is a 'script' that instructs WinBuilder how to build a 'pre-install' XP and lets you select which XP components you want to use in the install. To get XP to auto-install 'from scratch' on each remote boot you provide an 'answer file' - and this is where you place your Licence Number. This route is 'tried and tested' however because you are installing Windows every time you 'boot' it can be rather slow. This means that you need to strip out all the Multi-media garbage and support for Hardware you don't have** (such as the Modem drivers etc.) from the install sequence
Needless to say, convincing the installer to install to a RAM Disk (without 're-booting' and clearing the RAM) is another problem that has to be overcome
** Once you have stripped the installer of it's attempts to install Hardware you don't have, the install will run a lot faster (a 'normal' install encounters multiple delays as the installer 'times out' waiting for non-existent Hardware to respond)
I have an sp2 CD but 'need' sp3 ?
Most likely you do not - the only real difference between sp2 and sp3 are the new versions of MSIE and WMP
If you really want to build a new sp3 System CD, proceed as follows :-
1) First copy all the files from your existing Windows XP sp2 System CD to your hard disk at some location you will later use as the 'source' of your new CD (eg c:\NewCD)
Make sure you copy all files and all subdirectories !
2) Download the XP sp3 'network install' package from Microsoft to C:\temp (or similar)
3) From a 'command prompt', 'execute' the service pack using the "integrate" option - for example :-
C:\temp\WINDOWSXP-KB936929-SP3-X86-ENU.exe /integrate:c:\NewCD
Note - if your original CD is an OEM version (eg Dell), you have to run 'integrate' on that OEM's (Dell) computer (see MS support note)
How do I make my Windows System CD BOOTABLE ?
A1. You need to extract the boot sector from an existing bootable CD in order to 'burn' it to a new one.
You can use the 'free' ('trial') version of ISO Buster to extract the boot file or use a BartPE tool instead (see how to make a Slipstreamed Windows XP Install CD).
If you don't have Nero or Roxio (or some other bloated over-priced commercial garbage) then use the free ImageBurn tool.
What crap can I cut ?
Lots :-) Rather than do it yourself, I suggest picking up one of the Live XP projects
How do I network boot my XPLive 'image' ?
OK, this is what it gets a bit more difficult. Essentially you have use a BOOTSTRAP file that will create a RAM disk and 'install' XPLive into this without rebooting between steps
Do I need any special files for diskless workstation booting ?
Yes. You need 3 files from Windows 2003sp1. These are SETUPLDR.BIN or SETUPLDR.EX_, NTDETECT.COM and RAMDISK.SYS.
In fact, you can take NTDETECT.COM from a retail XP distribution disc (DO NOT be tempted to use a DELL System Disk ...)
Note that the Server2003 MS RAMDISK supports NTFS Compression (which 3rd party RAM Disk drivers do not) but only supports a maximum size of 512Mb. This means your XP Operating System MUST fit within a (compressed) 512Mb 'partition' !
How do I minimise the amount of RAM needed for my RAMdisk ?
If your RAMdisk is running NTFS, it is possible to use a feature of the NTFS file system known as 'Mountpoints'. Basically, this lets you 'map' to a network 'share' and instead of using it as a normal 'drive letter', use it to 'impersonate' a normal 'folder'.
Whilst you can't expect this to work during boot-up (since nothing will be 'mapped' before the GUI loads and a User is logged in) it does mean you can move your entire /Programs folder and /My Documents etc. to your Server and NTFS will never notice !
How do you install (net boot) XP directly to a RAM Disk ?
UNDER CONSTRUCTION
BOOTP has to boot Grub4Dos. This loads MEM Disk which can be used to create a RAMdisk and 'hooks' the INT13 (BIOS hard drive access point). This allows you to load XP. Unfortunately, XP itself won't use INT13 to access the RAMdisk - instead you have to install a driver such as WinVBlock or Firadisk driver
Click 'Next >>' in the Navigation bar left for 'How to use a CUDA Graphics card for SETI processing'