Introduction

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

ABSTRACT: This article discusses Windows 95's extensive support for the Novell NetWare network operating system. Features and functionality are discussed in four sections: Architecture and New Features, User Configuration and Security, Accessing and Sharing Resources, and Rolling out Windows 95.

By Joe Davies

Section 1, Architecture and New Features, discusses the new 32-bit protected mode NetWare client written by Microsoft and shipped with Windows 95. It offers the best performance and tightest integration into the Windows 95 operating system. This section also explains how Windows 95 supports Novell's real mode NETX and VLM clients. Lastly, this section demonstrates how to perform typical NetWare functions such as attaching to servers, mapping network drives, capturing printers and sending messages with the new Windows 95 user interface.
Section 2, User Configuration and Security, discusses various user configuration issues and ways to secure and customize the workstation through the initial logon, user profiles and system policies. Also discussed is the new peer server for NetWare, or the "File and Print Sharing for NetWare Networks" service. This new peer server allows a Windows 95 computer to process file and printer requests from any NetWare client. This section demonstrates how to configure and secure the Windows 95 NetWare peer server.
Section 3, Accessing and Sharing Resources, discusses in greater detail the processes of connecting to servers, mapping drives and capturing printers. It also discusses how the Windows 95 NetWare peer server can be used to share drive and printer resources with NetWare clients.
Section 4, Rolling out Windows 95, discusses what you need to do to plan and deploy Windows 95 in your organization: changes you may need to make to your server and workstations, ways to set up Windows 95 and workstation configuration options. It also discuss how use the system login script to create a "push" or automated installation of Windows 95 on your organization's workstations.

Architecture and New Features

This section explores the new features and architecture of NetWare connectivity in Windows 95 concentrating on Microsoft's Client for NetWare Networks. It also examines the support for Novell's VLM and NETX clients and demonstrates some basic usability.

Concurrent access to Novell NetWare resources has been a feature of Microsoft Network products since LAN Manager 2.1. The first implementation was a LAN Manager 2.1 dual network configuration that allowed both LAN Manager and Novell redirectors to load and access LAN Manager and Novell network resources at the same time. Windows for Workgroups version 3.1 allowed dual connectivity using the Novell NetWare redirector and MSIPX, an NDIS 2 compatible version of the IPX/SPX protocol. Windows for Workgroups version 3.11 allowed a dual stack configuration using either Novell's Monolithic or ODI-based IPX and either the NetWare Shell (NETX) or the newer NetWare DOS Requester (VLM).

In all of these cases, the connectivity to NetWare resources was implemented by real-mode components provided by Novell. Real-mode components take up conventional memory and are slower, less reliable, and require data buffering and excessive processor mode switches when used in protected mode multitasking environments.

For Windows 95, Microsoft has written a NetWare client called the Microsoft Client for NetWare Networks (CFNN) which is made up entirely of protected mode components that are fully integrated into the Windows 95 operating system.

Microsoft's Client for NetWare Networks: Architecture

This section examines the architecture of the Microsoft Client for NetWare Networks (CFNN), starting from the netcard and going all the way up to network applications. Here is the client's structure:

32-bit p-mode Netcard Driver

Windows 95 supports the use of NDIS 3.1 network interface card drivers. NDIS stands for Network Device Interface Specification and is an industry standard interface between protocol drivers and network interface card drivers.

NDIS 3.1 netcard drivers are 32-bit and interact with the netcard in protected mode allowing for optimized throughput in the Windows 95 operating system. NDIS 3.1 netcard drivers are also plug and play aware and can dynamically load and unload based on plug and play events.

32-bit p-mode IPX/SPX Protocol

Windows 95 includes its own 32-bit, protected mode version of Novell's IPX/SPX protocol, a component called NWLINK.VXD. This is the same IPX/SPX protocol stack that Microsoft has previously shipped with Windows for Workgroups 3.11 and even though it is 32-bit, it still provides real mode software interfaces for SPX applications such as RCONSOLE.

To get to the properties of the IPX/SPX protocol, select the Control Panel Network icon.

For a quick way to get the Network Control Panel, right click on the Network Neighborhood icon and choose properties.

IPX Protocol Properties

To get the properties on the IPX/SPX protocol, select the "IPX/SPX Compatible Protocol" and click the "Properties" button, or, as another alternative, double-click on the "IPX/SPX Compatible Protocol."

Enabling NetBIOS

If you need NetBIOS over IPX support, for example, for LOTUS Notes, you can enable NetBIOS over IPX. This adds a component called NWNBLINK.VXD, a protected mode NetBIOS over IPX driver, giving you the equivalent functionality of Novell's real mode NETBIOS.EXE driver in protected mode.

Auto Frame-type Detection

A great feature of the Windows 95 IPX/SPX protocol is that it auto-detects the Frame Type being used. Different header combinations called Frame Types correspond to the Data Link layer of the OSI model. Both the workstation and the server must be using the same frame type to communicate. If you have ever configured an ODI workstation you may have some experience with this issue. This is especially true on Ethernet networks where four different frame types exist. Historically, Novell on Ethernet networks used a frame type called ETHERNET_802.3. Since shipping NetWare 4.0, Novell switched to using the frame type called ETHERNET_802.2. There are many advantages to using the ETHERNET_802.2 frame type but there has been some confusion in the industry as users migrated from 802.3 to 802.2.

With Windows 95, however, a network administrator or user does not have to set the Frame Type. The default selection "Auto" causes Windows 95 to automatically detect the network's predominant frame type.

When the Windows 95 IPX/SPX protocol starts up, it performs a General RIP Request on the network. RIP stands for Routing Information Protocol, the protocol used by NetWare workstations, servers and routers to facilitate routing information. When the General RIP Request is sent out, any IPX routers or servers on the Windows 95 workstation's network respond with routing information. The IPX/SPX Protocol analyzes the frame types of the responses and selects the frame type common to the highest number of RIP responses.

In a single frame type environment, you should never have to set the frame type on a workstation again. You can override the default selection of "Auto" by manually selecting the Frame Type.

Network Address

The Network Address selection allows you to enter a specific IPX network address number. The default value is zero, which means that the IPX network addresses are determined automatically on startup from SAP and RIP broadcast traffic during the workstation connection process.

Source Routing

Source Routing specifies whether source routing is enabled and the size of the cache to be used to store source routing paths to destination workstations in a token ring source routing environment. The values are: Off, 16-entry cache, 32-entry cache, 64-entry cache and 128-entry cache. The default value is Off. If source routing is used, it is strongly recommended to use the 16-entry cache to minimize the memory overhead used for source routing information.

Support for IPX Diagnostics

The Microsoft IPX/SPX Compatible Protocol also supports Novell's Diagnostic Responder protocol for connectivity testing and configuration information gathering by NetWare diagnostic programs such as NWCARE and others.

Support for SPX II

The Windows 95 IPX/SPX Compatible Protocol for Windows by itself does not provide support for Novell's SPX II. SPX II is a protocol definition for doing windowing and large packets over SPX. SPX II is supported under Windows 95, but only with the TLI.DLL component (available from Novell) to provide Transport Level Interface services for Windows based NetWare applications. An application must call and use TLI.DLL to get SPX II support under Windows 95.

32-bit p-mode NCP Redirector (NETX-compatible)

Windows 95 includes its own 32-bit, protected mode version of Novell's NETX redirector, a component called NWREDIR.VXD. This new Microsoft-written redirector provides connectivity to NetWare resources that use the NetWare Core Protocol, or NCP, file sharing protocol. NCP is used between NetWare workstations and NetWare servers to manage connections, and to perform file input or output and bindery operations.

This new 32-bit redirector runs entirely in protected mode and is fully integrated into the Windows 95 operating system.

Note that NWREDIR at this time supports only NETX functionality to bindery-based NetWare resources. NWREDIR currently does not support NetWare 4.0's NDS, or NetWare Directory Services. Microsoft is working on support for NDS and will make available an enhanced version of NWREDIR which will support bindery and NDS-based NetWare resources.

Also note that Novell is preparing its own version of a protected mode 32-bit redirector for Windows 95.

NWREDIR offers a number of benefits:

Performance and reliability
Client side caching
Long filename support
Auto reconnect
Packet burst mode and LIP support

Performance and Reliability

The Windows 95 Client for NetWare Networks is much faster than Windows 3.1 using the Novell VLM client on large block file transfers and common network read and write operations because the Client for NetWare Networks is implemented as 32-bit components, executes entirely in protected mode and is designed for operation in a multitasking environment.

Client Side Caching

NWREDIR is written as a Windows 95 File System Driver. Other file system drivers for Windows 95 include drivers for local hard disk access and CD-ROM drives. All file system drivers (except the CD-ROM file system driver) share the same dynamically allocated pool of cache memory managed by a 32-bit component called VCACHE.VXD. With NWREDIR written as a File System Driver, read-only data read across the network is also copied to the RAM-based VCACHE cache. When the same data is read by the workstation again, the cache contents are checked and if the data is located it is copied from the cache. This saves the workstation from having to copy the file over the network for successive file reads and increases performance dramatically for certain types of network file operations.

Long Filename Support for OS/2 Namespace Volumes

NWREDIR supports the use of long filenames (that is, names longer than the MS-DOS 8.3 naming convention) on Windows 95 computers configured with the File and Printer Sharing for NetWare Networks service, also called the Windows 95 NCP server, or NetWare server volumes configured with the OS/2 namespace. Long filenames make it easy to put a more descriptive title on files.

Auto-reconnect

Another useful feature of NWREDIR is the ability to reconnect to a server automatically. If a connection to a server is lost when you are using the NETX client and Windows 3.1, the client computer typically hangs and you are forced to reboot, losing time and possibly data. Novell has addressed this issue with the AUTO.VLM component of the VLM DOS Requester client.

Auto-reconnect allows the Windows 95 Client for NetWare Networks to sense a lost connection and reconnect automatically. If a Windows 95 computer with the CFNN is connected to a NetWare server that goes down, the Windows 95 computer tries to reconnect to that server in the background. When the server becomes available, the Windows 95 computer's connection is reestablished, including drive mappings and print queue captures.

Packet Burst Mode and LIP Support

NWREDIR supports Novell's NCP packet burst mode for faster transfer of NCP-based information. NCP packet burst mode is a sliding-window, self tuning implementation of the NCP file sharing protocol. The Client for NetWare Networks also supports LIP, Large Internet Protocol, which is used by NetWare workstations and servers to negotiate a maximum packet size before sending data.

32-bit p-mode Network and Print Providers

Windows 95 includes its own 32-bit, protected mode network and print providers for NetWare specific functionality such as logon dialogs and network printing functions: NWNP32.DLL and NWPP32.DLL. These are the intermediate components between standard commands at the Windows 95 user interface, the Explorer and other Windows 95 applications, and NetWare specific commands for NWREDIR.

