At its outset, the Microsoft Windows NT product was positioned as a client/server platform to challenge the overwhelming market share held by Novell NetWare. As NT matured through several revisions, however, Microsoft's viewpoint evolved, and it was recognized that the trend in networking was toward the mixing of different NOS and client platforms into unified networks. The current stance taken by Microsoft is that its intention is to produce a server NOS that can be addressed by any type of client platform, and to produce clients that can attach to any type of server.
With a few notable exceptions, Microsoft has come very close to achieving this goal. Support for networking has been assimilated into the Windows NT workstation and Windows 95 operating systems to a greater degree than it has been in DOS, OS/2, Banyan, or most other major network client OSs. The actual task of installing and configuring the network client support in the 32-bit Windows OSs is so simple that it barely needs to be mentioned. Clients, protocols, and services are selected from pick lists, and all the adjustable parameters are presented in a simple, unified interface that is light-years beyond the multiple TSRs and ASCII configuration files used for traditional OS client installations.
The area in which difficulties arise is the abundance of client choices that are available to the network administrator for each OS. There are several different methods, provided by different vendors, through which Windows 95 and NT workstations can access the services provided by each NOS on the network, and assessments of the users' needs and the resources available must be made to determine the best possible configuration. This chapter will cover the various alternative client services available for Windows NT and Windows 95 workstations. In the process, there will be discussion concerning some of the NOS features that are designed to facilitate various client services, as well as the different methods by which these client OSs can be installed using the network as a source medium.
At the bottom line, therefore, this chapter is more about arriving at an ideal client configuration than it is a guide through the process of connecting a single workstation to multiple NOSs. That task has, happily, become a rather simple one. To use the most common configuration as an example, a Windows 95 workstation can be made to access an NT server and a NetWare server simultaneously, with very little intervention from the installer of the OS. Most common NICs are auto-detected, along with their hardware settings. Protocols can be selected with a few mouse clicks and maybe the specification of a frame type. Even the installation of TCP/IP support can be quick and automatic.
The selection of which client to use, however, must be based on the overall design of the network and the services required by individual users. In many cases, you find that a single client operating system and network interface selection is not suitable for every user in a given enterprise. The combination of different network types in today's heterogeneous environments is, by definition, intended to accommodate the needs of a widely divergent pool of users, and the versatility provided by the various network client software interfaces for these operating systems allows network administrators to cater the workstation to their, and the users', individual needs.
Like all of the Microsoft OSs designed with integrated networking, Windows NT can function as either a peer-to-peer or a client/server network. Indeed, in earlier releases, the differences between the NT Advanced Server and Workstation products were few, and the OSs were almost indistinguishable. This situation has changed with the release of NT Server, version 3.5--and more so with version 3.51--but the non-dedicated functionality of the server product still remains. This means that resources can be located all over the LAN. A printer need not be associated with a machine dedicated as a server; it can be attached to any NT machine and access granted to all users by making it a shared resource. The same holds true for hard disk storage. Remote access to any Windows NT drive on the LAN can be granted to users by using passwords for each drive or assigning rights to user accounts.
The native network requester that provides a Windows NT machine access to other NT (or Windows for Workgroups or Windows 95) machines is fully integrated in the NT operating system for both servers and clients. As noted above, the installation process is simple, routinely accomplishing many of the tasks that must be performed manually during a NetWare 3.1x server or client installation. For its own networking, Windows uses a set of protocols based on several accepted industry standards. Figure 12.1 illustrates the correlation of the protocols to the standard OSI reference model.
For the physical layer, Windows networks utilize the standard Ethernet and token-ring cabling systems documented in the IEEE 802 committee family of standards; however, the similarity to NetWare networks ends there. At the data link layer, NIC drivers written to the NDIS 3.0 or 3.1 standards must be used. The Network Device Interface Specification is a standard developed jointly by Novell and 3Com beginning in 1989. It defines a layer linking the functionality of the adapter driver in the media access control (MAC) sublayer and the transport protocols operating at the network and transport layers. (See chapter 3, "The OSI Model: Bringing Order to Chaos," for more on these concepts.) Much like the logical link control (LLC) sublayer defined in the IEEE 802.2 standard, NDIS can provide unified access to several different protocol stacks at one time. Most NICs in production today include an NDIS driver along with the MLID driver needed for NetWare and whatever other drivers might be needed for other network types.
Figure 12.1
The networking protocols used by Windows NT in relation to the OSI reference model.
Atop the NDIS interface, Windows NT provides support for several different protocol stacks, any or all of which can be running at the same time:
Knowledge of these protocols is useful to the personnel responsible for installing and configuring these network clients. On a Windows NT workstation, installing an additional protocol is as simple as picking one from a list and then providing the OS with access to the appropriate NT installation files. Many administrators who are unfamiliar with the usefulness of the protocols that ship with Windows NT tend to install more of them than are necessary--sometimes even all of them--since the process is so easy. Doing this can slow down the operation of the workstation and the network significantly and should be avoided. Learn what the function of each installed protocol is, and only install those that are actually needed. Others can always be added later.
Above the transport protocol stacks is another buffering layer called the Transport Device Interface (TDI). This functions much like the NDIS layer, providing unified transport protocol access to the protocols functioning at the session layer and above. Just above the TDI will be any requesters installed on the system (in NT parlance, these often are referred to as redirectors), as well as various server application processes. It is the TDI that receives the network access requests from the redirectors and channels them to the appropriate transport protocol stack.
The server processes are the means by which distributed applications (that is, applications that split their processing functionality between client and server computers) enable communications between the client and the server. Among these can be NetBIOS, Windows Sockets, and the System Message Block (SMB) protocols. The latter, designed jointly by Microsoft, IBM, and Intel, is the protocol most commonly used by Windows NT at this layer. It is used for requesting files from servers and delivering them to clients, filling much the same role that the NetWare Core Protocol (NCP) does in NetWare networks.
Thus, a basic file access request using the standard Windows NT protocols (see fig. 12.2) begins as an SMB message, generated by the originating workstation application's API call, which is channeled through the redirector (that is, the native Microsoft client) to the TDI, which sends it as an NBF down to the NDIS interface, which directs it to the NIC driver, and then to the network interface itself, and onto the network medium. Arriving at the server, of course, the process is essentially reversed, with the data traveling up the stack to the server NOS application, which then responds in much the same way.
The native client services for Windows NT provide access to a network of other systems running Windows NT Workstation or Advanced Server, Windows for Workgroups, or Windows 95. They can also connect to LAN Manager servers and remain compatible with the original MSNet OS. The functionality of a Microsoft network connection is essentially the same, whether it is achieved using peer-to-peer or client/server access. The original Windows NT releases contained few differences between server and workstation, and although their feature sets have since been modified to accentuate the differences between the two, any Windows NT machine can share drives and resources with any other. Even a machine configured as a server can be used to access drives on other Windows machines in the same way that a workstation does.
Figure 12.2
The path of communications through the Windows NT protocol stack.
Installing the Microsoft client services on Windows NT consists of procedures that are fundamentally the same as those performed on the configuration of a NetWare server: A LAN adapter driver is installed to directly address the network hardware, then one or more protocols are specified. Driver and protocols are then bound together. A link is thereby established between the physical and data link layers of the OSI model to the session layer and above, by means of the protocol, which occupies the network and transport layers. The theory is the same as in a NetWare network, but where NT excels is in simplifying these tasks so that they can all be accomplished at the same time, using a familiar Windows graphical interface (see fig. 12.3). The Windows NT installation procedure can auto-detect most LAN cards, and even if an older or unsupported card is used, the process is an easy one. Any card for which there is an NDIS driver is usable with Windows NT, and the hardware variables to be configured are, of course, the same as with any NIC installation. The proper settings simply need to be selected from a dialog box, and that part of the procedure is completed.
Figure 12.3
The Network Settings dialog box is where all configuration of the Windows NT networking
components takes place.
The default transport protocol for the Windows network, as you learned earlier, is the NetBEUI Frame (NBF). Selecting any other protocols to be used requires some knowledge of what applications and services are going to be running over the network; bear in mind that additional protocols can be bound to the adapter at a later time by returning to the Network applet in the Control Panel application and modifying the existing configuration. The Bindings button in the Network Settings dialog box provides a visual display of the way in which the various networking components are interconnected (see fig. 12.4). This is particularly useful when multiple LAN adapters and protocols are in use. Up to ten protocols can be bound to any one adapter (though I don't think you can find uses for ten), and multiple adapters, each utilizing multiple protocols if you desire, can be installed onto one machine. Individual bindings can also be enabled and disabled at will, without uninstalling the support files associated with the protocols and adapters, providing a convenient troubleshooting tool for networking problems.
Figure 12.4
In the Windows NT Network Bindings dialog box, clients can be associated with specific
protocols.
In many cases, this is the end of the procedure. Restart the machine, and as long as no error messages appear, support for the Windows network is loaded and operational. Access to specific network resources can then be provided in several different ways, some of which are utterly transparent to the user and others of which require additional configuration. Client/server applications usually operate using one or more of the additional upper-layer protocols mentioned in earlier sections, like Windows Sockets, SMBs, or NetBIOS. In these instances, access to the server portion of the application is automatically provided when the client is installed and executed. For file and printer access, Windows NT can map drive letters to specific network resources, just as in NetWare. This procedure, too, has been greatly simplified by the use of the Windows GUI, in the form of a Map Network Drives window that is functionally similar to the one in Windows for Workgroups or Windows 95.
For a drive or printer on any Windows network computer to be accessible to other users, it must first be shared by the user on the host machine. (These resources often are referred to simply as shares.) Sharing a drive or printer is the process of selecting an object, giving it a name by which it will be known to the network, and establishing security to control access to it from the network. Again, this process can be performed on every networked machine, forming a peer-to-peer network, or only on the drives of certain machines designated as servers, for a client/server network. Whether a particular machine is running the Windows NT workstation or server product is irrelevant, in this respect. Both OSs can share drives and printers and attach to other shares on the network.
Opening the Share As dialog box in File Manager after selecting a drive or directory on a local machine provides the means by which shares are configured for network access. This dialog box prompts the user for a name to identify the share, which may or may not reflect the name of the actual drive or directory. A field for descriptive comments is also provided to help to identify the contents or usefulness of the shared drive. Network users thus can be given access to specific machine resources without them being able to ascertain the actual volume or directory where the files reside.
The Permissions dialog box, accessible from the File Manager's Security menu, allows the owner of the machine to specify which users have access to the resource and the level of access that they are to be granted. The security provisions available in Windows NT are extensive and can be made to function in a manner similar to those of NetWare. User accounts must be created on the host machine, and rights to the shared resources can be controlled if you want to limit users to read-only or another specific type of access. The number of users able to access any particular drive can also be controlled here, protecting performance from degradation based on too many simultaneous accesses.
One of the most immediately perceptible differences between Microsoft and Novell networking is the syntax by which network resources are identified. To those familiar with the traditional NetWare canonical notation, which uses the SERVER/VOLUME:DIRECTORY/FILE syntax, the Uniform Naming Convention (UNC) used by Microsoft networks is basically a different means of expressing the same networking hierarchy. Volume names are replaced by share names, which need not represent an entire subdivision of a server. Let's consider the UNC name:
\\SERVER\SHARE\SUBDIRECTORY\FILENAME
SHARE can represent the root of an entire drive or partition or a single directory on a particular drive, providing access to all the files and subdirectories contained within it. Any other directories on the drive that are not included as part of the share are completely invisible to network users, unless they are shared in a similar manner. It should be noted that SERVER here refers to any machine on the Windows network that has been configured to share any of its resources with other machines. A computer running any network-capable Windows OS can be considered a server, in this respect.
To gain access to a shared drive, directory, or printer, the Connect Network Drive dialog box (see fig. 12.5) is accessed through Windows NT's File Manager. Here, a drive letter is chosen for the mapping, and a browser allows the user to select from all the shares visible on the network. The browser presents an inverted tree-style display, with a root object labeled Microsoft Windows Network. Stemming from the root are all the workgroups and domains containing Windows machines that have been recognized by the network, whether they have been configured to share resources or not.
Figure 12.5
In the Windows NT Connect Network Drive dialog box, you can assign drive letters
to network shares.
Every computer on a Microsoft Windows network belongs either to a workgroup or a domain (even if it is a workgroup consisting only of one machine). Both are logical groupings of computers that allow administrators to organize the computers on the network according to department, location, or any other criteria desired and to provide for the security measures that safeguard the network's resources. Workgroup and domain names, as well as the names of the machines themselves, are created by the user or administrator when the OS is installed or when a domain or workgroup is created. A workgroup is a collection of computers, each of which maintains its own security system. A machine running Windows for Workgroups, for example, can password-protect its shares, allowing network users either read-only or read/write access, depending on the password provided. The Windows NT Workstation OS, however, contains considerably more elaborate security features. User accounts and groups can be created and configured to provide a much greater degree of access control to its shares. Even so, every machine must be individually configured with appropriate accounts for all the users on the network.
This is the inherent drawback of a peer-to-peer network when it grows beyond a handful of computers. Imagine an administrator of a large network having to sit down at every machine on the LAN to create an account every time a new employee joins the company. It is for this reason that the Windows NT Advanced Server (NTAS) product was given the capability to establish domains--that is, groups of computers for which the user account information is stored on one machine, known as the primary domain controller (PDC). Replicas of the user account databases can be stored on other NTAS machines, for fault tolerance purposes. A network user logs on to a domain and immediately receives access to all the network resources allotted to him that are contained within it. This obviously is more in keeping with the client/server networking model.
Despite their differences, however, workgroups and domains behave identically within the tree display of the Map Network Drives browser. Each can be expanded to show all the machines within that workgroup or domain, and each machine can be expanded to show all the shares that it makes available to other users. Differences in functionality between workgroups and domains might arise when actually attempting to map a drive to a shared resource. A domain user that has already been granted access to the share will see the drive mapping take effect immediately, but in a workgroup, users might have to supply passwords before each individual share is mapped. Once a share is mapped to a specific drive letter, that drive appears in File Manager and in every Windows drive letter pick list. It can be accessed, and its contents manipulated, just as if it were a local resource (assuming sufficient access rights are provided). If the Reconnect at Logon option is enabled, then the access passwords provided are saved to an encrypted file on the local machine, and this drive mapping will be restored each time that computer is started. Unless access is interrupted at the source, this is a permanently available resource for that user.
Printers are shared and mapped in much the same way, except that you use the Print Manager application. The same naming convention shown above can apply to a printer as well as a drive or directory. There are no subdirectory or file specifiers needed, so the syntax is as follows (SHARE is the name given to the printer when the local user shares it):
\\SERVER\SHARE
As a result of these features, Microsoft networks contain a great degree of flexibility in terms of user interaction with the network. Domain user accounts and logon scripts can virtually duplicate the functionality of NetWare, if desired, mapping all of a user's network drives and printers and providing a ready-to-work environment. A greater capacity for self-configuration of network access is also available, however, within the Windows GUI environment. Unlike NetWare networks, in which users are restricted to accessing dedicated file servers over the network, users of a Windows network can quickly and easily share files on their local drives with other users. This is where the term workgroup computing really makes sense. Network users in an organization frequently work closely together in teams, sharing and developing the same resources, and the mixture of peer-to-peer and client/server functionality provided by Windows NT and the other Windows NOSs is ideal for this sort of interaction.
As we have seen, creating a Microsoft-only network is a relatively simple matter. The vast majority of networks containing Windows NT workstations, however, also have one or more NetWare servers on them, and the NT users nearly always require access to some of the resources provided by NetWare. Many installations position Windows NT Advanced Server as an application server platform, leaving the basic file and print services to NetWare. This means that NetWare resources may be accessed by the NT server, as well. Therefore, for Windows NT to be fully assimilated into a heterogeneous network, both as a server and as a workstation OS, support in two directions must be provided: NetWare server access to Windows NT clients, and NT server access to NetWare clients. This can be accomplished in different ways, based on several important factors, the most significant of which is the state of the professional relationship between Microsoft and Novell.
These two software giants, while clearly competitors in the networking field, are forced by reasons of practicality to work together to some degree. After all, the vast majority of NetWare clients are running a Microsoft OS on their workstations, and Microsoft cannot expect to effectively assault NetWare's overwhelming market share by denying that other NOSs exist. The number of Microsoft-only networks that have not been migrated from NetWare is very small indeed. It therefore is agreed by both companies that interoper-ability between their products must be achieved, but the logistical details, such as who is going to write the client software and when, have been a source of long-standing disagreement.
It originally was assumed that Novell would create the requester for the Windows NT operating system, but when delays, as well as some highly problematic beta versions, appeared, Microsoft undertook the task of designing a NetWare client itself. Windows NT 3.1, therefore, shipped without integrated NetWare support, but one of the most important pieces toward that end, the NWLink protocol, was already in place. Providing full 32-bit IPX functionality in the network and transport layers, NWLink was a vital tool needed to provide NetWare connectivity, but by itself, it could not handle the NCP packets that are the primary component of NetWare's client/server traffic. For this, a requester was needed, operating at the session layer and above, which could access NWLink through the TDI.
Microsoft released such a requester as a free, downloadable add-on to the Windows NT 3.1 OS, and beginning with version 3.5, it was included as part of the shipping product. This requester, originally called NetWare Workstation Compatible Service (NWCS), was very efficient at providing basic functional access to NetWare resources. It operated alongside the native NT client, allowing NetWare drives to be assigned to drive letters just as NT drives could be and providing full access to NetWare-based printers and other resources at performance levels that were virtually indistinguishable from those of the Microsoft network resources.
There were some drawbacks, however. First, it was required that NWCS be run along with the native Microsoft client services, even if both were utilizing the same transport protocol. (Remember that the TDI effectively isolates the requester from the protocol stack.) NWCS could not be used in place of it, thus raising the minimum memory requirement for Windows NT to 16M. This, however, is not nearly as great an issue as it is in the DOS or Windows 3.1 world, in which running additional client software for several networks can mean utilizing large amounts of precious conventional memory for TSR drivers. Windows NT's 32-bit flat memory model allows sufficient memory to be allocated for the additional drivers, as needed. More memory might be required in the machine, but there are no complex memory optimization chores to be performed by the user.
Despite lower official recommendations, 16M should be considered the absolute practical minimum for a Windows NT workstation today. Moreover, the benefits in speed that are realized when memory is increased beyond this point are significant enough to make it well worth the investment. With the release of Windows 95, Windows NT Workstation is coming to be used more often as a workstation OS for power users, due in part to these greater hardware requirements. As with many OSs, greater performance levels can be more readily achieved through the installation of additional RAM than through any other upgrade.
The second major problem with the NWCS requester is that no support is provided for the execution of NetWare logon scripts. This is unfortunate, as it means that any mass migration of workstations to Windows NT requires the individual reconfiguration of drive mappings and other environmental settings into NT logon scripts for each node. Virtually the same functionality can be provided by the NT equivalent script, but the conversion process can be lengthy and problematic. In addition, no support is provided for logging on to the NetWare Directory Services database. This means that not only are the resources provided to a Windows NT user by the NDS limited to those available under bindery emulation, but the NDS configuration utilities, such as CX, NWADMIN, and NETADMIN, cannot run on Windows NT using its native NetWare client. These are serious drawbacks for the network administrator that can (and have) prevented wholesale conversion to Windows NT in many cases. Both are currently being addressed by Novell and Microsoft; this is discussed later in the chapter.
Remote Access Service. Another popular feature built into Windows NT from its inception was the ability to provide remote or mobile users with access to the network through Remote Access Service (RAS). RAS consists of a service that runs on an NT Server (with the appropriate communications hardware) and an RAS graphical phone book that runs on any Windows for Workgroups, Windows 95, or Windows NT workstation. The connection to the remote machine can be made using asynchronous modems, ISDN, or X.25 wide-area links. RAS provides the remote user with complete (albeit slower, in most cases) access to all the same network resources available to a LAN-connected client. It should be understood that RAS provides a true network connection to the remote user. It is not a remote control solution, such as PC/Anywhere or Carbon Copy, in which keyboard, mouse, and display signals are redirected to a remotely located machine. The RAS server's processor is devoted to communications tasks, and any applications accessing network resources from the remote workstation are actually running on the remote workstation's processor.
Users of Windows NT 3.1 were very enthusiastic about the RAS feature, but when the NetWare client became available, they were troubled to discover that the RAS connection could support only SMB traffic. NCP packets could not be relayed in this manner, preventing remote users from accessing NetWare resources. This was considered another major shortcoming of Microsoft's NetWare requester, and the problem was subsequently addressed by the addition of a gateway feature to beta versions of the client that could translate between the SMB and NCP protocols. This allowed the RAS host server to literally become a client of a NetWare server and reshare the NetWare drives and other resources to its own remote clients. Obviously, the translation mechanism entailed some further performance degradation, but access was successfully granted to resources that previously were unavailable.
This feature was subsequently removed from the NWCS client software package and included as part of the Windows NT Advanced Server 3.5 product as the NetWare Gateway Service. By doing this, Microsoft took a significant step toward differentiating the NT server and workstation products, but more importantly, it provided this gateway service to all the clients on the network, even those not running a NetWare requester themselves. This can be seen as extremely advantageous, in several different ways. For clients running only Windows network drivers, access to NetWare resources can be provided without the need for reconfiguring the client workstation--allocating more of its memory for the additional client software--or utilizing an additional NetWare server connection. For example, in the case of a standard Windows for Workgroups workstation, only the protected-mode Windows network drivers have to be loaded or configured. There is no need for the NetWare real-mode ODI client software, resulting in significant savings of both conventional memory and the time that would have to be spent configuring the machine for the use of both clients. As far as the NetWare server is concerned, there is only one connection being utilized--that of the NT server, which logs on using a normal account and the regular NWCS client. Dozens or hundreds of NT client users, however, can access the NetWare server through that one NT gateway.
Again, there is a performance hit involved, and it certainly increases as more clients utilize the gateway. Moreover, there is little reason for Windows NT or Windows 95 workstations to use the gateway, when they can so easily install the full client services themselves. For workstations that require only occasional access to NetWare resources, however, this solution is ideal and very economical. NetWare drives and printers appear just as though they were normal shared resources on the NT server, leaving end users unaware that they are even accessing NetWare devices. This can save the cost of additional training for end users and can also be a powerful tool, enabling network administrators to perform a gradual migration from NetWare to Windows NT. The client software on a company's workstations can be converted from NetWare to NT, with both server types remaining active until the process is completed. This is preferable to a mass migration in which all the workstations would have to be reconfigured at once.
Thus, Windows NT's NetWare Gateway and RAS are two elements that help to provide network administrators with a great deal of flexibility in their selection of network client software for their workstations. As with most software products that are in the relatively early stages of development, the aim of the manufacturer is to provide a set of tools to users and then observe how those tools are best utilized in real-world situations. The continued development of tools like these depends on their popularity with users and the additional functionality requested by those users.
Novell NetWare Client for Windows NT. Due in no small part to user requests and despite its late appearance, there is now a 32-bit NetWare client for Windows NT that has been produced by Novell. It is free for downloading from any of Novell's online services and consists of the client software itself, as well as 32-bit versions of RCONSOLE and NWADMIN, the GUI version of the NetWare Directory Services administration program. As the inclusion of NWADMIN implies, this Novell client is now capable of logging users on to the NetWare Directory and providing them with access to all their defined NDS resources, something the Microsoft Client Services for NetWare is not yet capable of doing. Apart from this feature, however (which is surely one of major importance to many users), there are very few persuasive reasons to utilize Novell's client instead of Microsoft's, and there are several good reasons not to.
First, the selection of a NetWare client is very much an either/or situation. If the Microsoft Client Service for NetWare has been previously installed, all vestiges of it must be removed from the system configuration before you install the Novell client, including all NetWare printers, drive mappings, and the Gateway Services for NetWare. The files need not be deleted, but the client service must be removed in the Network dialog box of the Control Panel. Severe problems can result if this is not done, in some cases requiring a complete reinstallation of the OS. There are no such vital concerns, however, when switching from the Novell client to the Microsoft client for NetWare.
Second, Novell has packaged the client files in a manner that provides for a needlessly annoying installation procedure. Considering that the vast majority of the software's users are obtaining it through a download from an online service, it is odd for Novell to require that installation floppies be made. The two self-extracting archive files that are downloaded expand into other archives of the installation files, along with instructions in the form of a Windows HLP file and a utility to make disks, which is the only ready method of extracting the actual installation files from the archives. Network administrators, most of whom are about to install this client on multiple machines, are forced to make a floppy disk set to copy the actual installable software back to their network drives. This is the equivalent of insisting that, if I decide to buy a new Chevrolet, I must walk to the dealership to pick it up, rather than driving my old Ford.
The 32-bit version of the NWADMIN program, which also must be extracted onto floppies, can be installed only through the INSTALL.NLM utility on the NetWare server, which is another odd requirement since the installation procedure does nothing more than copy files to the server drive. Once the files are extracted, the installation of the client proceeds easily enough. Added as a service through the Control Panel in the same manner as the Microsoft client, the Novell software does not call for any unusual configuration procedures. Novell's client can utilize an NDIS driver for the NIC or one of the 32-bit ODI drivers included with the client software. If the Microsoft Windows network client is active, then an NDIS driver has already been installed, which can be used to drive both services simultaneously. Novell recommends the use of an ODI driver, citing increased levels of performance, but admits to including 32-bit ODI support for only a very limited number of network adapters in the current release of its NT client (and many of these are several years outdated). Use of an ODI driver instead of an NDIS one also prevents users from logging on to their Windows NT domains. In addition to this, there was a well-publicized bug in the initial release of the NDS client involving the use of NDIS drivers when attaching to NetWare 3.11 servers. Attempts to access the directory structure on these servers were producing errors in the NT File Manager. A patch was released to address the problem--it, along with other patches, is in an archive named NTC3.EXE, available from the various Novell online services.
After the installation process, the Novell NetWare banner appears whenever the Windows NT system boots, and then a Logon dialog box appears in which the user enters an NDS tree name, a preferred server, and the server context. This is in addition to the standard Windows NT client logon; both must be completed whenever the system is started. No browsing ability is provided for the context, which, unlike Novell's real-mode clients, must be entered in full to log on to the directory. The Novell client adds a NetWare applet to the Control Panel, which displays the server drives to which the workstation is currently attached and allows for the configuration of the standard NetWare printing options, such as the inclusion of a banner page at the beginning and a form feed at the end of each print job.
Once the NWADMIN program has been installed on a NetWare server, a program icon to run it must be manually created on the Windows NT desktop. Once launched, NWADMIN is identical in features and operation to the 16-bit version included with NetWare 4.x, right down to its somewhat sluggish performance. The administration capabilities of NWADMIN, and the access to network resources provided by the Directory logon, comprise the entire NDS functionality of the Novell client. In fact, no support at all for the NetWare API is provided in the Windows NT MS-DOS session. A separate DOS Support program icon is created by the client installation that must be used to open a DOS session that is capable of running NetWare command-line and menu-based utilities such as MAP and PCONSOLE.
What's more, the DOS Support program provides a window that operates as a completely separate network environment from the Windows NT GUI. After launching the program, the user must manually change to the default network drive and log on again. Unlike the main NDS logon, there is support for logon scripts here, but the DOS Support program, oddly enough, is limited to Bindery Emulation mode, and therefore only bindery logon scripts are supported. NDS utilities, such as CX and NETADMIN, cannot run within this interface, and the user is limited to accessing only the resources in the current server context. In addition, no drive mappings or other network settings are carried over from the main NT session, nor are any settings that are modified while in the DOS Support program propagated back to the rest of the OS. Overall, this seems like a thrown-together system, more of a stopgap workaround than a full release. The client does not provide a convenient environment for NetWare administration tasks, which is the main reason why anyone would choose it over the Microsoft Client for NetWare.
One interesting benefit in the DOS Support program is that, due to its complete isolation from the rest of the NT environment, it is possible to log on to two different servers and execute different logon scripts by opening two separate DOS Support windows. On a network such as mine, which is divided into separate Production and R&D domains, with a single server providing routing between the two, it is possible to log on to a gateway server for each domain, providing access to both at the same time, a trick that could not be accomplished with any other client, on any OS. This is not a typical working situation, though, and it certainly was not enough of a benefit to persuade me to leave the Novell client on a production NT machine. Perhaps the most telling assessment of the client is that I could not get it off my systems soon enough for my taste--a process which, incidentally, led me eventually to reinstall the OS, rather than troubleshoot a series of system peculiarities that might or might not have been directly related to the Novell client.
As far as access to NetWare resources through the standard Windows NT interface is concerned, the Novell client behaves in much the same way as the Microsoft version. Drives are mapped within File Manager through the regular Map Network Drives dialog box, and printers can be attached either through Print Manager or from the NetWare applet in the Control Panel (which provides for capturing LPT ports). An expandable NetWare Directory Services tree entry is provided in the Print and File Manager browsers, along with a NetWare Servers listing, from which objects can be selected for access. Printers outside of the current context, however, cannot be seen. The context must be changed through File Manager or the Network applet to provide access to outside printers.
The Network applet is also the place where many of the client settings that normally would be included in a DOS/Windows workstation's NET.CFG file can be adjusted. This is done by selecting the various components of the NetWare client and clicking the Configure button. For example, under Novell NetWare IPX/SPX Transport, the Frame Type, SPX connections, retries, and Watchdog settings can be modified. The Preferred Tree, context, and burst mode settings can be altered by configuring the NetWare Client Services entry.
Although NetWare drive mappings made with File Manager are retained across Windows NT sessions, just as those of the Microsoft client are, there is no provision for the processing of NetWare logon scripts during the main NDS logon. NT's user profile scripts can emulate some of the NetWare logon script functions, including the mapping of drives (with the NET USE command) and network search drives can be permanently established by adding them to the system environment path in the System applet of the Control Panel, but this does not avoid the fact that individual environments must be configured at each workstation, just as though a network is being built from scratch. Any large-scale migration to Windows NT workstations on a NetWare network would, therefore, not be facilitated in any way by the use of this client. Also, no support is presently included for the Windows NT RAS feature, although this is promised for a later release. Remote network users are limited to accessing only Windows resources when they attach to a Windows NT server running this NetWare client.
Thus, in general, the Novell NetWare Client for Windows NT offers little to recommend it to the average user. Its overall performance is perceptibly slower than that of the Microsoft Client for NetWare, and several significant bugs have been registered by users and addressed by Novell in various patch releases. Even the NetWare administration capabilities that one would expect to see, due to the inclusion of NWADMIN, are severely limited. Until these issues are addressed and complete support for the entire collection of NetWare utilities is provided, there still will be a need for a Windows 3.1 workstation on a NetWare administrator's desk. In that case, it probably is preferable to enjoy the increased performance and unified NetWare API support that the Microsoft NetWare Client provides to the Windows NT environment.
Appearing more than a year later than the Microsoft version, this initial release of the Novell client was a major disappointment to a great many Windows NT and NetWare Directory Services users. Hopefully, improvements in both stability and capabilities will be realized in the near future. Novell promises to include global NDS support in future releases, as well as support for NetWare Connect and the Packet Signature security options. In the meantime, however, Microsoft has announced its intention to develop its own NDS-compatible NetWare Client for Windows NT. Few companies outside of Novell have yet proven themselves capable of writing software that fully supports the NetWare Directory. Indeed, even Novell appears to be having trouble in this respect. But if, as we shall see later in this chapter, Microsoft is capable of writing Windows client software that can execute NetWare logon scripts, while Novell seemingly cannot, then perhaps Microsoft is up to the task.
File and Print Services for NetWare. In the same way that Microsoft's Gateway Services for NetWare provides Windows network users with access to NetWare resources, a product named File and Print Services for NetWare (FPSN), soon to be released by Microsoft as an add-on, allows NetWare workstations to gain transparent access to Windows NT resources. FPSN accomplishes this by making a Windows NT server appear to NetWare workstations just as though it is a NetWare 3.12 server on the network. NetWare users can see the server with the SLIST command and log on to it just as though it were a NetWare server, gaining access to its shared drives and printers within the native context of their workstation environment. Like the Gateway Services, this is an extremely valuable tool for a network that is undergoing a gradual migration between NOSs. NT servers can be added to an existing NetWare network and accessed without the need to reconfigure all the workstations to use two different clients.
It must be stressed, however, that as the name implies, this product only provides users with access to Windows NT file systems and print queues in the context of a NetWare server. It is not a means to run NLMs or other NetWare services on a Windows NT machine. FPSN does, however, allow NetWare client workstations access to any other Windows NT application services that may be running on the server. In addition, they can be given access either to NetWare-compatible printers on the network or to printers connected locally to the Windows NT machine.
For a network site that is switching from NetWare to Windows NT as its primary NOS, the combination of FPSN and the Migration Tool for NetWare, which ships as part of the NT Advanced Server product, allows for a simplified migration of NetWare file systems, user and group accounts, security, and permissions to a Windows NT machine. The Migration Tool can replicate NetWare files, directories, binderies, and logon scripts to a Windows NT server with complete safety. A "pre-flight" feature allows for the creation of a log that details the exact changes that will be made by the process before it is actually performed. Of course, this is not possible when a single computer is going to be migrated from NetWare to Windows NT. The process must be performed on two separate machines, the original NetWare server and a Windows NT machine with enough disk space to hold the entire contents of the NetWare server volumes to be migrated.
Once the migration has been performed, the installation of FPSN creates a directory named \SYSVOL on the Windows NT server that simulates the actual directory structure of a NetWare SYS: volume. This directory, therefore, contains \PUBLIC, \SYSTEM, \LOGIN, and \MAIL directories, and utilities are furnished with the product that precisely simulate the performance of their familiar NetWare counterparts--ATTACH, LOGIN, LOGOUT, MAP, SLIST, CAPTURE, and so on.
FPNW also adds extensions to the Windows NT User, Server, and File Manager applications to allow for the administration of NetWare users in a manner similar to that of an actual NetWare server. An Enable NetWare Access right is added to the User Manager, and standard NetWare account management attributes, like grace logons, station and time restrictions, and intruder lockout policies, are all present. Also, by deploying the Windows NT Directory, users (even NetWare users running the NETX shell) can access all the resources in the enterprise with a single logon, and the account can be replicated among Windows NT machines for fault tolerance.
Thus, with a combination of the tools described above, even large networks can be migrated to, or integrated with, Windows NT servers and workstations in a planned and methodical manner. One server at a time can be moved to Windows NT, if desired, or NT servers added, and NetWare user accounts replicated until administrative personnel have been trained, native NT account policies have been created, and workstation client upgrades have been performed. Microsoft has come to realize the gravity of the decision to change NOSs, and it has made a great effort to facilitate the process, by providing administrators with client and server tools that can be adapted to almost any existing network environment.
Windows 95 was planned, from the outset, to be the ultimate network client. Microsoft has made it compatible with virtually every NOS in use today and has simplified the configuration of network services even more than in Windows NT. The simplest way to achieve network connectivity on a Windows 95 machine is to install it on a machine that is already a functioning network client. The setup routine autodetects a wide range of NICs and their hardware settings, acknowledges the existing network client software, and upgrades it accordingly. For NetWare, Windows, and TCP/IP network users, the 32-bit protected-mode clients that ship with Windows 95 are, quite simply, the fastest and most easily manageable network clients available today. Network services have been fully integrated into the OS, avoiding the performance delays and conventional memory requirements of the TSR network drivers that were needed in the past.
An upgrade to Windows 95 migrates any non-standard settings and parameters found specified in Windows INI or NetWare NET.CFG files to the Windows Registry; these are accessible through the Registry Editor or through the Network tabbed dialog box in Control Panel, which provides a far more elegant and functional window into the workings of the network software. Like the Windows NT applet, the Windows 95 version lists each network client, adapter, protocol, and service that has been installed (see fig. 12.6).
Figure 12.6
The Network tabbed dialog box, accessed through Control Panel, is the central interface
for all of the operating system's networking components.
Unlike NT, however, which provides a single unified (and sometimes confusing) Bindings dialog box for all the network components, Windows 95 has a Properties sheet for each component that contains not only all the adjustable parameters for that module but an individual Bindings tab that displays, for example, all the clients that are utilizing a particular protocol or all the protocols that are bound to a particular adapter. This allows for simplified troubleshooting of network communications problems. For example, examining the bindings for the IPX/SPX protocol (see fig. 12.7) shows whether or not it is being used by the Microsoft network client, perhaps explaining why only workgroups on the local network segment are visible in the browser (since NetBEUI is not routable).
Network-related services also are visible through the Network tabbed dialog box. Services are software modules that are functionally equivalent to TSRs, in that they are always available for use by any part of the OS but without the drawbacks in conventional memory usage to which TSRs usually are subject. For example, Windows 95 (on CD-ROM) ships with services that function as client agents for network backup packages by Cheyenne Software and Arcada Software, as well as printer control software by Hewlett-Packard. A service can be made permanently available (allowing system backups or printer control at any time) without the need to launch an actual application--and without the performance hit that such a launch entails.
Figure 12.7
Here, the Bindings tab has been selected to reveal particular information that can
help with troubleshooting.
For power-users, access to all of the workstation's configuration data is available through the Windows 95 Registry Editor (REGEDIT.EXE). This program provides an expandable tree view of all the settings that would have been included in INI files in the 16-bit Windows OSs and a great deal more. All the settings that are adjustable in Control Panel are also available here, albeit in a far more cryptic format. It is extremely important to know what you are doing before making any changes to Windows Registry settings. What you don't know here can hurt you a lot!
Unlike Windows 3.1, where you could always boot to DOS and tinker with INI file settings, there is no direct access to the Windows 95 Registry from the command line. If you make a change that prevents the Windows GUI from loading, then running REGEDIT.EXE from a DOS prompt allows a backup copy of the Registry to be imported, but no actual editing of the data is possible. It should also be known that the actual Registry data files, named USER.DAT and SYSTEM.DAT (and stored as hidden files in the \WINDOWS directory), are automatically backed up to files with the extension DA0, whenever changes are made to them. This provides a means of reverting to the most recent configuration at any time. Many of the hundreds of Registry settings are described in the Windows 95 Resource Kit, but changes should only be made in response to a particular problem or situation in which the precise effect of the change you're making has been fully researched; otherwise, extremely unpredictable behavior may result. In any case, it is recommended that the Export Registry feature be used to save a functional copy of the Registry files before you conduct any experiments.
As with Windows NT, the native Windows 95 client for Microsoft networks is a 32-bit, protected-mode service that provides both peer-to-peer and client/server functionality, allowing connections to be established to Windows NT, Windows for Workgroups, and other Windows 95 machines, as well as to other SMB-based servers such as IBM LAN Server, LAN Manager for UNIX, DEC PATHWORKS, and AT&T StarLAN, as long as both machines are using a common protocol. When the File and Print Sharing for Microsoft Networks feature has been added to the network client, Windows 95 workstation resources can be shared with other network users by means of individual passwords for each share (in the Windows for Workgroups model) or by user-level access, in which the user and group accounts defined on a Windows NT server that has been designated a primary domain controller provide security. The latter technique is also known as pass-through validation.
Access to all available shares on the network is provided through a unified file system in the form of the Windows Explorer, which in the Network Neighborhood provides seamless file management capabilities to all available shares without even the need for drive mapping. Early add-on products for Windows 95, such as Norton Navigator, even integrate FTP services into this metaphor (for workstations connected to the Internet through TCP/IP), allowing access to remote systems as easily as to local ones, without the need for an external application. The Windows protected-mode clients are able to use the same 32-bit caching (called VCACHE) as the rest of the Windows file system, improving network performance by storing the most recently used data in memory. Long file names of up to 256 characters--one of the most popular features to users of the Windows NT and Windows 95 OSs--are viewed, transferred, and manipulated easily between different machines on the Windows network.
Another new feature of Windows 95 is the capability for the storage of user profiles on the network. User profiles are collections of the drive mappings and desktop configuration settings for a particular user. In this way, the configuration of a Windows 95 machine can be varied according to the name of the user that logs on to it. A network administrator can, therefore, log on to any machine on the network and immediately receive access to all the tools and resources needed to perform the task at hand. Likewise, users of varying security levels or departments can switch Windows 95 machines for any reason and not have to completely re-create their individual preferences on the new workstation.
Various hardware profiles can also be created for instances when different sets of hardware are used with the same computer at different times. If a portable computer is sometimes used with a docking station, for example, then drivers and configuration settings for two different display options, keyboards, and network connections can be loaded, depending on whether or not the computer is docked.
Dialup network access is built into Windows 95, as it is with Windows NT. In Windows 95, however, it is configured just as any network adapter would be. Specific clients, protocols, and services can be bound to the dialup adapter so that the connection process is automatically initiated when access to certain network resources is requested. Windows 95 machines can also be configured as dialup servers, using additional software included in Windows 95 Plus! Thus, Windows 95 home or mobile users can easily dial into their office networks and be provided with the same network access that they would have if directly attached to the LAN (subject to the speed limitations of the connection).
NIC support is also excellent. 32-bit NDIS 3.1 drivers are included for a wide selection of adapters, including PC Card and parallel port products, but 16-bit real-mode NDIS or ODI drivers can also be used, yielding a lower level of performance but providing almost universal compatibility. The auto-detection mechanism also functions quite well, successfully identifying many NICs with sufficient accuracy to allow a connection to the network. When hardware fully conforming to the Plug and Play standard becomes common, the process will become even easier.
In short, for Windows network users, there is no reason not to use the Windows 95 client. Its overall performance is excellent, whether connecting to a peer Windows 95 machine or an NT server. Security capabilities are extremely flexible, allowing the caching of passwords to be disabled, if desired, thus forcing users to log on to remote resources each time the machine is started. The full complement of Windows NT security mechanisms, as well as the NT Directory, can be used to provide detailed access control to a network of Windows 95 machines.
Fault tolerance for network performance is well-realized. If a connection to a shared network resource is interrupted for any reason--a file server goes down or a portable computer is detached from the network and carried across the room--both continue to perform as stand-alone machines without interruption. When network service is later restored, the client immediately reestablishes the connection, allowing the user to resume network access without any indication or delay. The addition of support for other networks, clients, protocols, or services is easily accomplished, with no apparent ill effect to the Microsoft client. There are limitations with respect to other network clients, as we shall see in the following sections, but as far as its native networking capabilities are concerned, there is little that Microsoft could have done to create a better client.
Of course, the majority of Windows 95 users are not connecting only to Windows networks. The real test of the OS's networking comes in its ability to connect to NetWare servers, and with a few notable exceptions, Microsoft has done an excellent job here as well. Windows 95 ships with a 32-bit, protected-mode client for Novell NetWare that functions as a counterpart to the Windows network client. The two easily share the same NDIS 3.1 board driver that ships with the OS and can also share the services of the transport protocols installed on the machine. For example, the NetWare client requires the use of the IPX/SPX-compatible transport supplied with the OS, but this protocol can also be used by the Windows client to route NetBEUI traffic between network segments.
Microsoft Client for NetWare Networks. The Microsoft protected-mode NetWare client ships with the Windows 95 release and is installed in the same manner as the client for Microsoft Networks. It appears as one of the installable services in the Network tabbed dialog box of the Control Panel, and installation can often be as easy as select- ing the service, specifying a preferred NetWare server, and rebooting the workstation. The protected-mode client is also, in most cases, installed by default when an existing NetWare workstation running one of the NetWare real-mode clients (NETX or VLM) is upgraded to Windows 95. The setup routine will rem out all the old network components from the workstation's AUTOEXEC.BAT file, modify the existing SYSTEM.INI file, migrate the settings found in the NET.CFG file to the Windows 95 Registry, and install and bind the appropriate protocols to the new NetWare client. Any existing networking component files (such as NETWARE.DRV) that are overwritten during the installation process are renamed with a tilde (~) in place of the last character in the extension, so a return to the original configuration is never hampered by the deletion of necessary files.
In most cases, it is preferable to utilize the protected-mode client whenever possible. It provides superior network performance without the memory utilization problems of the multiple TSRs needed for NETX and VLMs. NetWare API support is provided to Windows DOS sessions, allowing the use of nearly all NetWare command-line and menu-driven utilities (the exceptions being the NDS-related modules). The client supports the NCP Packet Burst mode as well as Large Internet Packets. Even the long file names that are native to Windows 95 machines can be stored on NetWare volumes, as long as they have been properly configured for the OS/2 name space.
Storing Long File Names on NetWare 3.11 Servers
Please note that the NetWare 3.11 release shipped with an OS/2 name space module that incorrectly stored long file names. A patch named OS2OPNFX.NLM must be applied before the OS/2 name space will function properly. This file is available from NetWire in an archive named 311PTD.EXE.
For this reason, Windows 95 will not by default write long file names to NetWare 3.11 server volumes. Standard DOS 8.3 file names are written instead. Once the patch has been applied, this default can be modified by adding the following section to the workstation's SYSTEM.INI file:[NWREDIR] SupportLFN=2or by modifying the following Windows Registry setting:
Hkey_Local_Machine\System\CurrentControlSet\Services\VxD\NwredirThe possible values for this Registry key are
0 This prevents all long file names from being written to NetWare servers.
1 (default) This allows long file name support on NetWare servers version 3.12 and greater.
2 This allows long file name support on all NetWare servers that have OS/2 name space.
Unlike the Windows NT clients available from both Novell and Microsoft, the Windows 95 client for NetWare is capable of processing the bindery logon scripts associated with NetWare user accounts. Although this feature is not yet 100% accurate (problems with certain IF...THEN statements have been noted, for example), it is an excellent sign of the advancements being made by Microsoft in the area of client software design. The protected-mode client, at this time, also does not provide support for the NCP Packet Signature security options, NetWare IP, or IPX checksums, but these are relatively minor matters that do not significantly affect a large number of users.
As with the Windows network client, NetWare passwords can be cached by the Windows 95 operating system (if you desire), allowing for quick access to network drives in future logons. Network users are even provided with a choice of whether or not they want their network drives to be actually attached when the system is booted, or whether mappings should be performed, and attachment delayed until access to each device is individually requested. This provides a tradeoff between additional speed at boot time versus quicker initial access to network drives, depending on the user's preference. Microsoft even includes a protected-mode equivalent of the NetWare RPRINTER utility with Windows 95. NetWare print queues can be despooled to printers attached to a Windows 95 workstation.
Another excellent feature of the Microsoft client for NetWare is the safe mode that can be used in situations when a malfunction prevents the Windows GUI from loading properly. Safe mode can be selected from a list of startup choices that appear when the F8 key is pressed while the system is booting. When safe mode is selected, access to the network is granted using a real-mode client that does not support the advanced features of the Microsoft client such as long file names, packet burst mode, and auto-reconnection to servers but does provide emergency access to the network in situations that prevent the fully functional Windows interface from loading. Options like this are part of Microsoft's attempt to overcome the inherent limitations of the GUI. When an ancillary component such as a video display driver fails to function, the GUI might be inaccessible and an alternative means of accessing the operating system must be provided. The client's safe mode allows the additional benefit of network access, so that support personnel can access replacement drivers or diagnostic tools that can be used to remedy the problem.
File and Print Sharing for NetWare Networks. For a Windows 95 machine to operate in peer-to-peer mode with other workstations--that is, to share its drives and printers-- a network service named File and Print Sharing for Microsoft Networks must be installed along with the Windows client. Also present in the pick lists of services that ship with the Windows 95 product is File and Print Services for NetWare Networks. In comparison with the features provided by its Microsoft counterpart, this may seem odd. A peer-to-peer function for NetWare? Actually, this service is a fully realized, fully integrated Windows 95 version of the FPNW add-on module for Windows NT.
Installing this service, which requires that File and Print Services for Microsoft Net- works first be removed, allows any Windows 95 machine to appear on the network as a NetWare 3.12 file server. The installation process creates a subdirectory under \WINDOWS named \NWSYSVOL, which becomes the root of the "server's" SYS: volume. Any other shares that are created on the machine's drives become additional volumes. SAP packets can (optionally) be generated to advertise the machine's presence on the network, using the Windows machine name as the server name. Likewise, the share names become volume names.
Use of this feature requires a NetWare server to provide pass-though security validation. Just as a Windows 95 machine can access an NT domain server's account information, File and Print Services accesses the bindery of a NetWare 3.1x server to extract user and group information to provide access to the Windows 95 "server." There is no share-level password protection provided. Once a preferred NetWare server is specified, its bindery is accessed, and its user list presented on the Windows 95 machine. Users can then be selected and provided with read-only access to shared drives, full control of them, or customized access based on the standard set of NetWare file attributes.
Once this has been done, a user at a workstation running only a standard real-mode NetWare client can enter the SLIST command and see the Windows 95 machine on his list of servers (assuming that the creation of SAP packets has been enabled). The only indication of abnormality on the server list is the inclusion of the Windows 95 machine's full network and node addresses, as opposed to the listing of the internal IPX addresses for the real NetWare servers. The user can logon to the "server," watch his logon script run, and then manipulate files or print to printers just as though it actually was a NetWare server. In fact, except for subtle indications, such as the server listing cited above, it would be easy to mistake the Windows 95 machine for an actual NetWare server. The performance is that good. It is even possible to perform a backup of the Windows 95 machine using network backup software to address it as a server.
Of course, many of the NetWare server utilities are useless here. Users are created through the Windows 95 interface, not SYSCON, and PCONSOLE is not operational. It also cannot be forgotten that this feature provides file and print services only. There is no way to run NLMs on the Windows 95 machine. This spoils the ability to back up the "server," because a NetWare Target Service Agent cannot be loaded that would allow Windows 95 long file names to be successfully written to tape. Copy operations from the "server" to another Windows 95 or Windows NT machine--or an actual NetWare server (with OS/2 name space)--do preserve long file names properly.
While Microsoft is attempting to position the NT version of the FPNW feature as a transitional tool to aid in migration from NetWare to NT, the real power of its functionality is clear in the excellent performance of the Windows 95 version. Each Windows 95 machine running File and Print Services for NetWare appears to the network as a 250-user NetWare server, yet it utilizes only a single connection to an actual NetWare server. In this way, file and print services for an almost unlimited number of users can be provided for the price of the hardware plus a single NetWare server license. When it is made available on the Windows NT platform, then NT's own client/server application functionality, as well as file access and printing, will be available to the NetWare clients.
Other NetWare Clients. As with Windows NT, there has been a certain amount of confusion regarding whether Novell or Microsoft will be the primary supplier of NetWare client software for Windows 95. At this time, both companies are well into their individual client development projects. If nothing else, this should provide users with a range of choices to select from, as the development projects seem to be aimed in different directions, despite the basically similar tasks to be performed. This is an important point, because the Windows 95 NetWare client, while very well-realized for an initial release, is not yet complete. The protected-mode NetWare client supplied by Microsoft does not yet support NDS. This is a crucial element if Microsoft's plan to dominate the network desktop is to succeed. Both Microsoft and Novell are currently developing clients for Windows 95 that will be NDS-compliant, but in the interim, a significant number of users are compelled to utilize the standard Novell real-mode VLM client for NetWare on their Windows 95 machines.
Windows 95 and Real-Mode NetWare Clients. In its quest to create an OS as compatible with existing hardware and software as it could possibly be, Microsoft was wise to leave in the option to use a workstation's existing NetWare client software. While the lack of NDS support in its own client was no doubt a substantial factor in this decision, it also was a functional safety measure, in case Microsoft's NetWare client did not turn out to be as successful as it did. It must be remembered that, despite the massive beta testing program, Windows 95 was a tremendous gamble. Few software developers are able to anticipate the problems that will occur with their products once they are released to market.
NETX. Windows 95, therefore, runs with either the NETX or VLM real-mode Novell clients without any alteration to them. Because of the excellent performance of the Microsoft Client for NetWare, the only valid reason for anyone to be using NETX with Windows 95 would be to support a networking TSR that could function with no other client. If a network adapter was being used that did not have an NDIS 3.1 driver available, it would only be inertia on the part of network administrators that might prevent the use of at least VLMs. However, NETX can be installed and used, if you desire. The files needed to run NETX can be loaded manually through modification of the work-station's AUTOEXEC.BAT file, in the usual manner, but users must also install NETX support through Control Panel, just like the Microsoft network clients. To do this, you must remove the Microsoft NetWare client, if it is present, and in the Select Network Client dialog box, choose Novell in the left pane and Novell NetWare (Workstation Shell 3.x [NETX]) in the right. The files needed for the NETX installation, however, do not ship with Windows 95. It is necessary to provide the installer with a location where the proper files are located. NETX.EXE may be obtained from Novell's NetWire in an archive named NET33X.EXE.
It is also necessary to manually modify the LASTDRIVE= line in the workstation's CONFIG.SYS file. This is set to Z by both VLMs and Windows 95. When NETX is used, this value indicates the last drive letter that is to be considered as allocated for local workstation use. It is most often set to E, so that F will be the first available NetWare drive letter. It is also necessary to add NETX.EXE to the workstation's SETVER table. This should be done so that Windows 95 sees NETX as being designed for use with MS-DOS 7.0, which is how the DOS functionality in Windows 95 is labeled. This is particularly important if the %OS_VERSION variable appears in the user's logon script. The SETVER utility is no longer a separate executable in Windows 95. It is automatically loaded by the IO.SYS file during startup.
VLMs. It is more likely that users will run VLMs with Windows 95 than NETX. However, there are also some important concerns that should be addressed when this is done. The default Windows 95 installation process detects the presence of an existing NetWare client, and in some cases, removes it automatically, installing the Microsoft 32-bit client in its place and overwriting several of the VLM files with newer versions in the process. For this reason, it is recommended that the VLM client be completely reinstalled if the Microsoft Client for NetWare has ever been used on the system. This is because full Windows support for the VLMs must be activated, particularly if NDS access is required. Many people assume that they need only to include the lines in the AUTOEXEC.BAT that execute the LSL, MLID driver, IPXODI, and VLM.EXE modules in order to provide full VLM client support, but this is not the case. The entire VLM client kit in its latest version (1.21, as of this writing, also available from NetWire) should be installed, using its own INSTALL.EXE program in Windows 95's MS-DOS mode, rather than through the Windows Control Panel. Be sure to specify that Windows support be installed for the client. MS-DOS mode in Windows 95 is achieved by pressing F8 while the machine boots and selecting Command prompt only or by choosing Shut Down from the Windows 95 Task Bar and then selecting to restart the computer in MS-DOS mode. The process should not be performed from a DOS session within Windows.
The original NET.CFG file from the NetWare real-mode client is not deleted or altered in any way by the Windows 95 setup routine, so any settings previously stored there by earlier VLM installations will be intact, and the file can be saved to another location--or renamed--and then returned to the \NWCLIENT directory after the VLM installation, if you desire. During the installation, the user may be prompted as to whether or not the NETWARE.DRV file should be overwritten. Always respond Yes to this question. NETWARE.DRV is a crucial part of the NetWare clients--NETX and VLMs, as well as Windows 95. Both the Novell and Microsoft client install programs overwrite this file, which normally resides in the \WINDOWS\SYSTEM directory, and full NetWare network functionality in Windows cannot be achieved if the incorrect version is used. Table 12.1 lists the sizes of the various versions of NETWARE.DRV. After restarting the computer, open the Network tabbed dialog box from Control Panel and install support for Novell NetWare (Workstation Shell 4.0 and Above[VLM]) through the normal Select Network Client dialog box.
| Name | Version | Size |
| NETWARE.DRV | Microsoft | 1.6K |
| NETWARE.DRV | Novell NETX | 125K |
| NETWARE.DRV | Novell VLM | 160K |
If the Microsoft Client for NetWare has never been installed on the system, and the VLM client is currently active, then it is only necessary to perform the Control Panel installation procedure. This ensures that the appropriate settings for Windows 95 are configured in the SYSTEM.INI file (such as the path, which is specified as \WINDOWS\SYSTEM by the VLM installation program but needs to be \WINDOWS\VMM32 in Windows 95).
There are some issues to be discussed concerning the actual use of the VLM client. Its compatibility with Windows 95 is not quite 100%. For example, due to improper routine calls made by Windows 95 to NETWARE.DRV, a user might see an attempt to restore drive connections occur before the workstation has connected with a NetWare server, causing an error message for each failed connection. The Restore Now option in NWUSER.EXE establishes connections after the errors have occurred, but they can be avoided entirely by logging on to the server from DOS before the Windows GUI has loaded. This is done by placing a LOGIN command in the workstation's AUTOEXEC.BAT file, or in a batch file named WINSTART.BAT in the Windows directory.
Loading TSRs Using WINSTART.BAT
WINSTART.BAT is a little-known convention in Windows 95 that has been carried over from Windows 3.1. A normal DOS batch file by this name, when stored in a workstation's \WINDOWS directory, is executed just before the Windows GUI loads. In Windows 3.1, one of the advantages of this file is that its contents are removed from memory when Windows is shut down. This obviously is not of any particular value in Windows 95, however, since shutting down the OS leads to a system reboot.WINSTART.BAT is also useful for loading the DOS-based requesters for client/server systems such as Btrieve's BREQUEST.EXE. When Windows 95 is configured to use Microsoft's protected-mode clients, network support is not provided at the time that the AUTOEXEC.BAT file is processed, and an attempt to load Brequest fails since no IPX communication with the server is possible at that time. By the time that WINSTART.BAT executes, however, network support is active, and the requester can load properly.
As with Windows 3.1, it is necessary, when using VLMs, to create all the network search drives that will be needed for the session before the Windows GUI starts. Search drives created in a Windows DOS session are not carried over to other sessions or to the main Windows interface, so they should be specified in a logon script instead, for execution at system startup. As far as drive mappings are concerned, though, the opposite is true. The VLM feature that allows users to select whether drive mappings created in a DOS session should be global or private (that is, whether they should be carried over to the entire Windows environment or remain active only in that single DOS session), does not function under Windows 95. All drive mappings are global, and erratic behavior may result if the Global Drives and Paths option in NWUSER.EXE is not selected.
Finally, Windows 95 long file names cannot be written to NetWare servers using the Novell real-mode clients. The files themselves are written, but only the DOS 8.3 file name that is stored as part of every Windows 95 file gets written to the server volume, despite the presence of the appropriate name space. As a result, Windows 95 user profiles cannot be stored on a NetWare server with these clients.
What is less readily quantifiable is the reduced performance that the Novell real-mode clients provide, when compared with the Microsoft protected-mode client for NetWare. The real-mode ODI adapter drivers that NETX and the VLMs rely upon are inherently slower than their NDIS 3.1 counterparts used by the native Windows client. This can be proven easily since the ODI driver also can be used with the Microsoft Client for NetWare. The memory requirements of the real-mode TSR modules used by the Novell clients also place the user in virtually the same position as the one she sought to escape by switching to Windows 95. The DOS modules load in conventional memory--or they must be loaded into upper memory using EMM386.EXE or a third-party memory manager like QEMM, even in Windows 95. The price of loading them wholly in conventional memory is a reduction in the amount of available memory in each Windows 95 DOS session.
As is becoming increasingly plain to many users, the wishful thinking that has, for many months, fostered the claim that Windows 95 eliminates DOS and all its limitations is inherently untrue. The DOS base upon which Windows runs is still there. A simple change to the MSDOS.SYS configuration file allows a Windows 95 machine to boot to the DOS prompt, after which the user must type WIN to start the GUI. After all, how far could we really be from Windows 3.x and still remain backwards-compatible?
Such considerations are better left behind altogether, whenever possible, which means using 32-bit protected mode applications and services and abandoning the old ways as quickly as possible. The majority of people using VLMs with Windows 95 do so for NDS access alone. NWADMIN and the other NDS-related NetWare utilities do run well in Windows 95, when VLMs are used, although NDS print queues outside the current bindery context are inaccessible. Most network users in a well-designed NDS tree, however, should be capable of performing their normal daily tasks using the resources within their bindery contexts.
NDS Clients for Windows 95. In any case, it is no longer necessary for users to live without a 32-bit NDS client. What, at the time of the initial Windows 95 release, was a serious deficiency, is now rapidly becoming an embarrassment of riches. Both Microsoft and Novell have released NDS solutions for Windows 95. Microsoft's is an additional service that operates with the Client for NetWare Networks, and Novell's is a public beta of its forthcoming Client32 for Windows 95, which is a complete client in itself.
Novell is centering its 32-bit client development activities around an area of common code that it calls Client32, which will form the core of its collection of new 32-bit clients, to be developed simultaneously, including new packages for Windows 3.1, Macintosh, and OS/2. As evinced by the Windows 95 Client32 beta, the plan seems to be progressing well, when compared to the Novell Client for Windows NT discussed earlier in this chapter; the Windows 95 client is light years ahead, even in a beta release. While Microsoft has constructed a basic NDS-compatible client, providing access to all the necessary resources and capable of running logon scripts, Novell has set its sights much higher. It is, with these clients, beginning to demonstrate the true possibilities of NDS as a network management tool, as we shall see.
Nowhere in sight are the severe limitations imposed by the Novell NT client, like the proprietary DOS session and the lack of logon script support. This package installs easily from a local or network drive either by running a SETUP.EXE file from within Windows 95 or through Control Panel. Although the utility for making floppy install disks is again provided, its use is not required this time. The program detects a current installation of the Microsoft Client for NetWare (or either of the Novell real-mode clients) and removes them from the system configuration (although the files are left intact). Client32 can also be installed along with the Windows 95 OS, allowing administrators to custom script a push installation that will cause the client to be automatically installed from the network to every workstation as its user logs on. This type of installation is also possible with the Windows 95 operating system itself (as we shall see later in this chapter), and Client32 can be integrated into that installation, allowing for a one-stop upgrade of both OS and client.
The installation process allows the user to browse for a preferred server or tree name, a definite improvement over the earlier betas. The user's full context for an NDS logon must be entered manually, however. A successful logon causes bindery or NDS logon scripts to be executed, if desired, and while support for all the possible logon script commands is not yet complete, it is nearly so. Logging on under two different user names sequentially causes the two different environments to load smoothly. There are no complaints from Windows regarding changes in drive mappings or other settings. It is even possible, in the Login dialog box, to specify a different profile script to be executed during the logon or to provide values for up to four variables called by the logon script. Support for multiple users on a single machine is therefore quite good.
Once fully installed, the Novell client coexists very well with the Microsoft Windows client, allowing the Windows 95 machine to share its own drives and printers and to access the resources of others, with no interference. The Windows Explorer, under Entire Network, contains an expandable listing of all the servers on the network, as well as a representation of all the NDS trees present there. Users can navigate their way down the current NDS tree to select a particular resource, if desired, or they can expand the server tree all the way down to the file level. It is even possible for a user to log on to two separate NDS trees simultaneously!
Despite these features--or perhaps because of them--overall performance of this beta is not up to the level established by the Microsoft NetWare client. Noticeable delays occur when initially scanning directories on NetWare volumes, possibly due in part to the lack of the integrated network caching using VCACHE provided by the Microsoft client (although Client32 is supposed to provide its own caching). These delays were particularly noticeable when browsing with the NDS tree, but performance levels when actually accessing network files using an application were a good deal more acceptable.
Novell provides a wide array of configuration parameters for its client, accessible through the properties sheet in the Control Panel's Network tabbed dialog box. Many of these are counterparts to variables that can be set in a traditional Novell client's NET.CFG file, some of which can be used to optimize client performance. Their values are stored in the Windows Registry, as are those of the Microsoft client, but Client32 cannot yet parse an existing NET.CFG file and automatically add its settings to the Registry.
Support for the writing of long file names to NetWare servers is provided by the Novell client (except in the case of unpatched NetWare 3.11 servers, as noted earlier). However, it is not possible to create a directory with a name longer than 8.3 characters from the Windows Explorer, even though I can create such a directory from a DOS session. It also is not possible to delete files using DOS wild cards when the file name mask is greater than 8.3. Thus, DEL FILE*.* is accepted, but DEL LONGFILENAM*.* is not. As with the VLMs, all drive mappings are global, although Novell promises private mappings in DOS sessions for a future release. Directory changes on mapped drives, however, remain local to the session where they are enacted. Thus, changing to a subdirectory while in a DOS session does not cause a Windows application to default to that directory on the NetWare drive.
Network fault tolerance in this client is no less than superb. Not only are broken network connections automatically and transparently restored, as with the Microsoft clients, but open files and locks are restored as well! A workstation left running NWADMIN.EXE displays as many as ten files open on the NetWare server console. This server, which not only contains the master replica of the NDS partition being edited, but the NWADMIN executable files themselves, can be brought down (using the DOWN command) and restarted with no interruption to other processes on the Windows 95 workstation. Once the server is completely activated again, operations in the NWADMIN window can be continued from the point at which they were abandoned, and the same open files are again displayed at the server console.
Printing to NetWare queues has changed little in the new client. It still is impossible to run the NetWare Rprinter or Nprinter utilities from Windows 95 (although a 32-bit Nprinter is promised), but NDS print queues are accessible from the Windows Explorer and the Network Neighborhood interfaces. Oddly, however, they are not displayed in the Printers/Add Printers dialog box within the My Computer window. Novell asserts that this is a limitation of that particular dialog box in Windows 95.
Aside from such minor difficulties, the NetWare Directory is completely supported by Client32. NWADMIN runs much the same as it does when VLMs are used, although the 32-bit version that ships with the Novell Windows NT client does not load. All the DOS-based NDS utilities are fully functional in the standard Windows 95 MS-DOS session. There is no need for a dedicated DOS shell to gain NetWare API functionality, as with the NT client. Not surprisingly, though, File and Print Services for NetWare will not be supported by the NetWare client.
Client32 provides many small improvements to the networking features of the Windows 95 GUI. Trustees to files and directories on NetWare drives can be assigned and modified directly through their properties sheets in the Network Neighborhood and Windows Explorer, with user and group account information drawn directly from the server. Additional NetWare-related information is also provided for network objects throughout the interface.
Finally, Novell with this beta has provided an inkling of the true potential of NDS as a centralized network management tool. A library file named APPSNAP.DLL, intended for use with NWADMIN, modifies the NetWare Directory schema so that a new type of NDS object can be created: an application object. Representing program files stored on network drives, application objects can be created for DOS, Windows 3.1, Windows 95, or Window NT executables. They are configured and modified through NWADMIN, like any other object, with properties that can provide the application with command-line parameters, working directories, drive mappings, search drives, starting and ending scripts, custom commentary and contact information for users, and other variables that can be used to control the environment in which the application runs. The modified schema also adds additional selections to the Detail displays of user, group, and container objects that allow access to the application objects to be granted, defined, and even imposed. It is even possible for the administrator to designate whether the environmental settings defined for the application should be applied only while it remains active or carried over permanently to the rest of the working system.
An executable program, called NetWare Application Launcher (NAL.EXE), also ships with the client and will eventually be available in versions for all the Client32 platforms. When executed at a workstation, all application objects to which the user has been granted access appear as icons in a window not unlike a Windows 3.1 program group. Alternatively, users (as well as groups and containers) can be configured so that some or all of the applications are immediately launched when NAL.EXE is executed. This concept allows network administrators to assign users access to customized suites of applications on a completely object-oriented level, from within the NWADMIN interface. There is no need to deal with individual application installations, the creation of program icons, custom logon scripts, or access to the proper application directories as separate tasks. Once application objects are properly configured, you can simply add new users to the appropriate groups or containers in the NDS to provide them with a ready-made Windows desktop, including access to all the applications they need--it's one simple operation.
Although not quite complete, either in its feature set or its performance levels, Novell's effort is considerably advanced for a beta release. Microsoft's own NDS-capable protected-mode client, on the other hand, was released to its online services for free distribution in October of 1995. Instead of reinventing the wheel, it chose to take advantage of Windows 95's networking architecture and provided a Service for NetWare Directory Services that works with the existing Client for NetWare Networks. Installing from Control Panel in the normal way, this client also allows the user to browse for a preferred server or tree, providing support for both NDS and bindery logons. Beyond this, however, Microsoft has opted for the no-frills approach. Its service provides the basic functionality required by the average NDS user and delivers better performance than Client32, all in a package that was released on time, while the actual release of Novell's client is again overdue.
Even without these clients, though, network access from both Windows NT and Windows 95 is far more advanced than that provided in earlier Windows versions. Those who remember the original Windows 3.0 and 3.1 releases should recall the way in which networking was tacked onto those products--almost as an afterthought--and how client installation, at that time, was a strictly manual process.
A great deal of progress has been made since then, and it is always with mixed feelings that veteran network administrators see some of the carefully honed skills that they have acquired over the years become obsolete with the advent of new and improved products. The manual tasks of configuring NICs and installing client software are going to all but disappear before long; it soon will be no more than a matter of inserting a card into a slot, powering up the machine, and watching the OS install the necessary client software. For MIS personnel responsible for hundreds of machines, this will be a miraculous improvement; however, there always will be other tasks to test their skills, as seen in the following sections.
The networking capabilities of Windows 95 are not limited to the various client packages that ship with the product. Microsoft has also devoted a good deal of attention to the installation process itself and particularly to the concerns of network administrators who may be responsible for the installation of the OS onto hundreds of machines. In a situation like that, it usually is impractical for network support staff to travel to each machine with a stack of floppy disks or a portable CD-ROM drive.
This may, however, be unavoidable, if a wide variety of system configurations are used on the network's workstations. The automated network installation capabilities of Windows 95 are based on the assumption that a large number of machines utilize the exact same system configuration. Networks in which users are responsible for configuring their own machines or selecting their own software probably will not benefit from these features, as they rely on careful scripting to provide responses to all the prompts requiring user input during a normal interactive Windows 95 installation.
Consideration also must be paid to the network users' level of expertise. Highly experienced computer users (who are also those most likely to have unique system configurations) are unlikely to need the simplification provided by the automated installation process, considering that the Windows 95 installation process is already quite user-friendly. It is the novice user--who remains blissfully unaware of underlying structures like networks and operating systems--for whom such a feature is needed. For users of this type, their normal daily logon procedure can be modified to automatically begin a pre-scripted Windows 95 installation process that requires absolutely no user interaction. In this push installation, the user is given no choice about when or how an upgrade is to be performed. The same sort of scripting can be used to create a procedure that a user can perform at her convenience by running a particular program, logging on to a special network account, or even clicking an object sent as an e-mail attachment.
Installation Scripts. The preparation and debugging of the script files needed for these installation processes can be a lengthy and time-consuming process. Although several different means have been provided to automate parts of the scripting process, there almost certainly will be sections or parameters that have to be manually modified and tested. It also is unlikely that a scripted installation will be entirely successful on 100% of the machines for which it is intended. As any network administrator will tell you, users have a way of thwarting any plan or device designed to make the administrator's life easier. There are bound to be a number of machines that have insufficient disk space, unexpected configurations, or some other factors that prevent a successful upgrade--this is another reason why these methods are recommended only when large numbers of installations must be performed. If a scripted installation is performed on 100 machines, and only 75 of them are entirely successful, the time and travel saved is well worth the effort. For less than 50 machines, though, it probably would be more efficient for an administrator to perform individual installations from a server-based copy of Windows 95. When all the necessary components are assembled in one place, including any additional drivers or application files needed, the process can be streamlined to run very smoothly. In fact, trained personnel should be able to start the installation process on several nearby machines in succession and perform multiple installations simultaneously.
A network-based installation, however, is not simply a matter of storing a set of installation files on a server drive. It is important to note that, in most cases, the network client software itself is going to be upgraded during the Windows 95 installation process. This means that the software enabling the connection to the network that provides access to the installation files is going to be replaced in the process. In order not to figuratively saw through the tree limb that you are standing on, it is essential that the installation procedure be conducted using an entirely predictable and fully-tested routine, taking into account every workstation configuration that might be encountered on the network.
This routine is realized by the creation of a script file, which in Windows 95 is an ASCII text file with an extension of INF, that can be created by hand in any text editor or can be generated by a number of different utilities included with the OS. The function of the script file is to provide selections and responses to the various prompts and questions generated by the Windows 95 installation program. The questions range from the simple and mundane, such as into what directory Windows 95 should be installed, to the very complex, such as what networking protocols should be used. Selections can be made regarding every part of the installation, from what Windows 95 components to install, all the way down to what wallpaper should be used. In the process, the network administrator can configure the workstation to allow its user as much freedom, or as many restrictions, as the administrator deems fit. System policies can be established and stored on network servers that override the settings in the Registry of each Windows 95 workstation, and limit access to the OS resources that users may have insufficient training or authority to use. Server-based applications or third-party clients can even be installed at the same time as the OS, providing the user with a complete, ready-to-work system as soon as the scripted process is completed.
The simplest way to get an idea of what an installation script looks like is to examine the SETUPLOG.TXT file that is automatically created by Windows 95 during its installation. In fact, by performing such an installation on a representative machine, portions of a working script can be assembled from excerpted parts of this log. The script is structured in much the same way as the primitive INI files used in Windows versions of the past; headings in square brackets separating parameters with accompanying values associated by an equal sign (=). Aside from the setup log, two GUI-based utilities are provided that also have the capability of creating scripts.
The NETSETUP.EXE program is used to create a Windows 95 installation directory structure on a network drive. The operating system files are expanded from the *.CAB archives in which Windows 95 ships and are placed in a directory selected by the user, so that they can be used either to perform an installation to a workstation's local drive or as the server portion of a shared Windows 95 installation. Clicking the Make Script button in the Netsetup dialog box displays a selection of installation parameters in the familiar Windows 95 tree-style display (see fig. 12.8). Any item whose properties are modified is added to the script with the appropriate changes. All the parameters that remain unaltered are installed using their default values. Creating a script that completely automates the installation process is a matter of modifying every parameter that requires input from the user during installation to supply that input in advance and also making all the appropriate selections for the desired configuration.
Figure 12.8
Installation scripts can be created with the Windows 95 NETSETUP.EXE utility.
The BATCH.EXE program is used only to create INF scripts, and provides a different interface with several screens, containing a wider, more detailed selection of installation parameters that can be modified to the administrator's specifications, as shown in figure 12.9. Its basic functionality, however, is the same as that of NETSETUP.EXE. Selections made in a point-and-click front-end are translated to the appropriate syntax for the installation script and saved as an ASCII file. Once a script file is created, it can be executed by specifying its name on the command line after the Windows 95 SETUP.EXE program (as installed to the server drive by the NETSETUP program), or it can be assimilated into the Windows 95 default installation script (named MSBATCH.INF) using the INFINST.EXE program. In this way, you can easily write a network logon script or batch file to initiate the installation process at some point during the user's normal daily activities. Usually, the only difficult part of this task is ensuring that the installation routine is not run repeatedly (every time the user tries to log on, for example). This can be done through script logic or by having users log on to a special network account created specifically for installations.
Network Client Upgrades. The Windows 95 setup routine, under certain conditions, automatically upgrades the network client software from a previous Windows installation, depending on the software that it finds already installed--these actions, too, can be modified to an administrator's specifications. By default, the network client for Microsoft is always installed if a NIC is present in the workstation. Whether or not the protected-mode NetWare client is installed, however, is dependent on what client software is currently installed, and how it is being used. For example, any workstation using the Novell NETX client or the VLM client to attach to a NetWare 3.x server is upgraded to the protected-mode client. However, a VLM client that is being used for an NDS logon is left intact since the protected mode client does not support NDS. Likewise, if any additional networking TSRs are detected whose functionality cannot be exactly duplicated by the protected-mode client, actions are taken to preserve them. These actions may consist of migrating the load line for the TSR from the AUTOEXEC.BAT file to the WINSTART.BAT, substituting a protected-mode equivalent for a required protocol or service (such as IPX or NetBIOS), or leaving the existing client software as it is. In this way, special real-mode implementations of network client software, such as those providing access to mainframes or specialized TCP/IP tools, remain functional after the installation.
Figure 12.9
The Windows 95 BATCH.EXE program provides access to a more comprehensive array
of script parameters.
The special considerations taken into account by the Windows 95 installation routine, as well as the actions to be taken upon detection of network client modules, are listed in a file named NETDET.INI, which is located in the \WINDOWS directory. This file can be modified by the network administrator to accommodate any networking software that is used on the network's workstations, so that the various network configurations found throughout a large enterprise can be individually treated in a wholly predictable manner.
Scripted Installations: Asset or Liability. There is, obviously, a great deal of middle ground between a normal interactive Windows 95 installation and the completely automated one described in the preceding section. It is up to the administrator to decide how much accurate input can be expected of the person at the machine when the upgrade is performed. Anticipating every nuance of the installation process can be a very difficult task, requiring a great deal of thought and experimentation, as well as careful debugging of the script. The BATCH and NETSETUP tools furnished by Microsoft are very basic in this respect. They provide no guidance for the creation of scripts to accommodate specific situations, and the graphical front-ends do not provide access to all the possible parameters that may be included in an installation script.
The truly indispensable tool for this job is the Windows 95 Resource Kit, which is included on the Windows 95 CD-ROM as a large WinHelp file and which can also be downloaded from Microsoft's various online services or purchased as a bound volume. The Resource Kit contains a complete account of the script file syntax as well as a comprehensive listing of all possible parameters. As stated earlier, the use of a script to perform a Windows 95 installation with no interaction from trained personnel is generally not recommended, unless a very large number of identical machines must be upgraded. Making modifications to the default script, however, can streamline the installation process very nicely, allowing junior network support staff--or even short-term consultants brought in for the task--to perform large numbers of system upgrades in a relatively short time.
At this point, there should be no doubt in anyone's mind that 32-bit desktop OSs like Windows NT and Windows 95 are here to stay. Once users get a taste of long file names and see what computing is like without the 640K DOS barrier hanging over them, there can be no going back. As far as networking is concerned, Microsoft has fashioned a better client platform than has ever before existed in the PC world. Although there is always room for improvement, the initial Windows 95 release is being assimilated into the network mainstream with far greater speed than many people outside of Redmond ever anticipated, and Windows NT is rapidly gaining wider acceptance in the ultra- conservative NOS market. Novell's decision to abandon its development of application server OSs has left a significant market share in that area wide open to Microsoft, and the rapid development of 32-bit, shrink-wrapped applications to feed the Windows software-buying audience will all but silence the objections that have been voiced by Microsoft critics in the past that there are no applications for these OSs. Of course, it has been said by many that the only predictable thing about the computer networking industry is its unpredictability, and no one can say what the outlook will be a year from now, but these OSs are a great leap forward, by any rational judgment, and all of us who have had just about all they can take of forced reboots and mysteriously dwindling system resources should now be able to endure a few more years.
© Copyright, Macmillan Computer Publishing. All rights reserved.