Novell is now a part of Micro Focus

Overview of Novell's IntranetWare Client for Windows NT

Articles and Tips: article

BRETT GARRETT
World Wide Support
Novell Support Division

KEVIN WILSON
World Wide Support
Novell Support Division

01 May 1997


Novell developed the IntranetWare Client for Windows NT to bring the full power, ease of use, manageability, and security of IntranetWare/NetWare 4.x to Windows NT workstations. This AppNote provides a look into the client's inner workings.

Introduction

With the growing popularity of Microsoft's Windows NT as the desktop operating system of choice for large organizations, Novell has developed the IntranetWare Client for Windows NT to bring the full power, ease of use, manageability, and security of NetWare 4 and IntranetWare to Windows NT workstations. With the IntranetWare Client for Windows NT, organizations can take full advantage of IntranetWare services, such as Novell Directory Services, and the high performance of the NetWare Core Protocols (NCPs). The IntranetWare Client also includes the Novell Application Launcher (NAL) and NetWare Administrator (NWAdmin) utilities, as well as the new Workstation Manager program to simplify NT user account management.

This AppNote describes the basic networking architecture of Windows NT Workstation v4.0 and explains how Novell's IntranetWare Client for Windows NT ties into that architecture to provide the most comprehensive access to Novell's advanced networking services from NT workstations. It covers the following topics:

  • Microsoft Windows NT v4.0 networking architecture

  • IntranetWare Client architecture for File System Driver

  • IntranetWare Client architecture for NDIS and ODI LAN drivers

  • IntranetWare Client architecture for applications

  • IntranetWare Client architecture for Network and Printing Providers

  • IntranetWare Client architecture for graphical authentication and identifcation (GINA)

  • IntranetWare Client architecture for TCP/IP and NetWare/IP

  • Documentation and technical support for the IntranetWare Client

To learn more about the other Windows NT integration products mentioned above, refer to the April 1997 special issue of Novell AppNotes, or visit Novell's web site at http://www.novell.com.

IntranetWare Client for Windows NT Architectural Overview

Novell's IntranetWare Client for Windows NT is a full 32-bit client which takes full advantage of the Windows NT 3.51 and NT 4.0 workstation architecture. Its architecture differs from the NIOS-based Client 32 architecture used in the IntranetWare Client for Windows 95 in that the IntranetWare Client for Windows NT is a Redirector/File System Driver rather than an Interrupt 21 shell. The NT Client features 32-bit native support for applications written to NetWare's IPX/SPX APIs, as well as full 16-bit DOS/Windows 3.x IPX and SPX API emulation and global DOS support for applications designed to run with the previous NetWare DOS Requester (VLM) and NetWare Shell (NETX) client software. It also provides advanced features such as full automatic reconnection to network files and resources, and simultaneous access to multiple NDS trees. (See Appendix A of this issue for a full listing of IntranetWare Client for Windows NT features.)

The purpose of this architectural overview is to help the reader understand how Novell's IntranetWare Client for Windows NT fits into the Microsoft Windows NT Workstation architecture. This overview will discuss the following:

  • Microsoft Windows NT networking architecture

  • IntranetWare Client for Windows NT Redirector/File System Driver

  • Support for NDIS and ODI LAN drivers

  • Support for 16-bit DOS and Windows 3.x applications and for 32-bitWindows applications

  • Network and Print Providers

  • GINA (Graphical Identification and Authentication) login facility

  • Support for TCP/IP and NetWare/IP

Microsoft Windows NT 4.0 Networking Architecture

Windows NT Workstation is a 32-bit, multitasking operating system that was designed from the start with networking in mind. It uses an object model to provide user access to local and network resources such as files, directories, and printers. To support interoperability with Microsoft, Novell, TCP/IP (Unix), and other types of networks, Windows NT is built on a modular design in which various objects or components perform specific tasks within the operating system environment. Individual network components can be replaced with newer ones or with counterparts from other vendors. This allows multiple network redirectors to coexist in the Windows NT workstation.

Figure 1 is a representation of the Windows NT Workstation architecture. Since space does not permit a complete discussion of each component shown, we will focus on those that relate most directly to networking functionality.