Additional Components

Additional CFNN components:

Protected mode login script processor
Protected mode NCP peer server
NETWARE.DRV stub

32-bit p-mode Login Script Processor

Since the CFNN runs entirely in protected mode, there must be a way to log in and process login scripts in protected mode. The current Novell login script process, LOGIN.EXE, is a real mode 16-bit MS-DOS program. The CFNN provides its own 32-bit version of the Novell LOGIN.EXE login script processor called NWLSPROC.EXE. It processes NetWare 2.x and 3.x system and user login scripts during the logon process for the CFNN.

Section 2 (User Configuration and Security) discusses the logon and connection processes more fully.

Both the NETX and VLM clients can be told which NetWare server to login to using a "Preferred Server" setting in the NET.CFG file or at the command line. To specify a Preferred Server for the CFNN:

In the Network Control Panel double-click on the "Client for NetWare Networks" client to get its properties.
Under the Preferred Server option, enter the name of your NetWare preferred server.
If you want to process your login scripts when you log into the preferred NetWare server, check the "Enable logon script processing" box.

32-bit p-mode NCP Server

Windows 95 also ships with a 32-bit NetWare peer server service for file and printer sharing for NetWare Networks. It allows you to turn a Windows 95 computer configured to use the CFNN into a computer capable of processing file and print requests from any NetWare client, including the Novell NETX and VLM clients.

Sections 2 (User Configuration and Security) and 3 (Accessing and Sharing Resources) discuss the Windows 95 NetWare Peer Server in greater depth.

NETWARE.DRV Stub

For backward compatibility with network applications that check for the existence of the file NETWARE.DRV before running, Microsoft provides its own version of NETWARE.DRV. This version of NETWARE.DRV is a small stub. It does not provide the same functionality as the Novell-supplied NETWARE.DRV for the NETX and VLM clients. Applications such as NWUSER.EXE which attempt to call functions within this Microsoft supplied version of NETWARE.DRV will fail.

Application Interfaces

The CFNN architectural components provide a variety of software interfaces for applications.

Win32 Network APIs

The Win32 Network API is provided by a component called MPR.DLL. In the case of the Client for NetWare Networks, Win32 Network API calls are resolved by the Network and Printer Providers, NWNP32.DLL and NWPP32.DLL.

The Win32 Network APIs allow Win32 applications such as the Windows 95 Explorer to perform network-independent functions such as browsing and mapping network drive connections.

NETX INT 21h API

NWREDIR makes available the 16-bit NETX INT 21h API for NetWare applications and utilities.

On a real-mode NetWare workstation, the NETX API is exposed by the NETX.EXE or by NETX.VLM when using the VLM DOS Requester Client. The NETX API is available through a series of INT 21h subfunctions and is used by applications and utilities for services such as connections, printing, bindery, and other NetWare services.

NetBIOS Interface INT 5Ch

When NetBIOS over IPX is enabled, NWNBLINK.VXD, along with another component called VNETBIOS.VXD, exposes the standard NetBIOS interface at INT 5Ch. Applications using INT 5Ch can submit NetBIOS commands to this interface for NetBIOS session, datagram and name management services.

IPX ECB Interface INT 7Ah

The IPX/SPX Compatible Protocol for Windows, NWLINK.VXD, exposes the Novell Event Control Block (ECB) interface. ECBs are the programming construct for submitting packets to be sent using IPX or SPX. A 16-bit IPX/SPX application accesses the ECB interface through software interrupt 7Ah or 64h.

An example of an IPX/SPX application is Novell NetWare's RCONSOLE utility, which allows you to run commands on a NetWare server remotely using the SPX protocol. RCONSOLE creates SPX ECBs and submits them to INT 7Ah interface.

Another popular workgroup-based SPX application used in the corporate network environment is Network Doom. Network Doom uses the SPX interface exposed by NWLINK, and can be run in an MS-DOS prompt of Windows 95.

Novell Windows API

Novell also has a Windows API provided by a series of DLLs that shipped with the DOS Requester client (VLM). These DLLs provide a Windows API for Windows applications that need to access various NetWare services. They include:

NWCALLS.DLL: NCP Services
NWIPXSPX.DLL: IPX/SPX Services
NWLOCALE.DLL: Localization and Internationalization Services
NWNET.DLL: NDS Services
NWPSRV.DLL: Print Server Services
NWGDI.DLL: NetWare GDI Services

These DLLs expose a Windows API set. Calls to them are passed to the real mode Novell client components through the Novell-supplied VNETWARE.386 (for NETX or VLM) or VIPX.386 (for monolithic or ODI IPX).

Of the above DLLs, NWREDIR supports applications calling NWCALLS.DLL and NWLINK supports applications calling NWIPXSPX.DLL. NWREDIR provides VNETWARE.386 functionality for NETX (bindery) equivalent services.

Microsoft's Client for NetWare Networks: Features

Full Connectivity with No Conventional Memory Footprint

One of the principal benefits of using all Microsoft protected mode components is that they have no conventional memory footprint. If you compare the real mode memory environment between a computer using the CFNN and a client using Novell's NETX client, you will see that the CFNN machine has no drivers loaded in conventional memory corresponding to netcard drivers or protocol drivers. On a computer configured with the NETX redirector and ODI drivers, you see the LSL, MLID, IPXODI and NETX drivers are loaded, reducing available conventional memory.

Support for ODI MLIDs

The Client for NetWare Networks also supports the use of existing netcard drivers used in Novell's Open DataLink Interface, or ODI. An ODI netcard driver is called an MLID, or Multiple Link Interface Driver. If a 32-bit Windows 95 driver is not available, then the existing ODI MLID installed on the workstation can be used.

The architecture of a Windows 95 Client for NetWare Networks using an ODI MLID, has two extra Microsoft components that allow this functionality: an ODI Support Driver called MSODISUP.VXD loaded in protected mode and an ODI Helper driver called ODIHLP.EXE loaded in real mode.

Data is sent and received between the real and protected mode environments through two memory buffers, one in protected mode and one in real mode.

When data is sent, the protected mode ODI Support Driver copies the data to the protected mode buffer. It then copies the data from the protected mode buffer to the real mode buffer and switches the processor mode. Then, the ODI Helper Driver grabs the data from the real mode buffer and sends it through the ODI interface, where the netcard puts it on the media. The ODI Support Driver then switches back to protected mode and is ready for the next packet of data

ODIHLP.EXE in AUTOEXEC.BAT

The lines in AUTOEXEC.BAT that show Windows 95 using an ODI MLID configuration are:

LSL.COM
3C509.COM
ODIHLP.EXE

Loaded are the Link Support Layer (LSL.COM), the ODI MLID (in this case 3C509.COM, the MLID for the 3-COM Etherlink III card), and ODIHLP.EXE (the Windows 95 ODI Helper Driver).

Not loaded is the IPXODI.COM driver, because its functionality is provided by the Windows 95 32-bit IPX/SPX-Compatible Protocol.

Disadvantages of Using an ODI MLID

Although this ODI mapping technology works well and has been in the marketplace since Microsoft shipped Windows for Workgroups 3.11, there are a couple of disadvantages to using an ODI MLID:

Use of an ODI MLID causes a network performance hit each time data is sent or received, because data is copied between buffers and processor mode is switched.

Also with an ODI MLID, the NET.CFG file, which stores setting for ODI components like the MLID, must be separately maintained using a text editor. A network administrator cannot maintain the NET.CFG file through the Windows 95 Network Control Panel or remote registry utilities.

Finally, ODI MLIDs, unlike NDIS 3.1 netcard drivers will not dynamically load and unload according to plug and play events.

Windows 95 Support for Novell's NETX and VLM Clients

For backward compatibility, Windows 95 also supports the use of the Novell NETX or VLM client. Although there are benefits in using the Microsoft Client for NetWare Networks, some cases require the use of one of these Novell clients.

Windows 95 can use only one NetWare client at a time, and must be configured to use either the Microsoft Client for NetWare Networks, or the NETX client or the VLM client. A procedure for switching clients is discussed in section 4 (Rolling out Windows 95).

Architecture

In the lower layers of the architecture for either the NETX or VLM client, there is the real mode NETX or VLM client with the ODI-based IPX protocol stack. Just as with Windows 3.1, the Novell-written Windows components VNETWARE.386 and VIPX.386 provide virtual machine support for the Windows driver NETWARE.DRV and real mode NetWare applications. This NETWARE.DRV is the NETWARE.DRV written by Novell and not the stub driver written by Microsoft for the Microsoft Client for NetWare Networks. There are two versions of this Novell-written Windows driver, one for NETX clients and one for VLM clients.

Just above the Novell components is an extra component, NW16.DLL. This translation layer is necessary because the NetWare Network and Print Providers are 32-bit components and the Novell supplied components are 16-bit.

The Network and Print Provider layers are exactly the same. Regardless of which client is installed, Windows 95 applications use the same user interface and procedures for doing standard networking functions such as mapping drives and capturing printers.

Boot Process

When using Novell's NETX or VLM client, the boot process differs with respect to the initial login to the NetWare server. With the Novell clients, you must login and process your login script BEFORE launching Windows 95 to ensure that you have made all your appropriate drive mappings including search drives and other changes to the MS-DOS environment.

NETX/VLM login process

If you login to a Windows 95 computer configured with Novell's NETX client, as it boots you see the initial Windows 95 screen but then the screen clears and you are prompted to login. When you do, the login scripts execute using the Novell LOGIN.EXE login script processor and then Windows 95 loads. This procedure assumes that you login to your preferred NetWare server in the AUTOEXEC.BAT.

If you do not login before running Windows 95 and login using an MS-DOS prompt inside of Windows 95, then any changes you make to the MS-DOS environment such as search drives in the MS-DOS path, environment variables or TSRs will be local to that MS-DOS prompt window and are lost when you close the MS-DOS prompt.

Situations Where NETX/VLM Must be Used

Why use a 16-bit Novell client when there are so many benefits to using the 32-bit Microsoft Client for NetWare Networks? There are some situations where the NETX or VLM client must be used:

NDS support
Custom VLMS
NCP packet signature required
NetWare/IP required
Incompatibilities with network applications
Real mode TSRs and utilities required

NDS Support

If you are using NetWare 4.0's NDS, or NetWare Directory Services, in a true directory tree implementation, and are relying on directory tree syntax, context and directory objects, you must continue using the VLM DOS Requester client. The Client for NetWare Networks at this time is a NETX compatible, bindery based NetWare client and has no awareness of directory trees and objects.

Microsoft is working on an NDS-compatible client which should be available soon after Windows 95 ships.

