Finishing Touches Considering our options, we found the best approach was to locate as much machine-specific information on the local machine as possible, such as the registry and system .INI files. However, you may want to weigh the cost/benefit of storing browser cache and the like on your local machines.
To accomplish our goal, we created two RAM drives--the first (C:) configured at 1.44 MB and the second (D:) configured at 6.5 MB. The reason for a second RAM drive is that our first RAM drive, although still chewing up memory, becomes unavailable once Windows95 starts and the protected-mode environment takes over. We use the first RAM drive for the initial download of the boot image and the second for building a persistent location for the Windows95 environment (see "Sample CONFIG.SYS and AUTOEXEC.BAT Files" on page 99).
Our last major hurdle was going from power-on to an online GUI with no user intervention. We drew on some of our experiences in remote booting DOS/Windows 3.1 and created a custom WIN.BAT file (see "Sample WIN.BAT File" at left). In our environment, we rely heavily on the use of environment variables for determining what operations are required for a given machine. Instances that require input from the keyboard, such as supplying a user name, are handled by a public-domain keyboard utility in response to the logon queries of NET USE.
After the workstation has logged in, established its real-mode network connections and mappings and built its local Windows95 environment on the second (D:) RAM drive, Windows95 proper is called via WIN.COM. From this point on, Windows95 boots normally. When protected-mode networking comes online, the real-mode connections are subordinated by the 32-bit environment. In other words, the real-mode connections are lost; however, the real-mode components are still loaded and taking up memory. Any future connections created will be in protected mode, as if the real-mode environment never existed.
Wrap-Up What if we added local hard drives to the mix? At that point, you'd probably have to question why you're remote booting at all. Remember, the benefits of reduced administration that you glean from sharing a networked copy of the desktop OS--either DOS/Win 3.1 or Windows95--are substantial. However, the underlying boot environment of Windows95 is much less critical than that of DOS/Win 3.1 in terms of its effect on the stability of the resultant user environment. Hence, the big bang for remote booting Windows95 is in establishing the exact same environment on all machines every time they get restarted.
Unfortunately, from what we know, remote booting on Microsoft platforms may come to an end with Windows95, as Windows98 reportedly does not provide any remote boot support in its initial release.
Certainly, remote booting is not the glamour star of the network OS world. In fact, it is probably closer to a Rodney Dangerfield among Oscar winners. But there are many environments in which the total cost of ownership can be drastically reduced via a centralized-management approach to network clients and their environments.
Scott S. Campbell is a network systems analyst at Syracuse University. He can be reached at sscampbe@syr.edu.
|
REPORTS
ANALYTICS
Follow 