Figure 1: The Windows NT 4.0 Workstation architecture.

User Mode and Kernel Mode. To run applications of various types, Windows NT has two modes: User Mode and Kernel Mode. User Mode is defined as the applications and the subsystems which support the applications. In User Mode, processes run at a lower priority and are not allowed direct access to hardware. Kernel Mode is defined as the protected area where the NT operating system runs. Processes running in this mode are high priority and have access to all of the computer's hardware and memory resources.

The Windows NT Kernel is made up of thee layers: the Microkernel, the Hardware Abstraction Layer (HAL), and Executive Services. The Microkernel is the core operating system code. It accesses hardware both directly and through the HAL, which is a layer of software that abstracts hardware specific details such as I/O interfaces and interrupt controllers. Instead of dealing with hardware directly, applications and device drivers make calls to HAL routines to determine hardware specific information. Executive Services coordinates the activities of the operating system, such as providing access to the local hard disk, memory, and printers, as well as to network resources. Each specific function is carried out by a software module called a Manager. For example, the Virtual Memory Manager maps virtual memory addresses used by applications into physical memory.

Novell's IntranetWare Client for Window NT has both User Mode and Kernel Mode components. For example, the NetWare Redirector/File System Driver and networking components are part of the I/O Manager module of the Executive Services in Kernel Mode. The IntranetWare Client's NetWare Provider, as well as the 16-bit and 32-bit DOS and Windows support modules, include terminate-and-stay resident (TSR) code and Dynamic Link Libraries (DLLs) that run in User Mode.


Note: In Windows NT v3.51, the WindowsManager, Graphics Device Interface, and Graphics Device Driverswere located in User Mode. In Windows NT v4.0, Microsoft movedthese components into Kernel Mode. These changes have little effecton the IntranetWare Client for Windows NT, which can run on eitherNT v3.51 or NT v4.0 workstations.