If you have a single organizational unit directory tree structure and all your NetWare 4 servers are using Bindery Emulation, you can use the Client for NetWare Networks. The only exception is NDS-based login scripts. Section 4 (Rolling out Windows 95) explains a workaround that allows you to use the CFNN in this environment and still process System and User-based login scripts.

Custom VLMs

If you are using custom VLMs, such as PNW.VLM for Personal NetWare, and that functionality is not provided by Windows 95, you must continue using VLM.EXE.

NCP Packet Signature

The Client for NetWare Networks does not support NetWare's NCP Packet Signature–an enhanced security feature supported by the NETX and the VLM DOS Requester client that adds protection against packet forgery by requiring the server and the workstation to "sign" each NCP packet. The CFNN does not provide NCP Packet Signature; if you want to take advantage of this additional network security you must use the real-mode NETX or VLM client.

NetWare/IP

NetWare/IP allows NetWare users to send NCP data over IP, the Internet Protocol portion of the TCP/IP protocol suite, rather than IPX. The Microsoft Client for NetWare Networks at this time does not support the use of the TCP/IP protocol to send NCP requests.

Incompatibilities with Network Applications

Microsoft has made great efforts to support all the documented API calls for the NETX and ECB software interfaces. If a network application does not work under Windows 95 due to unknown or undocumented features, you must continue using the NETX or VLM client. To troubleshoot whether it is an incompatibility with the CFNN, merely switch clients to one of the NetWare clients and test again.

Other Real Mode TSRs and Utilities

A variety of TSRs and utilities require real mode Novell components to load. For these, the NETX or VLM client must be maintained until Windows 95 versions of these utilities are made available.

Limitations of Using the NETX/VLM Client

Performance/Stability

The NETX and VLM clients are 16-bit real mode clients, so they require buffering and mode switching which hamper performance. Using real mode components in a protected mode operating system can also cause stability problems such as NETX clients hanging in Windows after losing a server connection.

No VCACHE

Since neither NETX or VLM redirectors are integrated into the Windows 95 operating system as file system drivers, neither can take advantage of the 32-bit dynamic cache manager (VCACHE) present in Windows 95. This slows certain types of network file operations.

No Windows 95 NCP Server

If the NETX or VLM client is being used, you cannot install the "File and Printer Sharing for NetWare Networks" service (the Windows 95 NCP Server) which relies on the Microsoft Client for NetWare Networks for its network operations.

Using VLM's NWUSER.EXE for NDS Support

One of the benefits of using the VLM client is that we can take advantage of Novell's NetWare User Tools Utility, NWUSER.EXE.

On a Windows 95 computer configured to use the Novell's VLM client, you can from NWUSER perform any function that was possible with Windows 3.1 and the NWUSER utility: view directory trees, change context, map drives, capture print queues and send messages.

NWUSER provides users with a familiar way to perform NetWare network functions while they are learning the new Windows 95 user interface.

Running the NetWare Administrator

With the VLM client, you can also run NWADMIN,EXE, the NetWare Administrator for NetWare 4.x. This allows you to administer your NetWare directory tree from a Windows 95 computer.

Monolithic IPX Support

Windows 95 also supports computers using the monolithic IPX component, IPX.COM. Novell has stopped updating the monolithic version of IPX and no longer supports monolithic driver development. But if you have not been able to move your workstations to ODI, Windows 95 will install and support this older configuration.

Monolithic IPX configurations have some inherent limitations. For instance, Windows 95's network architecture allows for multiple protocols and multiple clients, but monolithic IPX workstation netcard drivers cannot be isolated from the IPX protocol driver because they are combined in the same executable file. This prevents you from using any additional protocols or network clients. Workstations using the monolithic IPX.COM, can be configured only with a single client, the Novell NETX client.

Basic Usability

Let's look at some basic NetWare functions and how they are performed with the Windows 95 user interface. Note that you perform these basic functions through the Windows 95 user interface and therefore through the network and print provider layer, the procedures are the same regardless of which NetWare client is installed: the Microsoft Client for NetWare Networks, Novell's NETX client or Novell's VLM client.

Attaching to a NetWare Server

Currently, this is done with the NetWare ATTACH utility or through the NETWARE.DRV dialog boxes in Windows 3.1. In Windows 95, you can still use the NetWare ATTACH utility from an MS-DOS prompt, or you can use the Network Neighborhood.

From the Network Neighborhood, select the "Entire Network" window, which shows all the NetWare servers on the network. This is equivalent to the display of the Novell SLIST command.
To connect to a server from the "Entire Network" window, double-click on the server icon or select "Attach As..." from the server icon's context menu. You are prompted to enter a user name and password or you can login as the GUEST account.
Click OK. Windows 95 displays a window showing the server's volumes and print queues.

This is the equivalent functionality of the Novell ATTACH command. You are authenticated by the server and can view its resources, but no login script is processed.

Mapping a Drive to a NetWare Server Directory Using Explorer

To map a network drive, you can use the Novell MAP utility or the Windows 95 user interface.

Once you have attached to the NetWare server and its window is up, navigate the server volume by double-clicking on the folder icons just as you were navigating our own disk directories. Once you arrive at the directory location you want to map, follow this procedure to map a network drive to the current location:

Select the directory.
Use the secondary mouse button to bring up the directory's context menu.
Select "Map Network Drive."
Select the drive letter and specify whether you want this drive to be reconnected upon startup as a persistent connection or to be a root mapping.
Select OK to map the drive. A new window with the contents of the new network drive appears.

This functionality is equivalent to the Novell MAP command, equating an MS-DOS drive letter to a NetWare server volume directory.

Capturing a NetWare Server Print Queue Using Explorer

To capture a network printer by redirecting a local LPT port to a print queue on a NetWare server, you can use the Novell CAPTURE utility or the Windows 95 user interface.

From the open NetWare server window, bring up the context menu for the print queue and select the "Capture Printer Port" menu option.
From the "Capture Printer Port" dialog, choose the local port to redirect and whether or not you want this to be a persistent connection.

This functionality is equivalent to the Novell CAPTURE command, where a local LPT port has been redirected to a Novell NetWare print queue.

Sending a Message Using WinPopUp

You can send a message using the Novell SEND utility or the Windows 95 WinPopUp utility (which also allows you to receive messages from other NetWare users). If you are using the Client for NetWare Networks, you cannot use the Novell supplied utility NWPOPUP.EXE to receive messages.

User Configuration and Security

This section looks at the issues of user configuration and security. It shows the Windows 95 logon process for each of these clients and discusses the new features of user profiles and system policies. It also shows how to configure the workstation, including user logon, user profiles and system policies, and discusses the configuration and security model of the Windows 95 NCP server, which allows a Windows 95 computer to act like a NetWare server and process file and print requests from NetWare clients.

Windows 95 Logon

Just as in Windows for Workgroups, the Windows 95 desktop is associated with a password used to identify each user attempting to access Windows 95. The Windows 95 logon consists of a UserName and Password.

