Remote Booting: Your Network Support Paddle The network server contains the client images, associated files and a boot table that specifies which image will be delivered to a given client, based on the client's network address. In our IntranetWare environment, for example, these image files are stored in the SYS:LOGIN directory along with the boot table, stored in BOOTCONF.SYS. Located in this file is the client machine's Media Access Control (MAC) address, as well as entry for the IPX network where the client can be found. A single machine can have multiple boot images, depending on the network number to which it is attached during boot. This can be particularly useful for laptop-carrying support staff who need to emulate the boot environment they are troubleshooting. If a client's machine address is not lis ted in the lookup table, the requesting machine can be served with a default boot image, NET$DOS.SYS, or receive a lookup failure and have its process terminated. The next component required in this process is the boot image, which contains all of a machine's boot files. This file is basically no more than what might be found on a bootable floppy disk residing on the network server. For example, in our test environment this included the DOS files found on a newly formatted bootable disk (including CONFIG.SYS and AUTOEXEC.BAT), the required network driver files for the client NIC, given our network environment, and a couple of other files (such as TCPIP.EXE) loaded at boot time prior to network connection. Once the client is network connected, the remaining boot files are accessed from shared directories on the server to complete initializing the environment. To complete booting, you may also need to supply additional files to the directory holding the boot images. In our case, we found that as soon as the IPX/SPX network connection was established with our server, the files from the boot image were no longer available in memory. This also was true for files we thought were open and being read--such as the AUTOEXEC.BAT. However, files were never left open while being used. Rather, files like AUTOEXEC.BAT were being opened and closed repeatedly after reading each line in the script--with a pointer mechanism to find their place each time. We found this frustrating, because subsequent to attaching to servers, commands located in AUTOEXEC.BAT went unexecuted when the batch file left memory; we were required to add this batch file to the SYS:LOGIN directory, along with the boot images, so that it would be available to complete the process. To avoid confusion between different boot sequences, we renamed this file to coincide with our client image. There may be other files that will fit in this category. But now that we're attached to the server, we can continue to log in and retrieve those files from our no rmal directory structure on the server. During our tests, setting up the boot images was fairly straightforward once the master boot floppy was created for each of our machine configurations. We generated our actual boot images using two different utilities, Novell's DOSGen (native to the server environment) and LANWorks Technologies' BootWare Manager. In the Novell arena, the DOS-based utility DOSGen took the contents of our master floppy disk and created the boot image file with no additional steps, save our renaming the image file from the default of NET$DOS.SYS to something more descriptive of the machine for which it is configured and moving the image to the SYS:LOGIN directory. Updating these images when any component on the master boot floppies is changed requires that you run DOSGen for each of those modified master disks, rename, then move those files to the server. We also tested, and were impressed with, LANWorks Technologies' BootWare Manager to create these images. This program provides many more features for creating and simultaneously managing our boot images. Instead of working directly from master floppy disks, we were able to use source files stored on any local or network-attached file system. The power of this approach came into focus when we considered updating a file common to several images, such as LSL.COM. Rather than manually updating the various master disks and running DOSGen on every image, this utility automatically updated all the boot images that contained the new file--a real time-saver.

Examining the Network Performance of JDBC by Barry Nace Updated May 23, 1997