Remote Booting: Your Network Support Paddle By Scott S. Campbell   Ever feel like you were about to be cast adrift in swift currents without a paddle? And you thought you had a paddle on order, but upper management is waiting to budget it in the next fiscal year. Desktop support can be a lot like that. It often seems like there's never enough time to keep your users' computers up to date. To make matters worse, users may take it upon themselves to tweak or fix machines. Eventually, you, a member of the trusty support staff, are called to the client's site to solve a problem. The machine in front of you, though, bears little resemblance to the standard desktop configuration embraced by your organization. How long does it take you to diagnose the problem before you can begin fixing it? You may find that the problem a user is having is prompted by a system patch that was never applied, or you may have to undo some playful tampering. In the end, the fix may be simple, but in many cases these problems shouldn't have cropped up in the first place. Meanwhile, the tasks that were placed on the back burner to answer this call are boiling over and jeopardizing your reputation as an able network administrator. Sharing Your Paddle If this scenario sounds vaguely familiar, maybe you should consider an alternate method for managing your client configurations: remote booting. A centralized management approach, remote booting requires client machines to get their boot software as a single image from a central file store. This lets several machines share specific files used in booting the client (such as a version of DOS) or complete boot processes, resulting in multiple machines booting up with identical environments. To provide you with the tools you need and to get you paddling in the right direction, we tested a mixture of remote booting solutions. For variety, we experimented with a single vendor solution consisting of network adapters and boot programmable ROM (PROM) from Cabletron Systems, and a mixed vendor solution of network adapters from 3Com Corp. and boot PROMs from LANWorks Technologies. We also tested support utilities from Novell and LANWorks Technologies. Finally, we selected the DOS/Windows client platform, which we are remote booting from an IntranetWare 4.11 file server. Of course, other platforms, such as Windows95, Unix and the MacOS, can be configured for remote booting, and most of the concepts laid out here can be applied to those systems. However, remote booting Windows95 requires much more finesse than remote booting DOS/Windows. Windows NT does not support remote booting at all. Before taking the plunge into remote booting, there are some questions to consider: First, how many client machines are you supporting? Remember, a 10-minute visit to a dozen clients will take you more than two hours of support time. Second, how many client machine platforms are you supporting? If you can identify five distinct machine configurations across 50 clients, you can effectively reduce the number of clients by a factor of 10 by remote booting. Third, will your clients give up control of the basic configuration of their computing environment? The Necessary Supplies What will it take to put you back at the helm of your boat and help steer you out of the rapids? First, you must have a network device/server that supports remote booting. For our tests, we selected an IntranetWare 4.11 file server running on a Compaq Computer Corp. ProSignia 500. From the file server's perspective, the overhead for supporting remote boot workstations is negligible, and the size/power of the server shouldn't play into the equation. However, as the number of remote booting clients increases, additional load may be nee ded--if you boot more than 10 to 20 machines simultaneously, for example. This may be the case at the start of a new workday or the beginning of a class session in a lab environment. At these times, significant delays can be observed in the doubling or possibly tripling of boot times because of the high netwoubling or possibly tripling of boot times because of the high network contention. We found that this is not so much the fault of the file server as the shared network infrastructure. When 30 machines were remote booted on a dedicated switched 10-Mbps link to the desktop and 100-Mbps to the server, we saw the elapsed boot time near that of an independent remote boot.

may be the case at the start of a new workday or the beginning of a class sess>

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