These identification parameters, (in effect, the user's security credentials) unlock a user's Password List File or Password Cache. The Password List File stores the accumulated passwords for network resources a user has connected to over time. The Windows 95 logon ensures that only appropriate users with appropriate passwords can open their Password List Files.

Following is a description of how the password list or password cache works.

Password List Options

When you connect to a network resource, you have the option to "Save this password in your password list." If you check this option and connect to the resource, Windows 95 stores an entry consisting of [Server Name, UserName, Password] in your password list file. The next time you connect to this resource, the password list file is checked for an entry and, if found, is sent. Because Windows 95 "remembers" your network server passwords and passes them automatically, you have seamless connections to your network resources.

This requires that you log in with your UserName and Password and unlock your password list file.

A word of caution about password caching. NetWare network users are accustomed to entering their password whenever they attach to a server. With password caching, you do not need to remember the passwords to network resources because you are connected without being prompted. This makes it very easy to forget the passwords over time. It is very similar to putting phone numbers in a speed-dialing telephone: over time you tend to forget the complete numbers. Password caching is a great convenience, but if a network resource password expires or needs to be changed you must first enter the original password (which you may have forgotten).

Also, once you have logged on to Windows 95 and have unlocked your password list file, someone using your system after you have logged on can gain access to your network resources without knowing the passwords, because the passwords are passed automatically by Windows 95. It is a good idea to log off of Windows 95 when you are away from your computer.

Blank Passwords

You can bypass the Windows 95 logon process by making your Windows logon password blank. This is not recommended because a blank password allows anyone to logon to your system and gain access to your network resources. Anyone signing on this way does not need your passwords: they are stored in your password cache and are passed automatically by Windows 95.

Windows 95 Logon Is Separate

It is important to note that the Windows 95 logon is separate from the login to the preferred NetWare server to run login scripts and separate from passwords on individual NetWare servers. Which logons you are prompted with depends on the NetWare client you are using and whether the passwords are synchronized.

Client for NetWare Networks

If you are using the Microsoft Client for NetWare Networks, you can select which logon the user sees first by using the Network Control Panel 's "Primary Network Logon" option.

Selecting "Windows Logon," brings up the Windows 95 desktop logon dialog first, then the dialog to logon to a NetWare server for the purpose of running login scripts.
Selecting "Client for NetWare Networks," brings up the dialog to logon to a NetWare server, then the Windows 95 desktop logon dialog.

For user convenience, a network administrator can arrange it so that users have only one login password. This is done by making the Windows Logon password the same as the logon password to the preferred NetWare server. When the user logs on, using whatever "Primary Network Logon" option has been set in the Network Control Panel, the password entered in the initial logon dialog is passed to the next logon process.

NETX or VLM Client

If you are using either the NETX or VLM client, you must login to your preferred NetWare server before launching Windows 95 to run your login script to make search drive mappings and other needed changes.

Once in Windows 95, you must logon to the Windows 95 desktop using your Windows 95 logon password. There is no way to synchronize passwords for these two clients, and you must enter one password to logon to your NetWare server and run your login scripts and the other to logon to Windows 95 and open your password list file.

With the NETX or VLM clients, the login process and the execution of login scripts is accomplished through LOGIN.EXE, a 16-bit real mode Novell NetWare utility located on the default mapped login drive. For example, you load VLM, change to the F: drive to run LOGIN.EXE and are prompted for your user name and password. Entering a correct user name and password causes the appropriate login scripts to be processed. This process is the same when using the NETX or VLM clients under Windows 95.

With the Microsoft Client for NetWare Networks, the 16-bit real mode Novell LOGIN.EXE utility is not used. Instead, the Microsoft Client for NetWare Networks relies on a Microsoft-written 32-bit protected mode login script processor called NWLSPROC.EXE which provides the same functionality as Novell NetWare's 2.x and 3.x version of LOGIN.EXE and processes the System and User login scripts while in Windows 95. NWLSPROC.EXE is written to process all documented login script commands for NetWare 2.x and 3.x.

You may know that if you login to your NetWare server in an MS-DOS prompt of Windows, changes to the MS-DOS environment to support search drives and any other MS-DOS environment settings or TSRs get loaded local to that MS-DOS prompt. NWLSPROC.EXE handles changes to the MS-DOS environment variables by changing the environment variables globally. LSPROC propagates the changes made to the MS-DOS environment through SET statements or search drive mappings to the Windows 95 System VM; each MS-DOS VM inherits these changes.

However, TSRs are not propagated to the System VM–a limitation of NWLSPROC.EXE that you must keep in mind when deploying Windows 95.

NWLSPROC.EXE opens an MS-DOS VM to process the login scripts. During processing it performs the login script commands and propagates changes to MS-DOS environment variables to the System VM. Any TSRs loaded in the login scripts are loaded local to that temporary MS-DOS VM. When NWLSPROC.EXE is done, it attempts to close the temporary VM. When it does, the TSRs loaded during login script processing are discarded along with the MS-DOS VM.

User Profiles

User profiles, new in Windows 95, allow customized desktop settings (wallpaper, color scheme, etc.) to "follow" you around the network. User-specific settings (instead of computer-specific settings) are the same regardless of which computer you log onto. User profiles must be enabled on each computer for this feature to be fully functional on all network computers.

Stored in <Preferred Server>\SYS:\MAIL\<user ID>

To enable user profiles with the ability to "follow" a user around the network, user profiles must be stored in some network location specific to the user. In NetWare networks, user profiles are stored on a user's preferred server, on the SYS: volume, in the MAIL directory and in a subdirectory off of the MAIL directory corresponding to an 8-digit hexadecimal bindery object ID assigned the user when the account is created. A directory under SYS:\MAIL corresponding to this user ID may also be created. This directory stores user login scripts and user print job configurations in NetWare 2.x and 3.x.

When users configure their computer for user profiles using the Password Control Panel, the next time they login and then logout, Windows 95 automatically creates a copy of the files containing their user profile (such as USER.DAT, the user-specific portion of the Windows 95 registry) in this directory. If a directory does not exist for that user, Windows 95 automatically creates one before copying files.

For that point on, whenever they login to their preferred server from a computer with user profiles enabled, their user profile files are automatically copied down to the local system and their custom desktop appears.

User profile files take up disk space on the preferred server. Make sure you have enough disk space on the SYS volume before enabling this feature.

Enabling OS/2 Namespace (LFN Error Message)

To store full user profile files, Windows 95 uses Long File Names. If it tries to copy Long File Name files to the SYS: volume and the SYS: volume has not been enabled with the OS/2 namespace, it returns an error message. To prevent this, enable the OS/2 namespace on the SYS volume before enabling user profiles.

System Policies

Network administrators can also use System Policies, a powerful administrative feature of Windows 95, to control access to the network, specify standard desktop configurations and prevent users from modifying pre-set applications or desktop settings. System policies consist of changes to the Windows 95 registry that are merged into the registry on the local computer during the logon process after the implementation of user profiles. They allow network administrators to create safer or more standard environments for users by specifying default settings, settings for individual users, groups or individual computers by computer name.

For example, a network administrator can use a System Policy can prevent a user from changing Network settings under Control Panel by removing the Network icon from Control Panel.

An administrator can also use a System Policy to create a standard look for the Windows 95 desktop. If you want all desktops to look the same (with the same color scheme and background bitmap) you can specify these settings with System Policies. Anyone logging onto the NetWare server automatically gets the standard company desktop.

System Policies are loaded across the network after User Profiles, so they override whatever custom settings are saved in the user's User Profile.

System policies are contained in a file which is created and placed in a central network location so that each workstation can download its settings during the logon process. The default system policies file is called CONFIG.POL and is created by the network administrator with a utility called the Policy Editor. On NetWare networks CONFIG.POL is copied to the PUBLIC directory on the SYS volume of the Preferred Server.

Whenever a user logs on with Windows 95, the \PUBLIC directory of the login server is checked for the existence of CONFIG.POL. If found, the appropriate settings based on defaults, user name, group membership or computer name are copied across the network and implemented on the local computer's registry.

Windows 95 NCP Server

Windows 95 ships with a network service called the "File and Print Sharing for NetWare Networks," also called the Windows 95 NetWare Core Protocol (NCP) Server. This service turns a Windows 95 computer into an NCP peer server capable of processing NCP requests from any NetWare client. This allows sharing of local files and printers on the Windows 95 computer with NetWare workstations running Novell's NETX or VLM client or the Windows 95 32-bit Client for NetWare Networks.

The Windows 95 NCP Server is 32-bit, runs in protected mode, supports long filenames, and is Plug and Play-aware. Like the peer sharing component in Windows for Workgroups, it allows users to share their directories and/or printers with other users on the network. However, the Windows 95 NCP Server differs from peer sharing in Windows for Workgroups in that it operates only under a user-level security scheme. Access to a shared resource is based on the identity of the user trying to access that resource instead of a password associated with that resource.

The Windows 95 NCP Server is meant to work in concert with an existing Novell NetWare server environment and add complementary sharing services by implementing a pass-through security link to an existing Novell NetWare server. To enable the NCP server in Windows 95 you must have a bindery-based NetWare server accessible on the network for the Windows 95 NCP server can use for its user database and authentication authority.

The File and Print Sharing for NetWare Networks service is available only if the protected mode Client for NetWare Networks is also installed, not if the NETX or VLM client is installed.

Windows 95 NCP Server not a NetWare Server

Note that the Windows 95 NCP Server is a 32-bit Windows 95 component which can process NCP-based requests for file I/O and printer output. The NCP Server service does not turn a Windows 95 computer into a Novell NetWare server. There are certain things that can be done with a NetWare server that a Windows 95 NCP Server cannot do:

NCP Server cannot load and run NLMs (programs written in the NetWare Operating System and which can be run only on a NetWare server)
NCP Server cannot perform client logins or provide system and user login scripts
NCP Server cannot do internal IPX or IP routing
NCP Server cannot use NetWare server LAN netcard drivers
NCP Server does not support the SFT features of NetWare such as disk mirroring and duplexing, transaction tracking and server duplexing
NCP Server does not support loading Name Space Modules (OS/2, NFS, Macintosh) to support alternate file systems

Using an Existing NetWare Server Bindery

Unlike a NetWare server, the Windows 95 NCP Server does not create and maintain its own database of users and groups and their properties. There is no equivalent to a NetWare server's bindery on a Windows 95 computer. Instead, the NCP Server relies on an existing bindery on a NetWare server for its security accounts database.

The NetWare server with the bindery of account information that is used by the Windows 95 NCP server is called the Security Provider. The Security Provider provides a network-wide list of accounts which includes users and groups and authentication services for Windows 95 servers. The Windows 95 NCP Server forwards user authentication requests to the Security Provider. Every client who attempts to use a Windows 95 resource must be validated from the central account list located on the Security Provider.

Creating a WINDOWS_PASSTHRU Account on the Security Provider

To facilitate the pass through authentication process on the NetWare server, you need to create a special account called WINDOWS_PASSTHRU on the Security Provider. This is not an account used for logging on, but a special account used when validating

To enable the NCP Server, add the File and Printer Sharing for NetWare Networks service using the Network Control Panel, then specify a NetWare server that will act as Security Provider using the Access Control tab of the Network Control Panel. After restarting, you can now use the Windows 95 Explorer to share directories and printers using the list of accounts on the Security Provider.

Note that this server does not have to be your preferred server used for logging on and running login scripts: it can be any NetWare server on the network.

Limitations of User Level Security

There are some limitations to the user level security provided with Windows 95.

Only one Security Provider can be specified. Windows 95 is designed to access the list of accounts available through one Security Provider. A Windows 95 server can grant access only to those users in the account list on the Security Provider specified.
Security provider must be a NetWare Server. When the Microsoft file and print sharing for NetWare service (NCP server) is installed, the Security Provider must be a NetWare server.
The Windows 95 NCP server cannot view group members from Windows 95 user interface. It can view the group names on the Security Provider but not the users within those groups. To view the users within a NetWare group, use the appropriate NetWare administration utility such as SYSCON or NWADMIN.
User Level Security assumes that Security Provider is up and running. The Windows 95 pass-through authentication model is based on the premise that a Security Provider is available on the network to validate a client's credentials. If the Security Provider is down or unavailable, access to user-level shares cannot be validated and clients will not be able to access the shared resources of the Windows 95 NCP server.
You cannot Administer accounts on the Security Provider. Windows 95 does not ship with tools or utilities to administer the Security Provider's accounts. To administer a NetWare server's accounts, use the SYSCON or NETADMIN/NWADMIN utilities shipped with Novell NetWare.
You must have a valid account on Security Provider. To access the list of accounts for sharing local directories and printers, you must be able to log on and be validated by the Security Provider.

Pass-through Authentication

Pass-through authentication is the mechanism for the Windows 95 NCP Server to enable user-level security. Pass-through quite literally means that Windows 95 passes an authentication request through to a NetWare server. The Windows 95 NCP server utilizes the bindery of a NetWare server in a five step process when an NCP client tries to connect to a Windows 95 NCP server:

The Client asks to be granted access to a Windows 95 server's user-level security share and sends its security credentials–its UserName and Password.
The Windows 95 user-level security Server asks the Security Provider to verify the client's security credentials.
The Security Provider checks the user name and password against its security database, which is the NetWare server's bindery.
The Security Provider informs the Windows 95 server that the Client's credentials are valid.
The Windows 95 User-Level security Server grants appropriate access to the Client, based on whether the Client has been granted access to the resource directly or indirectly through group membership.

It may seem that Windows 95 does not have true user-level security because it depends on an existing Security Provider such as a NetWare server for the user list. This is not a weakness, but an administrative advantage. Rather than have each user manually enter the list of accounts and maintain them locally, the network administrator can manage a central account list. Windows 95 keeps the network-wide account list centralized and scaleable and stops unnecessary use of local system resources.

Note that a user does not need to be logged on to the Security Provider as the supervisor or a supervisor-equivalent in order to use the Windows 95 NCP server. Any Windows 95 user that can log on and be validated by the Security Provider can access the account list.

Multiple server environments

NetWare 2.2 and 3.x servers store all information on users, groups, passwords and rights in a database on the server called the bindery. NetWare 4.x servers can appear to have a bindery through bindery emulation. There is a separate bindery for each NetWare server, but Windows 95 can use the bindery of only one NetWare server.

Companies commonly have multiple NetWare servers in different departments and users log in to their department server, but problems can occur when the list of accounts differs from one NetWare server to another.

Consider, for example, a case in which two users have accounts on server A and a third user has an account on server B. The users on server A can select only one NetWare server for pass through validation, and they must select server A because that is where their accounts are located and they must log onto it in order to get access to the account list. Selecting server A allows the two users on it to grant access to each other, but not to the user on server B.

The solution to this issue is to create a NetWare server that has all of the accounts of all the servers and make it the Security Provider for all users using the Windows 95 NCP Server service..

No NNS Support

NetWare 3.x servers support a distributed account naming service called the NetWare Name Service (NNS) which implements a domain model for NetWare servers by grouping servers together and distributing the domain's account list. The Windows 95 NCP Server does not support the use of NetWare domains and the NetWare Name Service.

NDS Support

NetWare 4.x servers support NetWare Directory Services, an organization-wide directory of network objects (servers, print queues, users) in a tree structure designed around organizational or geographic models. With NDS, once users log on to the directory tree, they can access any resource of the entire tree for which they have been granted access. NDS servers can access user names across the entire directory tree merely by specifying their context (or location) within the directory tree.

For a security provider, a Windows 95 NCP server can use any NetWare 4.x server using bindery emulation, which allows the NetWare 4.x server to emulate having a bindery with all of the objects (users, groups, print queues, etc.) within the context of the server's organizational unit. A Windows 95 NCP Server using a NetWare 4.x server this way has access only to the list of users in the context of that NetWare 4.x server, not the network-wide list of users available in the entire directory tree.

Directory Security on NCP Server

On a Windows 95 NCP server, you can specify directory access type using Windows 95 access rights, the equivalent of NetWare trustee and directory rights on a NetWare server. Access rights specify, at a directory level, what a given user can do in a given directory on a Windows 95 server. Unlike Novell NetWare, Windows 95 does not provide rights down to the file level or additional file attributes.

Access rights are:

Read Files–Read and open files in a directory
Write Files–Write to files in a directory
Create Files and Folders–Create new files and directories
Delete Files–Delete existing files and directories
Change File Attributes–Modify file/directory attributes or rename
List Files–Allow users to see files in a directory
Change Access Control–Allow users to modify access rights

"Read Only" corresponds to Read Files and List Files access rights. "Full Access" corresponds to all access rights. The "Custom Access" access type allows you to specify exactly what is allowed in the directory for an individual user or group.

Windows 95 Access Rights and NetWare Equivalents

NetWare equivalent rights are outlined in the chart below.

Windows 95 Access Right	Equivalent NetWare Right
(R)ead Files	(R)ead
(W)rite to Files	(W)rite
(C)reate Files	(C)reate
(D)elete Files	(E)rase
Change File A(t)tributes	(M)odify
(L)ist Files	(F)ile Scan
Change (A)ccess Control	(A)ccess Control

There is no Windows 95 access right equivalent to the NetWare "Supervisor" right.

"Change Access Control" is equivalent to the NetWare Access Control right, but no utilities shipped with Windows 95 allow users to change their access rights on a share: it must be done on the server.

Rights Flow Behavior

Before examining how access rights flow down a directory tree, it is necessary to make the distinction between two types of access rights: explicit and implicit.

Explicit access rights are specifically granted to a user or group at any point in the directory structure of the sharepoint.
Implicit access rights are obtained not through a specific granting of access rights to a directory but through an inheritance of access rights from a parent directory. Windows 95 does not require you to go to each subdirectory of a share and grant explicit access rights: they flow down the directory tree from the level at which they are granted.

The permission flowing behavior in Windows 95 resembles the Novell NetWare inherited rights and explicit trustee assignments with the exceptions of the behavior associated with the "Supervisor" right and the fact that there is no inherited rights mask at the directory level.

To determine the "effective rights" for a user in a directory on a Windows 95 NCP server, check to see if there has been an explicit assignment for that user for that directory. If there has, then the access rights match the explicitly granted rights. If there hasn't, the user inherits implicit access rights from the parent directory.

User vs. Group vs. "World" Account

If a Windows 95 server grants explicit access rights to both a user name and the group name (to which the user belongs), the access rights granted to users for the share or directory are those assigned the user name. User access rights override group access rights. Novell NetWare servers, by contrast, combine user and group rights. If a user belongs to multiple groups, the access rights of the multiple groups are combined.

The "World" Account is a special account supplied by Windows 95 (there is none on a NetWare server) that is used to grant access to anyone requesting it as long as they can be validated by the Security Provider. The World account can be used to grant "public" access to disk or printer resources or to troubleshoot pass-though security problems.

SAP vs Workgroup Browsing

With the File and Print Sharing for NetWare Networks service, you can use Advanced Properties to choose two methods for advertising the Windows NCP server on the network: Workgroup Advertising or SAP Advertising. Workgroup Advertising is the Windows 95 NCP server default.

With Workgroup Advertising, Windows 95 NCP servers are placed in workgroups and can be browsed by other Windows 95 machines configured with the Client for NetWare Networks. Computers running Novell's NETX or VLM client do not understand the Workgroup browsing scheme and cannot connect to a Windows 95 NCP server configured only for Workgroup Advertising.

SAP Advertising Scheme

SAP stands for Service Advertising Protocol–the protocol used by NetWare servers to advertise their existence and IPX network addresses on the network. For instance, if you start up servers A, B and C and none of them is aware of the others, here is how the SAP process distributes the necessary configuration information:

Server A broadcasts a SAP packet telling the other NetWare servers of its existence and its IPX network address. The packet contains a list of all the servers server A is aware of and their IPX network addresses. Suppose in this case, server A is not aware of any other NetWare servers except itself.
Servers B and C receive the SAP broadcast and record server A's name and IPX address in their binderies. Server C broadcasts a SAP packet telling the other NetWare servers of all the servers that it knows about, in this case itself and servers A and B.
Servers A and B receive the SAP broadcast and record server C's name and IPX address in their binderies.
Server B broadcasts a SAP packet telling the other NetWare servers of all the servers that it knows about, in this case itself and servers A and C.
Servers A and C receive server B's SAP broadcast and record server B's name and IPX address in their binderies.

Now all the servers are aware of each other through entries in their binderies. This list of servers in the bindery of a NetWare server can be viewed with the Novell SLIST or NLIST utilities found in the LOGIN directory on the SYS: volume.

Name Resolution

Here is the name resolution scheme that a NETX or VLM client uses to attach to a NetWare server.

An NCP Client logs in to server C, making it the NCP Client's default server. The NCP Client wants to attach server A. Before the attachment can take place, the NCP Client must obtain server A's IPX network address.
The NCP Client looks in its default server's bindery for an entry for server A. If it finds an entry, it retrieves the IPX network address and the attachment can take place. If it does not find an entry, the NCP Client sees the error message "File server not found."

The Windows 95 NCP Server does not do SAP advertising by default, so NETX and VLM clients using the binderies of their default NetWare servers do not find entries corresponding to the Windows 95 NCP Servers. Attempts to attach to them from these clients result in "File server not found" error messages.

SAP Advertising is not enabled by default because the SAP browsing model has a theoretical limit of 7000 systems but a more practical limit of about 1,500. Using SAP Advertising as a default setting for Windows 95 NCP servers on a large number of desktop systems in a peer networking environment eventually overloads the SAP model and creates large amounts of broadcast traffic.

Default Configuration for NCP Server–Name resolution

If you examine the default configuration of the Windows 95 NCP Server you see that the Windows 95 NCP Server name appears in the Network Neighborhood and in its workgroup but not with the other NetWare servers in the Entire Network window.

The NetWare servers listed in the Entire Network window correspond to the servers participating in SAP advertising and the list of servers displayed with the Novell SLIST utility. With this default configuration, NETX and VLM clients cannot connect to the Windows 95 NCP server.

On a NETX client, the Windows 95 server does not appear in the server list with the other NetWare servers. When you enable SAP Advertising it acts the same as a NetWare server and advertises its existence to the other NetWare servers. Now you can connect to it using a NETX and VLM client.

Returning to the example network with servers A, B and C, what happens if you replace server A with WIN95, a Windows 95 NCP Server with SAP Advertising enabled? Because SAP Advertising is enabled, the WIN95 server advertises its existence with a SAP broadcast. Servers B and C receive the broadcast and add server A (WIN95)and its IPX network address to their binderies.

If a NETX or VLM client logs in to server C (making C its default server) then tries to attach to the WIN95 server, it reads the server C bindery, finds the entry for WIN95 and gets the IPX network address to perform the attachment.

With SAP Advertising enabled, the WIN95 server appears in the Entire Network window with the other NetWare servers AND in its workgroup. This is still only one server: it is just participating in two advertising and browsing schemes. Since the servers listed in the Entire Network window correspond to those participating in SAP advertising, NETX and VLM clients can now connect to the WIN95 NCP server.

This section discusses accessing network resources: the connection process, the functionality of password caching, how to map drives, how to capture printers and how Windows 95 supports an automated setup of network printer drivers called "Point and Print." It also discusses sharing network resources: the processes for sharing local files or printers, and the Microsoft Print Agent for NetWare.

Accessing File Resources with Explorer

You can find servers by viewing the Network Neighborhood and Entire Network lists.

Network Neighborhood Contents	Entire Network Contents
Already attached servers	All Novell NetWare servers (SLIST)
Yourself if you are an NCP server	Windows 95 NCP Servers if enabled for SAP Browsing
Shortcuts	Windows 95 NCP Server workgroups

Connecting to Servers

This is equivalent to NetWare ATTACH. There are three ways to attach to any NCP server (including Novell NetWare servers and Windows 95 NCP servers) using the Windows 95 user interface:

Double-click on the server icon
Start-Run \\<server name>
"Attach as" from Server context menu

Double-clicking on the server icon or doing a "Start-Run" complete the connection automatically. Here is the sequence of events.

The user's logon UserName-Password combination used to initially log into Windows 95 according to the "Primary Network Logon" setting in the Network Control Panel are sent. If this is successful, the connection is made.
If the attempt fails owing to an invalid user name or an invalid password, Windows 95 searches the password cache for an entry corresponding to the server name.
If an entry is found, Windows 95 sends the UserName-Password for the server entry in the password cache. If this is successful, the connection is made.
If an entry in the password cache is not found, Windows 95 prompts the user with a dialog to enter manually a user name and password with an option to connect as GUEST and an option to save this name and password in the password cache.

If you use "Attach As..." you are always prompted with a dialog to enter manually a user name and password with an option to connect as GUEST and an option to save this name and password in the password cache.

A Windows 95 password cache entry consists of a [ServerName-UserName-Password] combination. In Microsoft networks, only [ServerName-Password] is required since the UserName is always the Windows 95 logon name. In NetWare networks, however, users can log on to different servers with different user names while retaining their Windows 95 logon name, so the additional UserName field for the password cache entry is required.

An Automatic Attachment Problem and its Solution

The automatic method of attaching to NCP servers can create confusion in some circumstances. Here is an example:

You do not have an account on NetWare server A but you want to connect as a GUEST.
In your first attempt to attach, your logon UserName-Password fails, because this is the first time you have connected to this server and there is no entry in the Password Cache.
You are prompted with a dialog to enter your name with an option to connect as GUEST and an option to save this name and password in the password cache. You have no account on the NetWare server, so you choose to "Connect as guest."
When you attach, if the "Save this password in your password list" box is checked, Windows 95 stores this entry in the password cache: [A, GUEST,<none>].
Later on, you get an account and user access rights on A with a UserName-Password that is different from your Windows 95 logon UserName-Password.
The next time you auto-attach to server A, the Windows 95 logon UserName-Password is sent and fails.
The Password Cache is checked and then the GUEST-<blank> UserName-Password is sent because the server A server entry was found in the password cache.

Because of the automatic reconnection process, you attach to the server with the GUEST account and are allowed only GUEST privileges even though you have an account and rights on the server.

To troubleshoot this type of problem, always verify what UserName is being used for the attachment. For this, you can use the NetWare utility WhoAmI. It shows all the servers currently connected and the usernames used for attachment. In the Windows 95 user interface, you accomplish this by selecting "Who Am I" from the context menu of the specific server or "Who Am I" from the context menu of the Network Neighborhood. The "Who Am I" dialog tells you exactly what name was used to make the attachment.

To replace an undesired entry in the password cache, select "Attach As" from the context menu of the specific NCP server. When prompted, enter the proper UserName-Password for the server and check the "Save this password in your password list" box.

Returning to the example above, you must do this to correct the problem:

Bring up server A in the Network Neighborhood/Entire Network window
Select "Attach As"
Enter the correct user name and password for server A
Check the "Save this password in your password list" box
Click OK

This attaches to server A and saves the proper UserName and Password in its password cache for future auto-attachments.

Mapping Drives

MAP and MAP ROOT

To MAP drives, follow this procedure:

Open the server using the Network Neighborhood
Open a server volume
Open a server volume directory
Select Properties of the directory
Select which drive letter to be mapped
To MAP ROOT, select the "Map as Root of the Drive" checkbox

Drive Mapping Dialog (Always a MAP ROOT)

This dialog is available through the Explorer Toolbar and through the Context Menu of Network Neighborhood. You can enter the path to the NetWare resource in Novell NetWare syntax (<Server>\<Volume>:<Path>) or UNC (Universal Naming Convention) syntax (\\<Server>\<Volume>\<Path>)

Search Drives

Just as in Windows 3.1, you cannot do search drive mappings (which also change the PATH MS-DOS environment variable) while in Windows because you cannot make global changes to MS-DOS environment variables while in Windows 95, with the exception of the Windows 95 Login Script Processor.

Using the Novell MAP Command

Run the MS-DOS Prompt
Use the Novell MAP command

Search Drive Mappings Local to VM Using MAP Command

You can make search drive mappings using the Novell MAP utility, but they are local to that MS-DOS VM only: when you close the MS-DOS VM, its search drive mappings are lost.

Capturing Printers

For Windows applications, Windows 95 can print directly to a print queue without having to capture an LPT port. Print captures are printed to a NetWare print queue based on a UNC-based path name, rather than printing to the port name. Since an MS-DOS LPT port for each printer connection does not have to be redirected, there are no limitations of 3 or 9 LPT ports that can be captured.

Here is the procedure for capturing a printer port:

Open the server
From the Context Menu, select "Capture Printer Port"
Select the port
Select OK

This is the equivalent of the CAPTURE command with the command line options: S=server Q=queue L=x. It performs redirects of the selected port only for MS-DOS Applications to the NetWare print queue location. The procedure has not installed Windows printer drivers or allowed you to modify additional capture command line options.

You can also install a network printer from the Printers folder using the Add Printer Wizard. During the installation process, you must tell the Wizard which print queue on which NetWare server and whether or not you want this network resource to be available for MS-DOS programs. If the NetWare print queue is to be made available to MS-DOS programs, you must also redirect a local LPT port to the NetWare print queue.

Capture Settings

To change CAPTURE command line options, get properties on the installed network printer in the Printers folder and select the "Capture Settings" tab.

Point and Print

Point and Print installation is a drag-and-drop network printer installation that automatically installs the printer and copies its drivers over the network. All you have to supply is a friendly name for the printer. Point and Print installation works for any Windows 95 print share and for NetWare print queues that have been set up for Point and Print support.

To install the driver files for a network printer driver, drag the Point and Print enabled network printer icon from the server's shared resource window to the Printer Folder window. You can also select "Install" from the Point and Print enabled network printer's context menu or double-click on the network printer icon.

For Windows 95 servers, Point and Print is automatically supported and requires no setup. For NetWare servers, a network administrator must perform extra steps on the server to enable this functionality. There is no way to tell if a network printer is point-and-print enabled from its icon's appearance or properties.

Point and Print Specifics

For Point and Print to be enabled for a network printer, the server sharing the printer needs this information:

The printer name and configuration
Which printer driver files are needed
Where those files are located

The files needed to set up a Point and Print network printer are the printer drivers as specified in the Windows 95 printer INF files.

Setting up Point and Print for a NetWare Server Print Queue

To enable Point and Print on a NetWare server, Windows 95 must write some configuration information to the bindery on the NetWare server that is accessible from any Windows 95 client: properties and values that Windows 95 clients can read for the printer name and configuration information, the list of printer driver files and where the printer driver files are located.

You must be logged in as a supervisor or supervisor equivalent to setup Point and Print on a NetWare server because the process requires writing properties and values to the server's bindery.

Setting up Point and Print through the Printers Folder

Log in to the NetWare server as the supervisor or a supervisor equivalent.
Highlight a NetWare print queue on a NetWare server and bring up its Context menu. Select "Point and Print Setup," which appears only if you are logged into the server as the supervisor or a supervisor equivalent.
Select "Set Driver Path" from the cascaded "Point and Print Setup" menu.
Enter the UNC path to the driver files for the above printer model. For NetWare, enter: \\<server>\<volume>\<directory path>. You must use a UNC path. The NetWare syntax of <Server>\<Volume>:\<directory path> is not supported here.
Select "Set Printer Model" from the cascaded "Point and Print Setup" menu.
Select the printer manufacturer and model from the standard print setup dialog box. Windows 95 will check for the existance of the printer drivers in the location you specified in Step 4 and if not found, will automatically copy the correct printer drivers from your local computer to the NetWare server location. This automatic copying process will only occur if you specify the printer driver files location BEFORE the printer model.
Grant users NetWare rights (Read and File Scan at a minimum) to the directory specified in Step 4.

If you specify the SYS:\PUBLIC directory, you do not need to grant any additional rights. If you want to keep all the Windows 95 printer driver files in a separate directory (for example: SYS:\WIN95DRV), you have to use the SYSCON or NETADMIN/NWADMIN utilities and grant the group EVERYONE Read and File Scan rights to the \WIN95DRV directory on the SYS: volume.

The Windows 95 File and Printer Sharing for NetWare Networks service, or Windows 95 NCP server, uses a pass-through authentication security model for its user level security. Here are more details on the process, using as an example a Windows 95 computer using the Windows 95 user interface as the NCP client attempting to connect. When the client attempts to map a network drive or capture a printer corresponding to a shared resource of the Windows 95 NCP server, it passes its security credentials–its UserName and Password. The Windows 95 NCP server checks to see if the user name exists in the bindery of the Security Provider. If not, the user at the NCP client is prompted with a dialog for specifying a different name or the user can login as GUEST.

If the user name exists in the bindery, the password is checked. If the password is incorrect, the user at the NCP client is prompted for a new user name and password.

If the password is correct, then the NCP Client's UserName and Password have been validated by the Security Provider, the NetWare server. The Windows 95 NCP server then checks to see if the user has been granted access rights directly by user name or indirectly through a group membership. If access rights have been granted, access to the requested resource is allowed; if not, access is denied.

Sharing a Directory and Setting Permissions

To share a directory, use the Explorer to select a directory. Then select the "Sharing.." option from the directory's context menu. From the Sharing dialog, select "Shared As" and optionally change the share name.

To grant access to users or groups, click the Add button. Windows 95 reads the bindery of the Security Provider and displays the list of users and groups.

Select users, groups and thier type of access (Read-Only, Full or Custom).

Changing Permissions in a Subdirectory of an Existing Share

Like Novell NetWare, Windows 95 allows you to change the access rights of a user at the directory level. The user must be granted access to the shared directory to allow them access to the share. Beyond that, the user's access rights can be changed at any subdirectory of the share point. To change access rights of a subdirectory, merely select the desired subdirectory and change the access rights for the user or group.

Microsoft Print Agent for NetWare

The Microsoft Print Agent for NetWare (MSPAN) is a 32-bit application designed to run on a Windows 95 computer configured with the Client for NetWare Networks. MSPAN, which can be enabled from the property sheet of any locally-attached printer, provides the Windows 95 computer with NetWare Print Server capability to despool print jobs from a NetWare print server with a single print queue to a locally installed printer.

Using MSPAN does not prevent you from printing to the locally attached printer or from sharing that printer on the network: it is simply another 32-bit application submitting jobs to the local printer's print queue. The locally attached printer can service local print jobs from applications (such as WINWORD.EXE), from the network server and despooled print jobs from the NetWare print agent all at the same time. You do not have to have a network server installed to use the MSPAN.

The MSPAN is installed as an additional network service from the Windows 95 CD using the Network Control Panel.

Despool Print Jobs from NetWare Print Server

A Novell NetWare print server machine is typically either a dedicated computer or a Novell NetWare server configured to despool print jobs to a locally attached or remote printer. In either case, the computer acting as the print server machine can have multiple printers attached through the various ports (LPTx:, COMx:) and can be configured to service multiple print queues. The Windows 95 MSPAN is designed to despool from a single NetWare print queue.

Configuration of Print Queue and Print Server

A properly configured printer server object for the MSPAN is that which is designed to despool from only one print queue. The print queue is set to print using Printer 0-Remote Parallel, LPT1 on the print server object. Configuration of print queues and print server can be done from the Novell PCONSOLE or NWADMIN programs.

Configuration of Local Printer

To bring up the printer properties of a locally installed printer:

Select the "Enable Microsoft Print Server for NetWare" option on the Print Server property sheet (all NCP servers accessible on the network are listed in the NetWare Server drop-down list).
Select your server (the available Print Server object names configured on the NetWare server appear in the Print Server drop-down list if you are logged in to the NetWare server).
Select the print server object name from the drop down list.
Select the print server name for which the Windows 95 machine will act as the print server machine.
Adjust polling if necessary (high = 15 seconds for maximum print server performance; low = 3 minutes for increased local performance; default = 30 seconds).

Print Server Agent Printing Process

When the NCP workstation prints, it sends the print job to the NetWare server. The job ends up as a spool file in NetWare server's print queue directory.
The Windows 95 machine polls the NetWare server to see if there are any print jobs in its print queue subdirectory, sees the NCP workstation's print job, and instructs the NetWare server to begin sending the spool file across the network. MSPAN receives the job and sends the raw printer data to the local print queue as if it were any other printing application.
When the entire print job has been despooled from the NetWare server, the Windows 95 print subsystem begins sending the document to the locally installed printer.

RPrinter functionality without RPRINTER.EXE

MSPAN causes a Windows 95 workstation to act like a Novell remote printing workstation running RPRINTER.EXE in that it despools jobs from NetWare print queues to a locally attached printer on a non-dedicated computer. However, MSPAN is a version of PSERVER not of RPRINTER.

Rolling out Windows 95

This section shows step-by-step what you need to do to prepare your NetWare networks for a company wide upgrade to Windows 95.

Review of Deployment Process

The Deployment process is outlined in the Windows 95 Resource Kit. Here is a summary:

Review the Product: The first step toward a successful migration to Windows 95 is for you, the IS manager or support staff in your organization, to learn the technical side of Windows 95. There are a number of resources available such as the Microsoft Windows 95 Reviewer's Guide, the Microsoft Windows 95 Resource Kit. These and other sources of information are available on the TechNet CD.
Assemble the Planning Team and Tools: Assemble the resources and information needed to plan the implementation: Windows 95, the proper staff, test computers and an inventory of your hardware and software.
Specify the Preferred Client Configuration: Determine the primary client configuration, or configurations, to be used under Windows 95. This is especially important with NetWare, which has three clients to choose from: the MS CFNN, the NETX client, and the VLM client. Novell may provide a new 32-bit client designed for Windows 95.
Conduct the Lab-Test: Begin evaluation and testing. Testing is the key to a successful and easy migration to Windows 95; it will help you isolate and solve problems you and your users may encounter.
Plan the Pilot Rollout: Prepare for and plan the actual rollout of Windows 95 to your organization: create a server-based Windows 95 setup, create setup batch scripts to customize the setup process to your specifications, and modify your servers to do an automated, or "push" install.
Conduct the Pilot Rollout: The pilot rollout tests your system on a small group to help you identify problems or issues that may arise when you roll Windows 95 out to your entire organization.
Finalize the Rollout Plan: Modify your Rollout Plan based on feedback from the users in the Pilot Rollout and solve any problems encountered.
Roll out Windows 95: The final step.

This rest of this section is a step-by-step examination of NetWare-specific issues you need to consider during the Windows 95 deployment process.

Step 1: Install Windows 95 on a single PC

You must install Windows 95 on a single PC in order to test the changes being made to your NetWare network and for the server-based setup of Windows 95. You will probably already have it installed by this time, but if it has not been done, you must do it before you start.

Step 2: Change Server Configuration

You need to make some changes to your NetWare servers to support the enhanced features of Windows 95.

Login scripts
User profiles
System policies
Long filename support
Windows 95 NCP server
Network printing

Login Scripts

If you are using the Windows 95 Client for NetWare Networks, the system and user login scripts cannot be used to load TSRs or device drivers with the "#" or "EXIT" login script commands. This procedure loads them in an MS-DOS VM during the processing of the login script and they are discarded when the MS-DOS VM is closed.

Search the User Login Script with SYSCON or edit the NET$LOG.DAT in SYS:\PUBLIC. For the user login scripts, you could use the Find utility in the Windows 95 shell to scan all the LOGIN files from SYS:\MAIL for instances of the "#" login command or the "EXIT" command.

If you use the Microsoft Client for NetWare Networks and login to a NetWare 4.0 server, your NetWare 4 Organizational Unit, Profile and User Login scripts are not processed. The current Login Script Processor for the Client for NetWare Networks does not recognize the login script properties of NDS objects.

If you want to use the Microsoft Client for NetWare Networks and NDS login scripts is the only functionality you would be missing, here is a procedure to get NetWare 3.x system and user login script functionality.

As a workaround, you can create the following files to emulate a NetWare 3.x server with respect to login scripts. When the Login Script Processor runs, it looks for a file called <Preferred Server>\SYS:\PUBLIC\NET$LOG.DAT for the System Login Script. Create a system login script file with this name and place it in <Preferred Server>\SYS:\PUBLIC.

When the System Login Script is complete, the Login Script Processor looks for a file called <Preferred Server>\SYS:\MAIL\<User ID>\LOGIN for the User Login Script. Create a user login script file with this name and place it here.

If you don't want to process user login scripts, place the login script command "EXIT" at the end of the system login script.

This workaround gives you all the benefits of the Microsoft Client for NetWare Networks and still allows you to login to a NetWare 4.0 server and process system or user login scripts.

User Profiles

Verify that there is enough space on SYS: Volume to hold all user profiles

User Profiles (see Section 2, User Configuration and Security, for more detail) allow users to have customized desktops "follow" them around the network as they login to different machines. To enable this, user profile files are stored in a central user-specific location. In NetWare networks this is on SYS:\MAIL\<User ID>. Some network administrators prefer to keep the SYS: volume small and have all their data stored on another volume. The SYS: volume typically needs to store only NetWare public utilities, user login scripts and custom print job configurations. If this is your situation, verify that there is enough room on the SYS: volume to store this additional information. You will need about 100K per user to store user profiles.

System Policies

As discussed in Section 2, network administrators can use System Policies to restrict or allow users access to parts of Windows 95 for security or safety reasons. System Policies are registry settings that are merged into the local user's registry upon login and can be specified as default settings, by user name, group name or by computer name.

If you wish to take advantage of System Policies, use the Windows 95 Policy Editor, POLEDIT.EXE, to create a set of System Policies in a policy file called CONFIG.POL. When CONFIG.POL is complete, copy it to the PUBLIC directory on your NetWare login servers.

Windows 95 clients logging into that server now will automatically check for the existence of CONFIG.POL and download the appropriate settings.

Long Filename Support

The Microsoft Client for NetWare Networks supports the use of long filenames on NetWare server volumes that have been enabled with the OS/2 namespace. Long filenames make file names easier to use and are used when User Profiles are enabled.

To enable OS/2 Namespace on server volumes:

From the NetWare server console prompt, type "LOAD OS2"
From the NetWare server console prompt, type "ADD NAME SPACE OS2 TO SYS"
Repeat Step 2 for any other volumes on the NetWare server.
Use the INSTALL.NLM and place the line "LOAD OS2" in your STARTUP.NCF. Although some versions of NetWare autoload name space modules before mounting volumes, this line ensures that the OS/2 name space module is loaded.
Verify that the file OS2.NAM in same location as SERVER.EXE on your DOS paritition. If not, NetWare will be unable to mount the OS/2 -enabled volumes when starting the server.

To remove the OS/2 namespace for a NetWare server volume, use the VREPAIR NLM utility.

If the NetWare server is version 3.11, LFN support is disabled by default because of problems with the NetWare 3.11 namespace module, OS2.NAM. To enable this functionality on a NetWare server, you must download and run Novell's OS2NSFIX utility (available on CompuServe) on the NetWare 3.11 server, then add the INI setting 'SupportLFN=2' to the [nwredir] section of SYSTEM.INI to each computer using the Client for NetWare Networks.

Windows 95 NCP Server

If you enable some Windows 95 computers with the NCP Server Service, you need to prepare any of the servers that will be acting as Security Providers for Windows 95 NCP Servers.

Only one Security Provider can be specified, so if you want to grant access to all users, every user must have an account on the Security Provider. In a single server environment, this is already the case. For a multiple server environment, designate one server to hold the master list of accounts and add the entire organization's list of accounts to that server. Have the users synchronize their passwords between their login server and the server with the master list.

Create the account WINDOWS_PASSTHRU, which is used during the pass-through authentication process. Create the WINDOWS_PASSTHRU account so that it has no password (which does not expire) and no rights granted to it through explicit or group membership.

Network Printing

If you want to enable NetWare server print queues for Point and Print Support: log on as supervisor or as a supervisor equivalent to the computer already configured with Windows 95 and use the "Point and Print Setup" menu option from the context menu of the NetWare print queue icon using the procedure described in section 3.

If you want to use MSPAN, reconfigure your print server and print queue objects so that it is a supported configuration of MSPAN.

Step 3: Change Workstation Configuration

Make these changes on the client before workstation setup:

Reconfigure to support 32-bit MS Client
Verify that a 32-bit netcard driver is available
Remove any unneeded real mode NetWare TSRs so that Windows 95 Setup will upgrade the entire NetWare Stack
If you want to do an "push" installation of a server-based setup of Windows 95, modify each workstation's AUTOEXEC.BAT to include an MS-DOS environment variable to uniquely identify the individual computer. This computer name is independent of the login name of the individual who is using it. The example used in Steps 4 and 5 below is the statement "SET COMPNAME=<Computer Name>"

Default Setup Behavior

If a client is not specified during the creation of default or custom setup scripts, Windows 95 Setup attempts to upgrade as much as possible to protected mode components. It makes this determination based on the real mode client installed, how it is being used, and what additional Novell or 3rd party TSRs and utilities are being used.

Windows 95 uses the settings in a file called NETDET.INI to determine how it will respond in a given circumstance.

Upgrade Entire Stack
- NETX only
- Btreive
Upgrade Client but Leave Real Mode IPX
- LAN Workplace
- DOSNP.EXE
Leave Existing Client in Place
- NDS
- NetWare/IP

Step 4: Server Based Setup

Windows 95 supports a server-based installation like Windows 3.1 but has been enhanced to support easier customization of the installation and floppy and remote booting workstations.

Setup Options

Windows 95 can be setup on a standalone workstation (Local Install) or as a Server-Based Setup where the majority of the Windows 95 program files are located in a central place on a network server and user and computer specific files are installed elsewhere (either on a local hard disk or in another network location).

Server-based setup is done from a separate program on the Windows 95 CD called NETSETUP.EXE which can only be run from a Windows 95 workstation.

Note that you no longer run SETUP /A and SETUP /N to do a server based setup as you did in Windows 3.1 and that you cannot install a server-based setup of Windows 95 in the same location as the administrative installation of Windows 3.1.

NETSETUP.EXE Program

The NETSETUP.EXE program is used to accomplish the following on a NetWare network:

Copy Windows 95 shared files to a network server location such as \\NW312\SYS\WIN95SBS
Create a default setup script used to automate the install process (MSBATCH.INF) whcih is placed in the Windows 95 server based setup location
Create machine directories for the individual computers on your network such as \\NW312\SYS\WIN95_MD\<Computer Name>. For the <Computer Name>, use the same computer name designation as entered in the DOS SET statement in Step 3 above so that each computer running a server-based setup will have their own machine directory corresponding to their unique computer name.
Optionally, create machine specific setup scripts (NETSETUP.INF) which will be placed in the appropriate machine directory.
Grant read and write rights for all users to the Windows 95 machine directories

The machine directory is the network location that contains the computer specific and default user files such as INI files, the Windows 95 Registry and files that make up the Desktop and Start Menu. Machine directories are only required for floppy and remote booting workstations and are optional for hard-disk workstations.

If you currently use Windows 3.1 in a server-based setup, the location of the SETUP/N files may be the user's home directory. The Windows 3.1 SETUP/N files contain both the user specific files (WIN.INI, Program Manager groups, other INI files) and the computer specific files (SYSTEM.INI, WIN.COM). Windows 95 is attempting to separate these groups of files into the machine directory and user profiles. The machine directory contains all the machine specific information (SYSTEM.DAT portion of the registry) for Windows 95 to boot for a given computer and its configuration and a default set of user files. User profiles contain all the user specific information (USER.DAT portion of the registry) and is based on an individual's login name.

The end result of separating these groups of files is support for the roving user and for multiple users using the same computer. When any one of possible multiple people runs Windows 95 on a given computer, the computer settings are loaded from the machine directory and the user settings are loaded either from the machine directory or from thier user profile.Workstation Configuration Options

Hard disk workstations have the option of doing a local installation or a server-based installation where the user and computer files are stored either on the local hard disk or in a machine directory on the network. Floppy and remote booting workstations must use a server-based installation where the user and computer files are stored in a machine directory on the network.

To run Windows 95 in a server based configuration, a workstation must be able to get to the server-based installation of Windows 95 before Windows 95 can be launched. This must happen in real mode, so Windows 95 provides real mode versions of a NETX-compatible NCP redirector and IPX protocol.

Transitioning

When a Server Based Workstation boots, it loads the Real Mode NCP Client and prompts the user to login to the NetWare server. Once the user is verified by the server and the login script is run, Windows 95 is launched.

Upon launching Windows 95, the network software is transitioned from a real mode stack to a protected mode stack. Connection information is transferred to the protected mode counterparts and the Real Mode stack is shut down and its memory is reclaimed.

Step 5: Roll out Windows 95 to the Workstation

Deployment Strategies

When you have performed the server-based setup and created default or custom setup scripts, you are ready to perform the workstation installations and roll out Windows 95 to your users. There are several ways you can do this:

You can send out a memo or e-mail telling users to run Windows 95 Setup, leaving installation to them.
If your e-mail system is an OLE-enabled Windows application, you can send out an e-mail message containing a link or command line to run Windows 95 Setup, still leaving installation to the user.
As network administrator you can go to each workstation and run setup. If you manage a large network, you may not like this method.
If you have network management software that supports automatic installation of new software you could use it to automate the running of Windows 95 SETUP.EXE for each workstation.
Another way to rollout Windows 95 using the setup scripts you created is through an automated, mandatory installation scheme called the "Push Installation."

Push Installation through the System Login Script

To make the Windows 95 installation mandatory and automatic, tie it in with something that users must do every day, login to their NetWare server, and process their system login script. Here is the procedure:

Windows 95 SETUP.EXE requires 416k of free conventional memory to run. If you run SETUP.EXE as an external command using the "#" login script command, you may not have enough memory. The NetWare 3.x LOGIN script processor has too much memory overhead due to the LOGIN.EXE login script processor, so you cannot run Windows 95 SETUP.EXE. You can run Windows 95 Setup directly with the # command with the NetWare 4.x Login Script processor, however.

For the login script you will need to:

Check to make see if Windows 95 has already been installed
Check to see if there is a custom setup script NETSETUP.INF for that computer: if there is, use it; if there isn't, use the MSBATCH.INF in the Windows 95 server based setup directory.

Note: For more information on using batch setup scripts in Windows 95 see the detailed information in the Windows 95 Resource Kit and the sample batch scripts in the Resource Kit Utilities.

Unfortunately, you can't check for the existence of files using Novell Login script commands. You can with MS-DOS batch files by running the Push installation as an MS-DOS batch file called in the SYSTEM login script by means of the EXIT command. Programs or batch files run with the EXIT login script command do not have the overhead of the LOGIN.EXE login script processor.

In the batch file, run SETUP.EXE with a command line parameter indicating which setup script to process to run an automated installation: in some cases using the default MSBATCH.INF and in some cases using the custom NETSETUP.INF created for an individual user.

The example below assumes the following:

The current configuration is Windows 3.1 with an Administrative installation (SETUP /A) in SYS:\WIN31
The current network installation of Windows 3.1 (SETUP/N) is in the user's home directory SYS:\USERS\%LOGIN_NAME which is mapped to drive U:
The DOS environment variable COMPNAME has been placed in the workstation's AUTOEXEC.BAT to uniquely identify the computer (see Step 3 above)
Machine directories have been created for each computer by computer name in SYS:\WIN95_MD and all users have been granted read and write rights to SYS:\WIN95_MD.
A group has been created called WIN95UPGRADE which is used to control the deployment process

Login Script Commands for NetWare Server NW312:

map insert root s1:=nw312\sys:\public
IF MEMBER OF "WIN95UPGRADE"
     MAP INSERT ROOT S2:=NW312\SYS:\WIN95SBS
ELSE
     MAP INSERT ROOT S2:=NW312\SYS:\WIN31
END
MAP ROOT U:=NW312\SYS:\USERS\%LOGIN_NAME
IF MEMBER OF "WIN95UPGRADE" THEN
     MAP ROOT M:=NW312\SYS:\WIN95_MD\%<COMPNAME>
     DRIVE M:
     EXIT "Z:PUSHINST"
END

PUSHINST.BAT on SYS:\PUBLIC (Z:)

@echo off
if exist m:\system.dat goto :end
if exist m:\netsetup.inf y:setup m:\netsetup.inf
if not exist m:\netsetup.inf y:setup y:\msbatch.inf
:end

The second line in PUSHINST.BAT checks for SYSTEM.DAT, a Windows 95 registry file which will be present in the machine directory if Windows 95 is already installed.

To upgrade a given user:

Copy the Windows 3.1 SETUP /N files (WIN.COM, WINVER.EXE. *.INI, *.GRP) from thier home directory (SYS:\USERS\%LOGIN_NAME) to the machine directory corresponding to the computer they will use most often and will be using when performing the upgrade (SYS:\WIN95_MD\<Computer Name>. When these files are found in the machine directory, Windows 95 will perform an upgrade and maintain the user and applications settings instead of performing a fresh installation.
Add that user to the WIN95UPGRADE group
Have the user login to the NetWare server

This is just one way, not the only way, to perform a push installation.

Changing Clients

You may have to change clients on some workstations to test functionality or troubleshoot. Four methods are shown below.

From NETX to MS

Remove the NETX client
Remove ODI IPX
Add the Microsoft NetWare client

This changes the netcard to NDIS 2/3 and REMs the NETX and ODI Lines in AUTOEXEC.BAT.

From VLM to MS

Remove the VLM client
Remove ODI IPX
Add the Microsoft NetWare client

This changes the netcard to NDIS 2/3 and REMs the CALL STARTNET.BAT line in AUTOEXEC.BAT.

From MS to NETX

This assumes NETX was previously installed and Windows 95 replaced NETX with the Microsoft Client. This would REM the ODI and NETX lines in AUTOEXEC.BAT

Remove the Microsoft client
Remove IPX/SPX Compatible Protocol
Change Netcard to ODI
Add Novell NETX client

This Un-REMs lines in AUTOEXEC.BAT and CONFIG.SYS files.

From MS to VLM

This assumes VLM and VLM Windows components were previously installed and that Windows 95 replaced the VLM with the Microsoft Client. This would have REMed the CALL STARTNET line in AUTOEXEC.BAT.

Remove the Microsoft client
Remove IPX/SPX Compatible Protocol
Change Netcard to ODI
Add the Novell VLM client

This un-REMs the CALL STARTNET line in AUTOEXEC.BAT.

Conclusion

This article has presented a thorough, step-by-step explanation of Windows 95's support for the Novell NetWare network operating system. Although the support is already extensive, it will continue to increase in breadth and depth as Novell and Microsoft continue to expand their working relationship.

This article was derived from a Microsoft Traincast session. If you are interested in other Traincast offerings, call 1-800-597-3200 or e-mail mstv@microsoft.com.

Joe Davies is a trainer for Microsoft's WorldWide Training department doing course development and training for Microsoft support engineers. Joe started out at Microsoft as a support engineer supporting Windows 3.0. Joe has been doing Windows and network training for over two years and specializes in NetWare networking. Joe wrote the networking portions of the WorldWide Training Windows 95 Support Course and was certified by Novell as a Enterprise Certified NetWare Engineer in July of 1995.

Introduction

On This Page

Architecture and New Features

Microsoft's Client for NetWare Networks: Architecture

Microsoft's Client for NetWare Networks: Features

Windows 95 Support for Novell's NETX and VLM Clients

Basic Usability

User Configuration and Security

Windows 95 Logon

User Profiles

System Policies

Windows 95 NCP Server

Directory Security on NCP Server

SAP vs Workgroup Browsing

Accessing File Resources with Explorer

Mapping Drives

Capturing Printers

Microsoft Print Agent for NetWare

Rolling out Windows 95

Review of Deployment Process

Step 1: Install Windows 95 on a single PC

Step 2: Change Server Configuration

Step 3: Change Workstation Configuration

Step 4: Server Based Setup

Step 5: Roll out Windows 95 to the Workstation

Conclusion

Additional resources

Introduction

On This Page

Architecture and New Features

Microsoft's Client for NetWare Networks: Architecture

Microsoft's Client for NetWare Networks: Features

Windows 95 Support for Novell's NETX and VLM Clients

Basic Usability

User Configuration and Security

Windows 95 Logon

Windows 95 Login Script Processor

User Profiles

System Policies

Windows 95 NCP Server

Directory Security on NCP Server

SAP vs Workgroup Browsing

Accessing and Sharing Resources

Accessing File Resources with Explorer

Mapping Drives

Capturing Printers

Sharing File Resources with Explorer (NCP Server)

Microsoft Print Agent for NetWare

Rolling out Windows 95

Review of Deployment Process

Step 1: Install Windows 95 on a single PC

Step 2: Change Server Configuration

Step 3: Change Workstation Configuration

Step 4: Server Based Setup

Step 5: Roll out Windows 95 to the Workstation

Conclusion

Additional resources