Last year we wrote about remote booting DOS/Windows 3.1 machines in a NetWare-based environment (see "Remote Booting: A Paddle for Network Support Staff" at www.NetworkComputing.com/810/810ws1.html). In that environment, we saw that the remote boot process is fairly straightforward. The boot PROM on the workstation's Ethernet adapter requests a specific image of boot files from the NetWare file server. The files from the image are expanded into the workstation's memory as a pseudo A: drive, and the machine boots normally. Eventually, an IPX connection is established with the server, and all the remaining files needed to start up are available.

So, what's up with remote booting Windows95? First of all, it's almost nothing like remote booting DOS/Windows 3.1--although understanding the DOS process is very helpful. Rather, it's like that Western movie, The Good, the Bad and the Ugly, and Microsoft Corp. plays all three parts.

The Good is that Microsoft provides the facility for remote booting in the Windows95 environment. The Bad is the meager implementation documents found in the Windows95 Resource Kit. And the Ugly has to be the labyrinthine process of remote booting using protected-mode networking, which has seen no improvements since its release. Additionally, since Novell has shown little interest in implementing remote booting in Client32--as evidenced by its repeated back-burnering of the technology since the first release--perhaps we should be thankful that Microsoft has done anything at all.

Setting the Stage At Syracuse University, our environment consists of NetWare 4.11 servers. Networking is supported by 3Com Corp.'s 3C905 Fast Ethernet adapters running on a full-duplex, 100-Mbps LAN. Remote boot images are delivered to the clients via Lanworks Technologies' Multi Server Director (MSD.NLM).

The client machines in our environment reside in public-access labs throughout the university. These machines attach to the LAN through switched 10-Mbps ports and consist of several different Intel Corp.-based computer makes and models, ranging from 66-MHz 486s with 24-MB RAM to 266-MHz Pentium IIs with 64-MB RAM. Network adapters are all 3Com 10BASE-T Ethernet cards (3C509B or 3C900) using the Ethernet II frame type and Lanworks' remote boot PROMs. The final defining feature of all the client machines is that they have no hard drives. That's right, Windows95 and nothing but net ... the Good.

There are some peculiarities of administering a public-access lab at a university. Foremost are concerns for security on the network, the individual machine environment and compliance with software licensing. Of course, the corporate world is not immune to these concerns; however, in academia it can be a constant battle.

In the corporate world, some accessibility concerns regarding a meddlesome user or the access required for the accomplishment of a user's job are tempered by users' need to authenticate to the network under their own user IDs. In our public labs, we have no such luxury. Hence, we automated the boot procedure to look up the appropriate machine ID based on the Ethernet address and log in under the appropriate machine user ID. This machine user ID will grant access to just those resources required by the machines in that particular lab. Users who have their own network accounts can be restricted from accessing lab facilities from outside of that environment and can gain access to whatever resources are accessible to those accounts by establishing bindery connections to their other resources.