Although this works well in our labs, it would be much easier to throw all the boot/identification processing out of the loop. In the corporate world, where users employ their own user IDs to access all networked resources, such a meticulous boot/identification process is unnecessary. Users simply identify themselves and the boot process continues.
What is not immediately apparent in the above model is how these multiple authentications take place in the NDS environment of NetWare 4.11. Due to the necessity of having the machine ID as the primary authentication on boot, we found that the machine's authentication would necessarily be a directory services connection. Since there can be only one Directory services connection per tree, all subsequent, or personal, authentications are in bindery mode. Being able to employ personal user IDs for primary connections would relieve this complexity entirely. Users logged in under their own accounts, on an NDS connection, would behave similarly to a nonremote boot client.
Microsoft's Service for Novell Directory Services is the only client that currently supports remote booting. Ideally, we would prefer to choose whether initial connects are bindery- or NDS-based; however, Microsoft's client does not offer this feature. And though Novell's Client32 does offer this ability, it does not support remote booting. In the end, we were pleased to find that Microsoft's service worked well in our environment. Our concession, however, is that the very first NET USE operation is a directory services connection and all subsequent connections are bindery. This forces our lab users to re-authenticate each network resource they access, which is contrary to the philosophy of NDS.
The Supporting Cast So where are the pointers to pulling this off on your own? Although rather thin, the only documentation we had for remote booting Windows95 was found in Chapter 4 of the Windows95 Resource Kit. It's important reading but comes up way short of being thorough documentation.
For example, our greatest problems surfaced when we noted that there was no discussion on how to handle highly individualized components, such as the registry, or machine-specific or volatile directories like the Start Menu. When you begin to share information that is designed for personalized installation, it seems as though there should be a guide to help get you started. Similar to Microsoft's view of application networking, there are two underlying assumptions: You've got a hard drive installed in the client machine, and you're going to install all customizable pieces (if not the entire application itself) on that hard drive.
What would have been useful is some detailed discussion on the transition between the initial real-mode networking environment and the launching of Windows95 and its protected-mode networking environment. For example, it is quite a shock when the RAM drive from which you are booting suddenly disappears, taking the registry with it, when Windows95 starts up. Furthermore, how does the handoff occur between the real-mode and protected-mode network drivers? (Therein may lie the answer to the directory services versus bindery connection concern.)
|
REPORTS
ANALYTICS
Follow 