Windows NT I/O Manager. In Windows NT v4.0, the I/O Manager controls all input and output to the operating system, including application requests for local and network resources. The I/O Manager is integrated with the following subcomponents:

  • Multiple Universal Naming Convention (UNC) Provider (MUP). When applications make I/O calls that contain UNC names, the requests are passed to the MUP. (UNC is a naming convention for describing the location of a file on a network server and volume.) The MUP negotiates with each redirector to determine which one can best process the request.

  • File System Drivers and Redirectors. There can be a number of File System Drivers (FSDs) and Redirectors loaded on a Windows NT workstation. Common examples include drivers for the NT File System (NTFS), the CD-ROM File System (CDFS), and the Server service (which processes connections requested by client-side redirectors as they attempt to read or write files on remote computers). In Windows NT, client Redirectors are also implemented as FSDs. The IntranetWare Client's File System Driver/Redirector is called NWFS.SYS.

  • Transport Driver Interface (TDI). This boundary layer provides a common interface that File System Drivers can use to communicate with the various network transport protocols, such as TCP/IP or IPX/SPX. This allows users to choose any third-party protocol stack that is written to the TDI API (Application Programming Interface).

  • Transport Protocols. Windows NT supports a number of network transport protocols, including TCP/IP, NWLink (Microsoft's IPX/SPX-compatible protocol for Windows NT), NetBEUI 3.0 (a version of the NetBIOS Extended User Interface that is compatible with the older NBF or NetBIOS Frame Format protocol), AppleTalk, and DLC (the Data Link Control protocol used to access IBM mainframes). In Windows NT 4.0, TDI-based applications and Windows Sockets applications can use TCP/IP as their transport protocol. The IntranetWare Client for Windows NT does not ship with its own IPX/SPX protocol stack, but instead uses Microsoft's NWLink.

  • Network Device Interface Specification(NDIS). NDIS is an interface layer that translates between Network Interface Card (NIC) drivers and the transport protocols.

  • Network Interface Card Drivers. The NIC driver is used to talk to the network card that connects the Windows NT workstation to the network. Network card vendors provide these drivers with their hardware.

Figure 2 illustrates the architecture of these components within the Windows NT I/O Manager.

Figure 2: The Windows NT I/O Manager handles all input and output for the workstation.

The IntranetWare Client Redirector (NWFS.SYS)

The main component of the IntranetWare Client for Windows NT is named NWFS.SYS. Unlike the IntranetWare Client for Windows 95, which is based on the Client 32 NetWare I/O Subsystem (NIOS) and has NetWare Loadable Module (NLM) components, the IntranetWare Client for Windows NT is implemented as a Redirector/File System Driver. NWFS.SYS provides the internal tables and services necessary to track network resources, file caching, and automatic reconnection levels. It is fully backward-compatible with previous Novell client software, so NetWare-aware applications written to earlier client APIs should run without modification under the IntranetWare Client.

NWFS.SYS interacts with the MUP and with the TDI, which it uses to communicate with the underlying transport protocols. Novell does not supply its own IPX/SPX protocol for use with the IntranetWare Client for Windows NT. Instead, NWFS.SYS uses Microsoft's IPX/SPX-compatible NWLink transport. In a TCP/IP environment, NWFS.SYS can use any TDI-compliant TCP/IP protocol stack, including the one that comes with Windows NT.

LAN Driver Support

Novell's IntranetWare Client for Windows NT supports both ODI (Open Data-Link Interface) and NDIS drivers. Windows NT workstations running Microsoft client software always use NDIS drivers. (A small number of ODI drivers are available in the current release of Novell's IntranetWare Windows NT client; expect more to become available in the near future.

Support for NDIS LAN Drivers

The Network Device Interface Specification (NDIS) describes the interface by which network interface card drivers communicate with network interface cards, with protocol drivers, and with the operating system. NDIS allows multiple network cards and protocols to coexist in the same workstation. In Windows NT, the NDIS interface is implemented as a module called NDIS.SYS and is referred to as the NDIS "wrapper" because it surrounds the NDIS device drivers and provides a uniform interface between the drivers and the protocols (see Figure 3).

Figure 3: NDIS protocol stack.

Windows NT supports both NDIS 3.1 drivers (which come with Windows 95) and NDIS 4.0 drivers. However, Microsoft and Novell recommend that you use NDIS 4.0 drivers whenever possible.

Since NWFS.SYS uses Microsoft's IPX/SPX-compatible NWLink transport, no VMLID, LANSUP, or ODI2NDIS modules are required to translate between NDIS and ODI. This was not the case with the previous NetWare Client for Windows NT v3.5. This can cause some problems in cases where NWLink is not 100% IPX/SPX-compliant. For example, NWLink does not the forcing of IPX checksums. If you enable this feature at a NetWare server, a Windows NT client using NWLink will not be able to connect to that server.

Support for 32-bit ODI LAN Drivers

The IntranetWare Client for Windows NT also supports the use of 32-bit ODI LAN drivers through the ODI NDIS support module (ODINSUP). ODINSUP interfaces between NDIS and ODI LAN drivers, presenting itself as an ODI default protocol stack to the Link Support Layer (LSL.SYS) and as an NDIS LAN Driver to the NDIS Wrapper. This enables you to use Microsoft networking components with ODI LAN drivers.

The IntranetWare Client for Windows NT 4.0 supports the following 32-bit LAN driver specifications:

  • Assembly Specification v3.30 (for example, NE2000.LAN)

  • C Specification v1.10 (for example, CNE2000.LAN)

These are the same types of LAN drivers that are used for Novell IntranetWare and NetWare v4.11, and therefore they are NLM-based code. To accommodate these drivers, Novell has written an ODI loader for use with the IntranetWare Client for Windows NT. Figure 4 shows the modules and device drivers needed to support an ODI protocol stack.

Figure 4: ODI protocol stack.

The modules shown in Figure 4 are described below in the order in which they load:

  • LSL.SYS. The Link Support Layer (LSL) is the interface between the ODI protocol stack and the Media Support Module (MSM).

  • NBI.SYS. The ODI Loader module uses the NBI (NetWare Bus Interface) to get adapter hardware information.

  • ODILOAD.SYS. The ODI Loader allocates memory and loads NLM-based LAN drivers. It also contains the Media Support Module (MSM). ODILOAD currently uses the following registry setting to determine which Hardware Specific Module (HSM) to load and which command line parameters to use when it loads: HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/ODIload/ODI_modules

  • TSM (Topology Specific Module). The HSM specifies which TSM loads, such as ETHERTSM.NLM for Ethernet networks, TOKENTSM.NLM for Token-Ring networks, or FDDITSM.NLM for FDDI networks.

  • HSM (Hardware Specific Module). The HSM is the LAN driver (such as NE2000.LAN). It is supplied by the network card manufacturer.

  • ODINSUP.SYS. The ODI NDIS Support Module loads last to provide the interface between NDIS and the ODI LAN driver.

The flow of packets in an ODI configuration is as follows. For a send packet, the NDIS protocol passes the packet down to ODINSUP, which gives the packet to the LSL. From there, the packet flows through the ODI modules and is placed on the wire by the ODI LAN driver. For a recieve packet coming from an ODI LAN driver, the reverse occurs. The packet travels up through the ODI modules to the LSL, which passes the packet to ODINSUP, which in turn hands the packet to the NDIS protocol.

Application Support

The following sections describe how various types of applications make NetWare calls and how requests for NetWare services are processed in a Windows NT workstation running the IntranetWare Client for Windows NT.

Support for 16-bit DOS Applications

On Windows NT workstations, DOS-based applications run in a Win32-based application called the NT Virtual DOS Machine (NTVDM.EXE). Each DOS application runs in a separate NTVDM. Each NTVDM has its own memory space and is protected from other NTVDMs. In an NTVDM session, NTIO.SYS loads to emulate MS-DOS's IO.SYS and NTDOS.SYS loads to emulate MSDOS.SYS. By default, an NTVDM session loads the CONFIG.NT and AUTOEXEC.NT files that are located in the \<WINNT root<\system32directory.

The IntranetWare Client installation program modifies the AUTOEXEC.NT file, adding the following two lines to load modules necessary to support DOS applications:

%SystemRoot%\system32\vipx.exe %SystemRoot%\system32\vlmsup.exe

Figure 5 illustrates how a DOS application makes a NetWare DOS API call and an IPX/SPX API call.

Figure 5: Flow of a NetWare API call from a 16-bit DOS application.

In Figure 5, the VLMSUP.EXE module (a TSR) intercepts the NetWare DOS API calls. VLMSUP.EXE uses the 32-bit VLMSUP.DLL to access the Novell 32-bit Client libraries, which pass the call to a module in NT Executive Services, such as the I/O Manager. From here, a call will be made to the Requester (NWFS.SYS). The NetWare Requester will complete the request. All non-NetWare-specific DOS API calls, such as DOS file system calls, are routed by the NTVDM to the appropriate installed file system.

Figure 5 also shows the DOS application making a NetWare IPX/SPX API call. In this case, a TSR called VIPX.EXE intercepts the call and calls the Novell 32-bit VIPXVDD library. The VIPXVDD.DLL module forwards the call to NWSIPX32.DLL, which communicates with NWSIPX32.SYS. NWSIPX32.SYS makes a call directly to NWLink through the TDI interface to deliver the IPX/SPX packet onto the network medium.

Support for 16-bit Windows Applications

16-bit Windows applications also run in an NT virtual DOS Machine (NTVDM.EXE). As with DOS applications, the NTIO.SYS, NDDOS.SYS, AUTOEXEC.NT, and CONFIG.NT files are loaded and started. Before a Windows 16-bit application initializes, the NT workstation loads a program known as WOW (Win16 on Win32) through WOWEXEC.EXE. At this time, NT also loads modified versions of KRNL386.EXE, USER.EXE, and GID.EXE, which emulate a Windows 3.1x environment for the Win32 subsystem.

Figure 6 illustrates how a 16-bit Windows application makes a NetWare API call and an IPX/SPX API call.

Figure 6: Flow of a NetWare API call from a 16-bit Windows application.

When a Windows 16-bit application makes a NetWare Windows API call, the Novell 16-bit libraries pass the call on to the VLMSUP.EXE TSR module. VLMSUP.EXE calls the 32-bit VLMSUP.DLL, which forwards the call to the Novell 32-bit libraries. The Novell 32-bit libraries pass the call to a module in NT Executive Services, such as the I/O Manager. From here, a call will be made to the NetWare Requester (NWFS.SYS). The NetWare Requester will complete the request. All non-NetWare-specific Windows/DOS API calls, such as DOS file system calls, are routed by NTVDM to the appropriate installed file system.

When a Windows 16-bit application makes an IPX/SPX NetWare API call, the Novell 16-bit library (NWIPXSPX.DLL) passes the call to the Novell 32-bit library (IPXVDD.DLL). This module forwards the call to NWSIPX32.DLL, which communicates with NWSIPX32.SYS. NWSIPX32.SYS makes a call directly to NWLink through the TDI interface to deliver the IPX/SPX packet onto the network medium.


Note: The NWIPXSPX.DLL module that ships with IntranetWare Client for Windows NT must be used if the IPX/SPX NetWare API calls are to function. This is notthe same DLL that ships in the Novell Developer SDK. This cancause problems if an installed application overwrites this DLLor calls it from another directory. If you are having problemswith a 16-bit Windows application that is making IPX/SPX calls,always verify that you are using the NWIPXSPX.DLL that ships withthe IntranetWare Client for Windows NT.

Support for 32-bit Windows Applications

The IntranetWare Client for Windows NT supports NetWare 32-bit Windows programing, as shown in Figure 7.

Figure 7: Flow of a NetWare API call in a 32- bit Windows application.

When a 32-bit Windows application makes a NetWare API call, the Novell 32-bit Client libraries pass the call to the appropriate module in NT Executive Services. From there, a call will be made to the NetWare Redirector/File System Driver (NWFS.SYS).

When a 32-bit Windows application makes a NetWare IPX/SPX API call, the Novell 32-bit library (NWSIPX32.DLL) communicates with NWSIPX32.SYS. NWSIPX32.SYS makes a call directly to NWLink through the TDI interface to deliver the IPX/SPX packet onto the network medium.

Network Providers

Some applications use the WNet (Win32 Network) APIs instead of UNC names in their I/O requests. WNet requests are passed to another Windows NT component called the Multiple Provider Router (MPR). Like the MUP, the MPR passes the requests to each redirector in turn until one is found that can process the request. A vendor-specific provider DLL interfaces between the MPR and that vendor's redirector.

Windows NT comes with a provider for each Microsoft network supported; for example, the NTLM Provider accepts requests for a Microsoft LAN Manager network. If an application issues an SMB (Server Message Block) call to a LAN Manager network, the call is passed down through the MPR, where it is routed to the NTLM Provider DLL. Such requests are passed to a File System Driver called the Workstation Service Redirector (RDR), which allows connections to Windows NT, Windows for Workgroups, LAN Manager, LAN Server, and other MSNet-based servers (see Figure 8).

Figure 8:Network providers handle WNet API calls from applications.

The NetWare Provider

Also shown in Figure 8 is the NOVNPNT Provider DLL, a provider Novell supplies with the IntranetWare NT Client to handle applications that make WNet requests for NetWare services. This module uses the Novell 32-bit Client Libraries to access NWFS.SYS, which returns information from the NetWare network to Windows applications such as My Computer, Explorer, and Network Neighborhood. Thus the NetWare Provider allows you to perform network functions such as browsing the network, logging in, authenticating to NDS, and accessing NetWare resources through the native Windows NT interfaces of the My Computer, Network Neighborhood, and Explorer programs. (The functionality made possible via NOVNPNT is described in more detail in the AppNote entitled "Accessing IntranetWare Resources with the NWGINA Logon Interface and the NetWare Provider" in this issue.)

Typically, the installed Network Providers are sorted by a value in the Windows NT Registry database. Providers with lower values are called before those with higher values. One of the providers is designated as the Primary provider.

Print Provider

Like the browsing provider router (MPR) described above, Windows NT Workstation also has a Print Provider Router (PPR). This, along with the assoicated provider DLLs for the various Redirector/File System Drivers the workstation has installed, allows print jobs to be sent to network printers. Novell's Print Provider DLL, called NWSPOOL.DLL, uses the Novell 32-bit Client Libraries to access the IntranetWare Client Redirecor (NWFS.SYS) to send the print job through the network adapter to the NetWare network.

Figure 9 shows the flow of a network print job from a Windows application to a NetWare print queue, as well as to an NT Server print queue, within the Microsoft NT 4.0 Workstation architecture.

Figure 9:The Windows NT 4.0 Print Provider Router.

Printing is further discussed in the AppNote entitled "Setting Up Network Printing with IntranetWare Client for Windows NT Workstation" in this issue.

Graphical Identification and Authentication (GINA) Module

WinLogon is the part of Microsoft Windows NT that provides a user interface for logon support. Pieces of WinLogon are replacable. One such piece is called the GINA (Graphical Identification and Authentication) module. Being able to replace the GINA allows developers to implement other authentication mechanisms or methods.

The standard GINA that ships with Microsoft Windows NT is called MSGINA.DLL. Novell has written its own GINA called NWGINA.DLL which is used to perform all authentication and user interactions. The NWGINA module authenticates the user to a NetWare network (see Figure 10).

Figure 10: Novell's version of the GINA is NWGINA.DLL.

When you install the IntranetWare Client for Window NT, the installation procedure modifies the registry so that NWGINA will be used instead of Microsoft's MSGINA. The resulting registry information is as follows:

Key Name: HKEY_LOCAL_MACHINE

Software


  Microsoft


     WindowsNT


         CurrentVersion


            Winlogon


               Value Name: GinaDLL


Value Type:[REG_SZ]


Value: NWGINA.DLL

Support for the TCP/IP Environment

The IntranetWare Client for Windows NT supports both IPX/SPX and TCP/IP equally. You can thus use either protocol to access NetWare servers. If desired, you can standardize on TCP/IP across the entire network, including NetWare servers, for easier management. Novell does not ship a TCP/IP protocol stack with the IntranetWare Client for Windows NT. The IntranetWare Client is compatible with and can be configured to use Microsoft's TCP/IP stack.

The IntranetWare Client sets up its transport protocol automatically through dynamic and self-configuring protocol parameters. The IntranetWare Client optimizes these parameters automatically for the computer on which they are installed. As a result, administrators do not have to deal with manual configuration.

NetWare/IP Support

The IntranetWare Client for Windows NT supports NetWare/IP. It delivers full NetWare/IP services and operates through the TCP/IP stack that comes with Windows NT. A set of NetWare/IP client drivers is included with the IntranetWare Client software. Updates will be included with new releases of the IntranetWare Client for Windows NT.

Figure 11 shows how support for NetWare/IP is implemented in the IntranetWare Client for Windows NT. The controling module for NetWare/IP in the IntranetWare Client for Windows NT is NWIP.SYS. NWIP.SYS, an NDIS device driver, intercepts all packets from NWLink that originated in the IntranetWare NWFS and routes them through Microsoft's TCP/IP protocol stack. (This will be changed in a future release when IntranetWare and IntranetWare Clients support Native TCP/IP.)

Figure 11: NetWare/IP support in the IntranetWare Client for Windows NT.

NetWare/IP support can be added through the Services tab of the Network Control Panel. This procedure is outlined in the AppNote entitled "Configuring the IntranetWare Client for Windows NT Workstation" in this issue.

Additional NetWare/IP Notes:

  • In the past, NetWare/IP has not performed well on Windows NT 4.0 multiprocessor workstations. This problem has been fixed in the Microsoft Service Pack 2 for Windows NT 4.0.

  • NetWare/IP is not supported on Windows NT Server.

  • NetWare/IP does not support multiple network adapters; in other words, it does not work if you try to use a network adapter other than the one currently being used. NetWare/IP will work on the LAN alone or over a Remote Access Server alone.

Documentation and Technical Support

The help files included with the IntranetWare Client for Windows NT are the primary documentation for the product. These files contain information on understanding, installing, configuring, using, and troubleshooting the client software. To view the online help, select Start | Help | Using IntranetWare Client for Windows NT after the client software is installed. This opens the SETUPNW.HLP file.

Technical support for the IntranetWare Client for Windows NT is provided by all the usual Novell channels.

You can submit enhancement requests for Novell client software by sending an e-mail message to:

enhclient@novell.com

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates