Technical Backgrounder
Created: October 1993
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This paper is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
© 1993 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, and Win32 are registered trademarks and Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation.
Macintosh is a registered trademark of Apple Computer Company. Banyan and VINES are registered trademarks of Banyan Systems, Inc. CompuServe is a registered trademark of CompuServe Inc. ArcNet is a registered trademark of Datapoint Corp. DEC and VMS are registered trademarks and Alpha AXP, DECnet, and Pathworks are trademarks of Digital Equipment Corporation. SQLBase is a registered trademark of Gupta Technologies, Inc. Informix is a registered trademark of Informix Software, Inc. Ingres is a registered trademark of Ingres Corp. IBM and OS/2 are registered trademarks of International Business Machines Corporation. Lotus and Notes are registered trademarks of the Lotus Corp. MIPS is a registered trademark of MIPS Computer Systems, Inc. Novell and NetWare are registered trademarks of Novell, Inc. Oracle is a registered trademark of Oracle Corporation. SYBASE is a registered trademark of Sybase, Inc. UNIX is a registered trademark of UNIX Systems Laboratories.
The Microsoft® Windows™ family of operating systems is designed with interoperability in mind. Increasingly, customers are demanding flexible, open networking capabilities as basic components in operating systems. Microsoft meets these needs today with the Windows for Workgroups operating system with integrated networking, the Windows NT™ operating system, and the Windows NT Advanced Server, all incorporating networking capabilities as integral components.
The Microsoft family of operating systems supports interoperability with the Novell® NetWare® network operating systems. Windows for Workgroups and Windows NT can be configured to access data and printers on Novell NetWare servers. The Windows NT Advanced Server operating system allows existing NetWare clients to access server-based applications as they continue to access NetWare file and print servers. You can add these Windows family operating systems into your existing environments and be assured of compatibility, interoperability, and protection of your investment in existing NetWare servers.
Computers running the Microsoft® Windows™ family operating systems can easily be integrated into a predominantly Novell® NetWare® environment, making the benefits of Windows operating systems available to an existing network:
The networking architectures of Windows for Workgroups and Windows NT play an important role in making them powerful members of many different types of networks. The architectures themselves are protocol-independent, providing standard interfaces for applications (such as Windows Sockets, RPC, and NetBIOS) and device drivers (such as NDIS). This architecture allows computers to run multiple protocols on a single network adapter card, as well as run a single protocol on multiple network adapter cards simultaneously. This makes it easy to incorporate computers running Windows for Workgroups or Windows NT into existing networks so you can take advantage of their ease of use and advanced features without disrupting your enterprise.
A network administrator considering a mixed network environment is naturally concerned about how the various components will be able to communicate with each other. In the case of a mixed Microsoft Networking and NetWare environment, the network administrator wants to ensure that Windows-based workstations added to the network are able to use file and print resources on existing NetWare servers, and that existing NetWare clients can access client-server applications running on Windows NT Advanced Servers.
This section presents an overview of how Windows for Workgroups–based and Windows NT–based computers can effectively function as clients of NetWare servers, and how Windows NT Advanced Servers can function as application servers for NetWare clients.
Figure 1 shows the key components and protocols used in a mixed Windows and NetWare–based network.
Figure 1. Components and protocols in a mixed Windows NT and NetWare environment
Because it was designed to be on a network, Windows NT makes an excellent network client. Its open design enables network redirectors to integrate seamlessly with the operating system. To facilitate easy access to data and printers on NetWare servers, Microsoft is developing a NetWare-compatible redirector for Windows NT, called NetWare Workstation Compatible Service (NWCS). This redirector is now in beta testing, and current plans call for it to be completed during the first quarter of 1994. Using NWCS, you can access data and printers on a NetWare network as easily as you can use other native networking capabilities of Windows NT.
Novell is also developing a NetWare-compatible redirector for Windows NT, called the NetWare Client for Windows NT. This redirector is now in beta, and is widely anticipated by users and developers. (Novell has not announced a completion date for this product.) When available, NetWare Client will allow a Windows NT–based computer to access file and print resources on NetWare servers.
Therefore, there will be at least two solutions available for providing Windows NT–based machines client capabilities to NetWare servers (and possibly more, if other third-party solutions become available). The open architecture of Windows NT also makes it easy for third parties to develop redirectors. These clients will doubtless differ in features, performance, price, availability, and so forth.
Because NetWare connectivity is so important to many of our customers, we are increasingly building solid NetWare connectivity right into Microsoft operating systems (for example, NWCS for Windows NT, and enhanced built-in NetWare connectivity in Windows for Workgroups 3.11). In addition, we will provide timely support for NWCS on all Windows NT supported platforms (currently X86, MIPS®, and Alpha AXP™), support that is important to our customers.
Figure 2. Windows NT–based computers as NetWare clients or application servers
The Windows NT architecture includes an open interface incorporating two key components—the multiple provider router (MPR) and the multiple UNC provider (MUP)—that together enable consistent access to third-party network file systems. The MPR supports browsing and connection to other (non-Microsoft Windows) networks. The MUP makes all file systems, regardless of type and physical location, accessible through the same set of file-system APIs (using UNC names).
Applications make file-system requests through the Win32® API in Windows NT. The capabilities of the MPR and MUP ensure that requests are performed on the proper file system: Local file requests are sent to the local disk, remote requests to Windows-based servers are sent to the appropriate server by the Windows redirector, and requests to NetWare servers are sent to the appropriate server by the NetWare Client for Windows NT.
For example, File Manager allows users to browse and connect to any NetWare or Windows-based server on the net. Because built-in networking in Windows NT is independent of the underlying net, the same user interface and tools work with all networks that run on Windows NT.
The Microsoft NWCS is a fully native implementation of a 32-bit Windows redirector, utilizing all the built-in networking capabilities (for example, NDIS and TDI interfaces) of Windows NT. This provides a wide choice of compatible network cards and the ability to easily run multiple protocols and services over the same network card simultaneously. It also provides features such as MP-safety and the best portability among different Windows NT–supported platforms (currently X86, MIPS, and Alpha AXP).
The NetWare Client only partially reflects the Windows NT network architecture. For example, it relies on ODI device drivers rather than the NDIS standard used by most Windows NT–based network software. This will adversely affect the number of network cards that the NetWare client can support, and may affect portability to SMP or non-X86 Windows NT–based platforms.
Windows for Workgroups 3.11 is an operating system that adds integrated networking functionality to the familiar Microsoft Windows operating system, simplifying the process of connecting individual personal computers, servers, and printers. Windows for Workgroups version 3.11 provides significantly enhanced network integration with Novell NetWare by interoperating better with Novell NetWare configurations. The Novell NetWare–related improvements in Windows for Workgroups 3.11 focus on allowing Windows for Workgroups to work better with Novell NetWare drivers. These enhancements include:
NWNBLink is a NetBIOS version 3 provider that runs in conjunction with NWLink and uses the Novell NetBIOS frame format to provide full compatibility with Novell's NetBIOS version 1 implementation. It provides support using NetBIOS for interoperating with other Windows for Workgroups and Windows NT–based machines, and with machines running Novell's NetBIOS driver. The use of NWNBLink provides application connectivity to NetBIOS-based environments such as Lotus Notes, without loading the Novell NETBIOS.EXE driver, saving as much as 40K of conventional memory.
The combination of NWLink and NWNBLink allows Windows for Workgroups–based workstations to support file and printer peer networking over the IPX/SPX-compatible transport to Windows NT and Windows NT Advanced Server.
NWLink is the ideal transport protocol to use where Windows for Workgroups–based workstations need to communicate with other computers on an IPX backbone. Note that in order for a Windows for Workgroups–based workstation to access files and printers residing on a NetWare server, the NetWare redirector (either 3.x or 4.x) and real-mode IPX transport protocol are still required.
Many organizations today are seeking solutions for downsizing or reengineering existing applications that run on minicomputers or mainframes. Many of these are NetWare networks. NetWare servers are designed to function primarily as file and print servers, and therefore do not support business-critical applications well. NetWare servers do not feature preemptive multitasking or protected virtual memory, essential features for client-server applications. On the other hand, Windows NT Advanced Server makes an ideal platform for demanding applications because of its scalability, fault tolerance, 32-bit architecture, and threaded, preemptive multitasking with full memory protection.
Administrators can take advantage of the advanced features of Windows NT Advanced Server on an existing NetWare network without interfering with client systems' access to file and printer resources on NetWare servers. For example, an administrator can add Windows NT Advanced Server computers running SQL Server to the network (so client workstations can take advantage of a distributed high-performance relational database system) and still be able to use files and printers shared by their usual NetWare servers. This solution requires no additional hardware or software to provide the necessary connectivity.
MS-DOS, Windows (all types), and OS/2–based clients use a variety of mechanisms to communicate with back-end server applications running on Windows NT Advanced Server. These mechanisms include Sockets, Remote Procedure Calls (RPC), and Novell NetBIOS. Windows Sockets, Microsoft's enhanced implementation of the Berkeley-compatible sockets mechanism, is particularly powerful, since Sockets are a common tool for communicating with NetWare NLMs. Customers who have implemented client-server solutions using NLMs can port them to Windows NT Advanced Server, while retaining compatibility on their clients. All these mechanisms run over NWLink, Windows NT Advanced Server's built-in IPX/SPX-compatible protocol stack. Because NWLink is NDIS-compliant, the Windows NT computer can simultaneously run other protocol stacks (such as TCP/IP) over the same network adapter cards, allowing them to simultaneously communicate with non-NetWare computers.
Before adding computers running Windows NT (or other non-NetWare operating systems) to a NetWare network, an administrator should anticipate some potential areas of concern.
Administrators should be aware that Windows NT–based clients on NetWare do not run NetWare logon scripts. However, the ability of Windows NT to run its own logon scripts and maintain persistent connections provides much the same functionality as NetWare logon scripts in many instances. Windows NT Advanced Server also supports the notion of user profiles, which allows customization of user desktops at logon time.
Another area of difficulty is backing up Windows NT–based clients on NetWare. Novell servers cannot provide tape backup services for Windows NT–based computers. However, a Windows NT–based computer equipped with a supported tape drive can back up other Windows NT–based computers, as well as NetWare servers and computers running Windows networking software.
Finally, Windows NT can act as a client for NetWare 2.2-4.x servers (4.x supported with bindery emulation turned on). Currently, NWCS does not support NetWare 4.x-specific directory services and authentication.
The following sections discuss in greater detail how Windows for Workgroups, Windows NT, and Windows NT Advanced Server can be integrated into environments with NetWare servers.
This section discusses the three major software components for integrating Windows NT into Novell NetWare environments—NWLink protocol, Microsoft's NetWare Workstation Compatible Service (NWCS), and Novell's NetWare Client for Windows NT.
NWLink is an IPX/SPX-compatible transport protocol for Windows NT. It can be used to establish connections between Windows NT–based computers and MS-DOS–based, OS/2–based, Windows-based, or other Windows NT–based computers via a variety of communications mechanisms. Probably the most widely supported and versatile is Windows Sockets, since sockets are a common tool for communicating with NetWare NLMs. Customers who may have implemented client-server solutions using NLMs can port them to Windows NT Advanced Server, while retaining much compatibility on their clients. Other mechanisms, including RPC and Novell NetBIOS, are also possible.
NWLink is simply a transport protocol. By itself, it does not allow a Windows NT–based computer to access files or printers on a Novell NetWare server or to act as a server to a NetWare client. To access files or printers on a NetWare server, you need to use a redirector: either Microsoft's NWCS or Novell's NetWare Client for Windows NT.
NWLink is useful if you have NetWare client applications that use sockets or NetBIOS over the IPX/SPX protocol. NWLink can also serve as the protocol used by the default redirector and server for Windows NT and Windows NT Advanced Server, which use Server Message Blocks (SMBs) to communicate with Microsoft network clients. Customers can, if they choose, perform all their networking using IPX/SPX, including all traffic among clients, NetWare servers, and Windows NT Advanced Servers supporting applications such as Microsoft SNA Server or Microsoft SQL Server for Windows NT.
Because NWLink uses Streams, which in turn uses NDIS 3.0, the NWLink protocol can be run on any network adapter card that uses an NDIS-compatible driver.
Figure 3. NWLink, NWNBLink, and Streams
User-mode applications can use RPC, NetBIOS APIs, or Windows Sockets APIs to access the network via NWLink or other IPX/SPX protocol drivers. Both NetBIOS and Windows Sockets are supported in the Windows 32-bit, Windows 16-bit, and MS-DOS environments. Programs that run in the OS/2 environment can use NetBIOS and Novell's IPX/SPX support for OS/2, but not Windows Sockets APIs. All subsystems and VDMs can use logical drives that are established by the redirector via NWLink.
Figure 4. Communication via NetBIOS, Sockets, and RPC
The NetBIOS over IPX is compatible with the NetBIOS support provided by Novell. In addition, NWNBLink includes certain enhancements to improve performance when using NetBIOS.
These performance enhancements include acknowledgment of previous frames included in response frames (called PiggyBackAck). They also include use of a "sliding window" acknowledgment mechanism. These performance enhancements are used only when communicating with NWNBLink computers.
When a Windows NT–based computer communicates with a computer using NetWare NetBIOS, the Windows NT–based computer must also use Novell NetBIOS. The NetBIOS provided by Novell acknowledges each frame received. This amount of precaution is unnecessary overhead where a highly reliable medium such as a local area network (LAN) is used, or where higher-level protocols already contain end-to-end acknowledgments.
NWLink can be run on Ethernet, Token Ring, FDDI, and ArcNet topologies. Each topology requires a different frame formats. Ethernet supports Ethernet_II, raw 802.3, 802.2, or SNAP frame formats. Token Ring and FDDI supports 802.2 and SNAP. ArcNet supports raw ArcNet framing only.
It is important to make sure that the NWLink on the Windows NT–based computers is using the same framing used by the client computer. On Ethernet networks, the standard frame format for NetWare 2.2 and NetWare 3.1 is 802.3. Starting with NetWare 4.0, the default frame format is 802.2. You can determine the frame protocol on your Windows NT–based computer by viewing the configuration settings for NWLink through Network Control Panel.
The NetWare Workstation Compatible Service (NWCS) is Microsoft's solution for allowing Microsoft Windows NT–based workstations to access files, directories, and printers on Novell NetWare servers. Large-scale beta testing of NWCS began in the fourth quarter of 1993, and its current development schedule calls for completion during 1994. Early experience with NWCS has been excellent—it has been very well received by customers who have been waiting for this solution.
Because NWCS uses the IPX protocol, the NetWare Link (NWLink) transport must be installed before you install NWCS. After NWCS is installed, you can choose to configure the service, or you can start accessing the files, directories and print queues that reside on NetWare 2.x, 3.x and 4.0 (with bindery emulation) file servers.
NWCS is a fully native implementation of a NetWare redirector for Windows NT. It is implemented as native 32-bit Windows NT code, and includes both a service and a device driver. NWCS takes full advantage of the advanced communications architecture of Windows NT. Because it was implemented within the framework of Windows NT (as a native Windows NT networking application), it provides a well-integrated, seamless, and natural extension of the Windows NT native networking environment.
Figure 5. NetWare compatible service for Windows NT architecture
Installing NWCS is simple and straightforward—simply use the "Add Software" option in the Network applet of Control Panel. (Users must be sure that they install any required updates to their release of Windows NT when installing NWCS.) When NWCS is installed, an icon labeled NWC is created in Control Panel. This application can be used to select defaults for NetWare server and for printing services via NetWare print queues. Once NWCS has been installed, authorized access to files, directories and printers on the NetWare network can begin.
Before users can access files, applications, or print queues on a NetWare server, they must have authorization to do so from the administrator. Each user's username and password on the NetWare system constitute that user's NetWare credentials.
The NetWare server authenticates the credentials supplied by each user when prompted, or when the user logs on to Windows NT, by checking that the credentials match those for the user's account on the NetWare server. The user is prompted to supply a new password only if that user's credentials on the NetWare server are not the same as his or her credentials in Windows NT.
It is best to keep your username and password on NetWare servers the same as those you use when logging on to Windows NT. This allows you to use NetWare servers without having to supply another username and password. It also makes it easier for network administrators to coordinate user accounts.
NWCS uses the NetWare notion of preferred server. This is the NetWare server that is queried for information about available network resources. The preferred server also authenticates users' credentials. The username and password that the preferred server authenticates are the default credentials. NWCS allows you to select or change your preferred server at any time.
NWCS allows users to access resources on NetWare servers, including directories, files, and printers. NetWare server volumes, directories, and print queues are represented by their universal naming convention (UNC) names. (UNC names begin with two backslashes (\\) followed by the remote server name, and then the names of the volume or directory points on the server separated by single backslashes.) NetWare syntax is also supported.
Users can connect to directories on NetWare file servers using File Manager or the net command at the command prompt. Users can print to NetWare print queues by connecting to the print queue in Print Manager. Once a user has connected to a print queue, he or she can also print to it using the net command. Users can also display NetWare servers and volumes using the net command.
Another command that is supported in this version of NWCS is setpass, which can be used to change your password on NetWare servers. However, setpass is the only NetWare utility that is supported in the current release. Administrators should review the NWCS release notes regarding support for specific 16-bit utilities or NetWare APIs. NetWare-aware applications and Novell login scripts are not supported.
With File Manager, users can browse and connect to resources on both Microsoft and NetWare networks. Once connected to a NetWare drive, users can simply drag and drop directories and files between Windows NT, Windows for Workgroups, and LAN Manager servers and NetWare servers.
On NetWare networks, the servers, volumes and directories are organized in a tree structure. Both volumes and directories are represented by the shared directory icon. Users can simply choose an item to expand the list. For example, users simply choose a directory to display its subdirectories.
When a user selects the name of a NetWare volume, the NetWare server authenticates the user before allowing him or her to see directories. If the server cannot authenticate the user, Windows NT displays the Enter Network Credential dialog box so that the user can provide a username and a password for the server.
Users can specify the order in which networks are searched for disk and print resources when they are using File Manager or Print Manager. By default, the NetWare network is first in the search order, which speeds up the search for NetWare resources.
To send data to a NetWare print queue, the user must first use Print Manager to connect to the print queue. Then, at the command prompt, the net use command is used to redirect output to the queue. For example, to redirect output from LPT1: to the print queue called MEMOS on the server NETWARE311, type:
net use lpt1 \\netware311\memos
This is equivalent to the NetWare capture command:
CAPTURE Q=MEMOS S=NETWARE311 L=1.
After redirecting output using the net use command, using the copy command allows users to send preformatted output files to LPT1: or directly to the print queue.
To print to a NetWare print queue, users connect to it using Print Manager. If the NetWare network is first in the network search order for print providers, the list of servers on the NetWare network is displayed automatically in the Shared Printers box. After connecting, users can print to the NetWare print queue just as they would to a Windows NT–based printer.
The printing options that are supported for NetWare print queues include settings for form feeds, print notification, and banner pages. Printing options are set for the user who is logged on to Windows NT. Settings affect all NetWare print queues used from a given Windows NT–based computer. The options are equivalent to those available through the capture utility on NetWare workstations running MS-DOS.
Both Windows NT and NetWare support predefining actions and system behavior to take place when users log on.
NetWare has three different levels of login scripts:
Login script execution follows the following algorithm:
When a server is first installed, NetWare executes a default login script that maps the appropriate directories so that the administrator can access the NetWare utilities.
Based on feedback from customers of NWCS, the most typical scenario is for a network administrator to set up a system login script that is used for creating consistent connections, as well as setting up printing redirection. An example of a typical login script is:
if member of "DALY" then begin
attach T0500/HI10186
map root N:=T0500/sys:public\apps\modasst
end
if member of "ANNUITY" then begin
#capture q=annuity ff nb nt ti=10 lpt1
#capture q=annuity ff nb nt ti=10 lpt2
#capture q=ann_paintjet ff nb nt ti=50 lpt3
end
fdisplay z:\public\net\system.msg
pause
This script shows the most common use of login scripts: to connect to shares based on user or group affiliation, set print queues for the client, and display messages.
With Windows NT, you can set each user to have a login script that is run when the user logs on. This is typically a .BAT batch file. For example, you may wish to reestablish connections (mappings) to resources with the NET USE command. Login scripts are set from the User Manager. You cannot set a login script for a group, but the User Manager tool allows you to select all users in a group and then you can set them all to have the same login script. Use the 'Select Users' menu item to select the users in a group; then to set the actual script, go to User Properties Dialog, Profiles Button. Login scripts can be defined by individual users or by administrators.
With Windows NT Advanced Server, each user can also have a user-modifiable or a read-only profile. The profile represents the "state" of the desktop for the user, including groups, what connections to restore, and so on. This is independent of any connections made by logon scripts from Windows NT. To create the profile, use UPEDIT.EXE and then save it as a .USR file for user-modifiable profile, or .MAN file for a mandatory read-only profile. Then from User Manager, set the profiles for the users. The same group restriction as Login Scripts apply. You cannot set it for a group, but the User Manager tool allows you to set for all users in a group. If you do NOT specify a user to use a named profile, that user will have his/her own profile on any machine he or she logs on to. In other words, the user will still have persistent state, but it will be one per machine. This is the default scenario. Note that user profile requires the use of Windows NT Advanced Server.
As indicated above, the user's profile includes what network connections to reestablish. To make a connection permanent, check the 'Restore at Logon' checkbox when making the connection from File Manager. If using the command line, make sure the PERSISTENT switch is on:
NET USE /PERSISTENT:YES
User-modifiable profiles give users the most flexibility, while logon scripts and mandatory profiles give the supervisor the most control.
Both users and administrators can use Performance Monitor, located in the Administrative Tools program group, to monitor the NWLink IPX, NWLink SPX, and NWLink NetBIOS objects. Each of these objects can return information on packets sent and received. Which one you use depends on the application that is using NWLink. For example, if you are interested in data relevant to Windows NT–based networking, use the NWLink NetBIOS object. NWCS uses NWLink IPX. SQL Server uses NWLink SPX.
Novell's NetWare Client for Windows NT is another tool providing access to NetWare servers. As of October 1993, NetWare Client for Windows NT is approaching beta-level. Although it is a 32-bit Windows NT–based application, Novell has chosen not to use native Windows NT capabilities such as its built-in IPX/SPX protocol (NWLink) or its NDIS layer. (NDIS enables communications capabilities to work well with other Windows NT–based networking software, and provides a very wide range of device driver support under Windows NT.)
Figure 6. NetWare Client for Windows NT architecture
The NetWare Client for Windows NT includes a printer provider in user-mode memory (which allows the Windows NT printer system to use a NetWare server's printer), as well as the NetWare Redirector, the NetWare Provider, and the ODINSUP converter device driver.
The NetWare Redirector, along with the NetWare Provider, supports file and print services from NetWare Client for Windows NT, NetWare 2.x, 3.x, and 4.x servers. The Redirector can support an unlimited number of connections. The auto-reconnect feature is also supported so that users don't need to remember previously established connections.
Like the default Windows NT Redirector, the NetWare Redirector is implemented as a file system driver. This allows the NetWare Redirector to access to the other file system drivers such as FAT and NTFS. As of this writing, it is not clear to what extent Windows NT file system services, such as cache management, will be effectively utilized by the NetWare Client. Readers interested in using the NetWare Client should verify with Novell the feature set and functionality currently available.
The Redirector communicates with transport protocols through the Transport Device Interface (TDI). The NetWare Client for Windows NT supports both IPX and SPX II protocols. Unlike the default protocols provided with Windows NT (including TCP/IP, NBF, and DLC), the IPX and SPX protocols use the Open Device Interface (ODI) in place of NDIS. Therefore, not all the Windows NT–supported network adapter cards will be supported by the NetWare client.
NetWare Provider resides in user mode and provides an interface for user interaction with the network. This component creates extensions in File Manager, allowing users to manage connections and mappings made with NetWare server. NetWare Provider also allows users to browse NetWare resources on the network.
NetWare Provider creates extensions in Control Panel, allowing users to collect information about connections and to manage NetWare Client for Windows NT servers. NetWare Provider works with the MPR to accept and run WNet API calls from Win32 and Windows–based 16-bit applications.
NetWare Provider communicates with the Win32 subsystem via the Multiple Provider Router (MPR). Programmatic interfaces for the MS-DOS, Windows 16-bit, and OS/2 environments are also provided.
ODINSUP Converter
To allow NDIS-based protocol stacks access to the network adapter card via the ODI MAC-level driver, the NetWare Client for Windows NT provides a converter driver called ODINSUP. With this device driver, users can simultaneously run NetWare Client for Windows NT and TCP/IP, NBF or DLC on the same network adapter card.
Figure 7. ODI and ODINSUP converter
As mentioned previously, the IPX and SPX protocols provided with the NetWare Redirector use ODI to communicate to the network adapter card. Since only one device driver can be bound to a network adapter card at a time, this presents a problem for users who want to use both the NetWare Redirector with IPX/SPX to communicate with NetWare servers and the default TCP/IP protocol stack to communicate with UNIX® hosts. To allow this type of configuration, a converter driver, ODINSUP, is provided with the NetWare Redirector. This driver translates from NDIS to ODI and vice versa. This allows NDIS protocol drivers to be bound to network adapter cards via ODI-compliant MAC-level device drivers.
Windows NT can be configured with the ability to reshare redirected drives that point to networks that are not Windows-based. In other words, logical drives on a Windows NT–based machine that are connected to remote resources such as NetWare servers can be reshared via the built-in server capabilities in Windows NT. This capability allows Windows NT to act as a nondedicated gateway to foreign file systems for any SMB-based client (including Windows for Workgroups, Windows NT, and MS-DOS–based LAN Manager clients).
Windows NT can serve as a gateway between SMB-based networks and NCP-based networks. In the example below, both Windows (LAN Manager) clients as well as Windows for Workgroups–based clients can easily access remote NetWare-based file and print services via the Windows NT–based gateway machine.
Figure 8. Windows NT as an NCP gateway
To enable resharing of redirected drives, use regedt32.exe and navigate down the Registry tree to the key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters
At this location, add the EnableSharedNetDrives variable (of type REG_DWORD) and set its value to 1. Then reboot the machine (or stop and restart the Server service). This will enable resharing of redirected drives.
This scenario provides a number of capabilities and benefits to customers:
In this section, we have concentrated on the use of Windows NT as a client to NetWare servers for file and print services. Several third parties are working on add-ons for Windows NT that will provide NCP server capabilities as well, enabling Windows NT to act as a file and print server for existing NetWare clients. This will enable Windows NT to provide a true superset of NetWare functionality, combining superior application server capabilities as well as NetWare-compatible file and print services. As of this writing, Beame and Whiteside (Toronto, Canada) is about to enter beta testing for its NCP server.
This section has shown how customers can deploy Windows NT on their advanced desktops, while retaining access to existing data or applications that may reside on in-place NetWare servers. It has also discussed how Windows NT–based clients can act as gateways from Windows SMB-based networking to NetWare NCP-based networking.
Windows for Workgroups 3.11 features improved operability and compatibility with Novell NetWare environments. This section discusses the improved support and describes special information to assist in configuring and integrating Windows for Workgroups with Novell NetWare.
In an existing NetWare environment where Windows 3.1 is being used along with the NetWare client software, the incorporation of Windows NT and Windows NT Advanced Server requires that the Windows-based workstation run Microsoft network client software to access resources on a computer running Windows NT. Windows for Workgroups 3.11 is a compelling platform to use in this environment as it requires only approximately 5 KB of conventional memory to support concurrent connectivity to both NetWare and Windows NT Advanced Server servers over the memory requirements used by Windows 3.1 and the NetWare client software. The small memory footprint due to the 32-bit networking components allows MS-DOS–based machines to continue to access their NetWare resources, and also to leverage the computing power and server-platform for client-server applications that Windows NT Advanced Server offers.
Windows for Workgroups 3.11 greatly enhances the interoperability with Novell NetWare over the support provided by Windows for Workgroups 3.1. The additional support for integrating with NetWare includes the following.
Improved NetWare network adapter card driver support
Improved network redirector support
Improved networking support and functionality
Windows for Workgroups 3.11 includes NWLink, a 32-bit IPX/SPX-compatible protocol. NWLink is an NDIS 3.0-compliant protocol allowing Windows for Workgroups 3.11–based workstations to communicate over a routable IPX-compatible protocol.
Although Windows for Workgroups 3.11 can run natively on a real-mode IPX protocol, the NWLink protocol provides the following additional benefits:
On a computer configured with the NetWare client software, the NWLink protocol processes all
non-NetWare Core Protocol (NCP) IPX traffic. The Windows for Workgroups components do not process NCP traffic that is used by the NetWare redirector to communicate with a NetWare server for file and printer services. In order to support file and printer services from NetWare servers, the NetWare redirector and real-mode IPX protocol must be loaded.
The example below illustrates the flow of information from applications running under the Windows for Workgroups environment.
Figure 9. Flow of IPX information when the NWLink protocol is used along with the NetWare redirector and real-mode IPX protocol
A computer can install both protected-mode and real-mode IPX drivers on the same adapter running ODI or NDIS.
Depending on the functionality you want, you should choose the appropriate 32-bit protected-mode implementation of the IPX/SPX Compatible Transport (NWLink) with or without NetBIOS services. The following table provides a matrix showing when the "IPX/SPX Compatible Transport" and when the "IPX/SPX Compatible Transport with NetBIOS" should be installed.
Functionality Wanted |
IPX/SPX Compatible Transport (NWLink) | IPX/SPX Compatible Transport with NetBIOS (NWLink/NWNBLink) |
| NetBIOS support | X | |
| Connectivity to Windows NT or Windows NT Advanced Server | X | |
| Connectivity with Windows for Workgroups | X | X (if Network DDE is wanted) |
| Network DDE over IPX | X |
Microsoft's IPX/SPX protocol, NWLink, conforms to the IPX specification which dictates for it to provide routable datagram packets. The routable feature of IPX and its implementation across the majority of network environments are the reasons Microsoft implemented an NDIS 3.0 model of this protocol. NWLink can use Novell NetWare servers configured as routers (and other IPX routers) to transfer its packets across LANs to access the resources of other Windows for Workgroups 3.11 computers.
Since NWLink is protected-mode, Novell NetWare's shell, NETX.EXE, will not load unless a real-mode IPX protocol driver is also installed. NETX.EXE is required to access Novell NetWare's file server resources.
NetBIOS is a high-level interface used by applications to communicate with other NetBIOS-compliant protocols. The NetBIOS interface is responsible for establishing logical names on the network, establishing connections (called sessions) between two logical names on the network, and supporting reliable data transfer between computers that have established a session.
Novell provides a TSR NetBIOS driver called NETBIOS.EXE which is a Level 1 NetBIOS provider and consumes approximately 40K of conventional memory. Novell's NetBIOS driver acknowledges each frame received, thus increasing the amount of traffic generated when NetBIOS is used.
Windows for Workgroups 3.11 provides a 32-bit, protected-mode, NetBIOS driver that provides NetBIOS services on top of IPX, called NWNBLink. NWNBLink is compatible with Novell's NetBIOS support driver and provides enhancements to improve performance when using NetBIOS in conjunction with IPX. These performance enhancements include acknowledgment of previous frames in response frames (called PiggyBackAck). They also include a "sliding window" acknowledgment mechanism. These performance enhancements for NetBIOS are used only when communicating with other computers using the NWNBLink NetBIOS driver, including other computers running Windows for Workgroups 3.11 and Windows NT.
When Windows for Workgroups supports peer services on top of IPX, NetBIOS is necessary to support Network DDE services. Network DDE uses NetBIOS to communicate between other workstations.
NWNBLink is required for Windows for Workgroups 3.11-based computers to communicate with Windows NT–based computers that are using the NWLink protocol and NWNBLink support driver. Users of Windows for Workgroups 3.11 must install for IPX/SPX Compatible Transport with NetBIOS. The IPX/SPX protocol option in Windows NT automatically installs the NetBIOS component.
To add the NWNBLink driver to your system, choose the IPX/SPX Compatible Transport with NetBIOS protocol from the Add Network Protocol dialog box from Network setup. If you do not need NetBIOS services over IPX, choose the IPX/SPX Compatible Transport as the protocol to use.
By default, the NWNBLink driver is installed in a monolithic IPX configuration when the user selects the IPX Support Driver (Monolithic) with NetBIOS transport from the Add Network Adapter dialog box.
It is important to understand when it will be necessary to add the NetBIOS layer, NWNBLink, when installing IPX/SPX (or NWLink). The two most common requirements are:
NWNBLink is not necessary for Windows for Workgroups 3.11–based computers to communicate with other Windows for Workgroups 3.11–based computers. The Windows for Workgroups 3.11 redirector and server have additional code that allows them to communicate with the IPX protocol without using NetBIOS.
To support Novell NetWare integration with Windows for Workgroups, the workstation on which you are installing Windows for Workgroups should be properly configured to connect to a NetWare server. This requires that the workstation is configured with either the monolithic IPX driver (IPX.COM), or an ODI driver in addition to either a NetWare 3.x or 4.x workstation shell to access file or print services from a NetWare server. Novell recommends that NetWare users use ODI-based drivers rather than the monolithic IPX driver.
If the workstation is preconfigured with the Novell drivers, the Windows for Workgroups 3.11 setup program will detect these drivers and will automatically configure Novell NetWare support in addition to installing the Windows for Workgroups 3.11 networking components.
If the workstation is not correctly configured with the necessary Novell drivers, this must be done as described in the NetWare documentation before installing Windows for Workgroups 3.11.
Note that Windows for Workgroups 3.11 does not support NetWare interoperability using NDIS NIC drivers, nor do any NetWare components ship with Windows for Workgroups 3.11. Information on obtaining the necessary Novell files (or updates for the Novell files) is discussed later in this section.
In addition to the base Novell NetWare client software, which consists of the NetWare redirector and IPX protocol, there are some additional NetWare support files necessary for the Novell components to work properly in the Windows environment. These files are written and provided by Novell with your NetWare system:
| File(s) | Description |
| netware.drv, netware.hlp | Windows network driver and associated help file to provide access to network redirector functionality from Windows File Manager. |
| nwpopup.exe | NetWare messaging utility. Receives messages or alerts from a NetWare server. |
| vnetware.386 | Virtual device driver providing virtualization services for NetWare redirector for Windows environment and across MS-DOS virtual machines. |
| vipx.386 | Virtual device driver providing virtualization services for NetWare IPX protocol for Windows environment and across MS-DOS virtual machines. |
When Windows for Workgroups 3.11 is configured to support Novell NetWare in addition to Windows for Workgroups network functionality, Setup checks for these files in the Windows directory. If the files are not found, Setup will prompt the user for a disk or network drive location for these files.
If your workstation is not configured with the necessary NetWare client software, or if you don't have the Windows support files that Windows for Workgroups Setup requires to properly configure your workstation, several sources are available from which they may be obtained.
It is highly recommended that you use the latest version of Novell driver files that are available. As of October 1, 1993, Novell was offering the following files on the Novell Files forum (NOVFILES) on CompuServe®:
If NetWare client software is loaded and running at the time Windows for Workgroups is installed, Setup will detect this and automatically select Novell NetWare as an additional network.
If the NetWare client software is not running at the time Windows for Workgroups is installed, it is necessary to configure Windows for Workgroups to work in conjunction with the NetWare client software. To do this, choose the appropriate network option to match the version of the Novell NetWare Workstation Shell you are using. Windows for Workgroups supports Workstation Shells version 3.x, and version 4.0 and above.
Figure 10. Windows for Workgroups 3.11 Networks setup dialog box used to configure additional network support.
Once Windows for Workgroups Setup is run and "Novell NetWare (Workstation Shell 3.x)" or "Novell NetWare (Workstation Shell 4.0 and above)" is selected as an additional network (in conjunction with the Microsoft Windows-based network), the network detection code will attempt to determine the NetWare driver model you are using. If it cannot autodetect in your particular configuration, then choose the appropriate selection manually ("IPXODI.COM and LSL.COM (recommended)" or "IPX.COM"). The proper selection is important for installation of the necessary support files for each driver model.
The Open Datalink Interface (ODI) specification was defined by Novell Corporation and Apple Computer Corporation to simplify driver development and to provide support for multiple protocols on a single network adapter. Similar to NDIS in many respects, ODI provides a protocol, a consistent API to communicate with a network adapter card driver, and supports the use of multiple protocols on a network adapter card driver. Novell recommends using ODI-based client software rather than dedicated IPX drivers. To provide the most flexibility in Windows for Workgroups 3.11 for other protocol support along with NetWare integration, ODI drivers should be used.
Figure 11. ODI driver model
ODI consists of three main components:
It is important that the real-mode ODI IPX network be configured and working properly before installing Windows for Workgroups 3.11. Before installing Windows for Workgroups 3.11, test to confirm that there are no errors when loading LSL.COM, IPXODI.COM, MLID, and NETX.EXE, or when accessing resources on NetWare servers.
If the NetWare ODI drivers are installed and running on the computer when Windows for Workgroups 3.11 is installed, Setup detects that ODI drivers are being used and will automatically identify the network adapter card and configure Windows for Workgroups to run on top of the ODI drivers.
If Windows for Workgroups is unable to identify the ODI MLID being used, it may be necessary to manually configure the network adapter. In this case, the appropriate IPXODI Support Driver should be chosen to match the type of network adapter card you are using. For example, if you use Ethernet, choose the "IPXODI Support Driver (Ethernet)" as your network adapter.
When Windows for Workgroups 3.11 is installed over ODI drivers, the IPX/SPX compatible transport with NetBIOS is installed by default from the Protocol Setup dialog box. This provides the 32-bit implementation of the IPX/SPX compatible transport and loads the NetBIOS service provider support.
The driver configuration of Windows for Workgroups 3.11 installed over ODI:
Figure 12. Driver configuration in the default ODI IPX configuration
The driver files used are:
| Novell Drivers | Description |
| NE2000.COM—MLID driver | ODI MLID driver from NIC vendor or Novell |
| LSL.COM | Link Support Layer (LSL) driver from Novell |
| IPXODI.COM | Real-mode IPX protocol for use with Novell's redirector |
| NETX.EXE | NetWare redirector from Novell |
| VNETWARE.386 | NetWare redirector virtual device driver from Novell |
| Microsoft Drivers | Description |
| ODIHLP.EXE | Real-mode stub for ODI support layer |
| MSODISUP.386 | NDIS to ODI Mapping Support layer |
| NDIS.386 | NDIS Support layer |
| NWLink.386 | 32-bit IPX/SPX compatible protocol virtual device driver |
| NWNBLink.386 | NetBIOS services provider virtual device driver for NWLink |
| *VNETBIOS | Virtual device driver for virtualizing NetBIOS services |
| VREDIR.386 | Windows for Workgroups 3.11 protected-mode redirector |
| VSERVER.386 | Windows for Workgroups 3.11 protected-mode server |
When Windows for Workgroups is installed over ODI, the NetBEUI NDIS 3.0 and IPX/SPX Compatible Transport with NetBIOS protocols are installed by default.
An NDIS 3.0 protocol driver (such as NWLINK.386 or NETBEUI.386) can bind to an ODI driver with the help of two support files:
With LSL 2.01 or later, multiple default stacks, called default chained stacks, are supported. ODIHLP.EXE will bind as a default chained stack on current LSL versions. If another ODI-compliant protocol loads and is registered as a default stack, then ODIHLP.EXE loads after that protocol.
Make sure that you have the latest NetWare drivers and files, including the latest version of the ODI MLID driver for your network adapter card.
The monolithic/dedicated implementation of the IPX protocol, IPX.COM, is used by many of the installed base of NetWare workstations. IPX.COM is called monolithic because it contains the NetWare IPX/SPX protocol stack and the network adapter card driver for communicating with the network adapter in one code module or driver file.
When Windows for Workgroups is configured to run on top of a monolithic/dedicated IPX driver, NetBIOS is used to support Windows for Workgroups peer services over real mode IPX. Support for peer sharing over IPX requires NetBIOS when using monolithic IPX drivers.
Figure 13. Monolithic IPX model
IPX.COM is generated from the IPX.OBJ file and a particular network adapter card driver file (net_card.OBJ) using the NetWare SHGEN or WSGEN programs. IPX.COM must be configured for each individual workstation based on the individual network adapter card and its hardware configuration (IRQ, I/O address, RAM address in the upper memory area and DMA channel).
It is important that the real-mode monolithic IPX network be configured and working properly before installing Windows for Workgroups 3.11. Confirm first that there are no errors when loading IPX.COM and NETX.EXE or when accessing resources on NetWare servers from MS-DOS.
The driver configuration of Windows for Workgroups running over monolithic IPX:
Figure 14. Driver configuration in the default monolithic IPX configuration
The required driver files are:
| Novell Driver | Description |
| IPX.COM | Monolithic IPX driver from Novell |
| NETX.EXE | NetWare redirector from Novell |
| VNETWARE.386 | NetWare redirector virtual device driver from Novell |
| VIPX.386 | NetWare IPX virtual device driver from Novell |
| Microsoft Drivers | Description |
| NWSUP.386 | Supports the Windows for Workgroups network redirector and network server on top of monolithic IPX |
| NWNBLink.386 | NetBIOS services provider virtual device driver for NetBIOS on top of IPX protocol from Windows for Workgroups 3.11 |
| *VNETBIOS | Virtual device driver for virtualizing NetBIOS services in Windows and across MS-DOS virtual machines |
| VREDIR.386 | Windows for Workgroups 3.11 protected-mode redirector |
| VSERVER.386 | Windows for Workgroups 3.11 protected-mode server |
On each NetWare client, two ASCII configuration files—SHELL.CFG or NET.CFG—are used for the setup and configuration of a workstation's network environment. These are ASCII files specifying custom workstation parameters for NETX, IPX, NetBIOS or the general NetWare environment.
NetWare began using SHELL.CFG as the configuration file name with monolithic IPX, but now NET.CFG is the preferred file name to use with ODI. If both SHELL.CFG and NET.CFG exist, both are processed (first SHELL.CFG, then NET.CFG). If these files do not exist, default settings are used.
Since an ODI workstation can have multiple MLIDs and multiple protocols loaded and bound, ODI uses the NET.CFG configuration file to identify the network adapter card and protocol configuration and binding information. NET.CFG for ODI is similar to the PROTOCOL.INI file used for NDIS.
Monolithic IPX does not require a settings file because there is only one protocol and one NIC driver and they are bound together in a specific way. IPX.COM contains the network adapter card configuration information, including the interrupt and base memory address used by the card.
Refer to your Novell NetWare documentation for more information regarding processing order and specific settings in the .CFG and MLID files.
Windows for Workgroups 3.11 provides support for mapping NDIS 3.0 protocols to run on top of ODI; however, support for NDIS 2.0 protocols on top of ODI is not directly provided by Windows for Workgroups. If you want to use NDIS 2.0 in a NetWare environment where ODI drivers are being used, Novell offers the ODINSUP driver to map NDIS 2.0 protocols to ODI network adapter card drivers (MLIDs). The Novell ODINSUP driver allows NDIS 2.0 protocol stacks to run over the ODI LSL and talk to an ODI MLID. For example, the ODINSUP driver can be used to allow Microsoft NDIS-based protocols on top of an ODI configuration.
Figure 15. ODINSUP configuration supporting NDIS 2.0 protocols on ODI drivers
For more information about ODINSUP, see the ODINSUP.DOC file provided as part of the Novell NetWare DOS client software set. For support assistance concerning Novell's ODINSUP.COM, contact Novell Technical Support.
Windows for Workgroups 3.11 offers the complete solution for customers who need both Microsoft Windows 3.1 and networking software for their PCs. This section has shown how Windows for Workgroups 3.11 integrates into a mixed network environment, allowing users to access file and print resources on existing Novell NetWare servers.
The ability to access data that resides on different hardware platforms, different operating systems, different network operating systems, and different database management systems (DBMSs) is a fundamental need for client-server computing. Microsoft Windows NT is an ideal platform for DBMSs. This platform provides a high level of performance, scalable hardware, and a secure foundation for distributed computing. Features such as preemptive multitasking, multithreading, fault tolerance, and security help meet the growing demands of client-server computing.
Windows NT provides a full 32-bit architecture with a flat memory model, which does away with managing memory in segments, for increased performance. Windows NT and the Win32 API allow for programs, such as DBMSs, that deal with large amounts of data by providing access to 2 GB of address space. The operating system and other processes have their own protected memory spaces so that one process cannot bring another process down.
With preemptive scheduling and an asynchronous input/output model, the operating system, rather than the application, is in control. Windows NT automatically gives high priority to applications running in the foreground and to processes receiving input or completing input/output operations. Multiple threads of execution allow applications to be more powerful and responsive. An application does not have the ability to tie up the system, even when the application is loading, processing data, printing, and so on. The system is always available to the user.
Windows NT was designed from the ground up to support symmetric multiprocessing. The operating system can allocate application and system threads within the same process to different processors. The net benefit is improved performance and transparent scalability of your corporate DBMS.
These features within Windows NT provide a powerful platform for mission-critical database applications. Each DBMS for Windows NT implements this architecture differently and may or may not use all of the features available within Windows NT.
The purpose of this section is to discuss specifically how client workstations communicate with Windows NT databases—including details about MS-DOS, Windows, Windows NT, and OS/2–based client workstations.
At least 16 database vendors have announced support for the Windows NT platform. Client-server databases that are either available now or will be soon available for Windows NT include Microsoft SQL Server, Ingres Server, Oracle® Server, Informix® Server, SQLBase®, and Versant. This section provides a general guideline for implementing client-server databases using Windows NT in a NetWare environment by using Microsoft SQL Server as an illustrative example. For detailed information on how to integrate other database servers into a NetWare environment, contact the vendor of the database server you wish to use.
Microsoft SQL Server version 4.2 for Windows NT extends intelligent client-server database management to your corporate network, offering a powerful platform for the delivery of critical business applications. Microsoft SQL Server has been completely reengineered for Windows NT, including the following enhancements and performance improvements that were not part of the previous versions of SQL Server:
The key to enterprise interoperability is network independence. SQL Server for Windows NT can support clients communicating over multiple heterogeneous networks simultaneously, with no need for additional integration products. SQL Server communicates on named pipes (over either NetBEUI or TCP/IP network protocols) with Windows, Windows NT, MS-DOS, and OS/2–based clients.
In addition, SQL Server for Windows NT can simultaneously support TCP/IP Sockets for communication with Macintosh®, UNIX, or VMS clients and SPX Sockets for communications in a Novell NetWare environment. SQL Server for Windows NT is planned to support Banyan® VINES® in the first quarter of 1994. Microsoft SQL Server for Windows NT leverages the power, ease of use, and scalability offered by the Windows NT operating system to manage large databases for mission-critical applications.
The key interfaces used to access data in a Microsoft SQL Server client-server environment include application programming interfaces (APIs), data stream protocols, interprocess communication (IPC) mechanisms, and network protocols.
Figure 16. SQL Server for Windows NT architecture
Each back-end database typically has its own API through which it communicates with clients. A client application needing to access multiple back-end databases must be able to transform requests and data transfers into each of the corresponding API interfaces. Client-server applications communicate with SQL Server for Windows NT through two APIs—Open Database Connectivity (ODBC) and DB-Library.
ODBC is an API for generic database connectivity for Windows, Windows NT, and, in the future, Macintosh platforms. It is designed to be a general-purpose call-level interface (CLI) for any database back-end, including nonrelational DBMSs. The ODBC interface provides the needed functionality for applications that must access multiple DBMSs from different vendors. Application developers can develop, compile, and ship an application without targeting a specific DBMS, provided that DBMS-specific features are not used. ODBC ensures interoperability by forcing all clients to adhere to a standard interface. The ODBC driver automatically interprets a command for a specific data source.
DB-Library is a set of API calls designed specifically for SQL Server and allows applications to interact with SQL Server. DB-Library provides connectivity between multiplatform clients and SQL Server. DB-Library provides the needed functionality for applications requiring client support for MS-DOS and/or OS/2. DB-Library is also equivalent to the SYBASE Open Client interface on UNIX, VMS, and Macintosh systems.
Every DBMS uses a data stream protocol that enables the transfer of requests, data, status, error messages, and so on, between the DBMS and its clients. This can be thought of as a "logical" protocol. The API uses interprocess communication (IPC) mechanisms supported by the operating system and network to package and transport this logical protocol.
The Microsoft SQL Server data stream protocol is called Tabular Data Stream (TDS). TDS is also used by Open Data Services and SYBASE software to transfer requests and responses between the client and the server. TDS is a logical data stream protocol and must be supported by physical network IPC mechanisms. The Net-Library architecture (described later in this chapter) provides a method of sending TDS across a physical network connection.
Each database's data stream protocol is typically a proprietary one that is developed and optimized to work exclusively with that DBMS. This means that an application accessing multiple databases must be able to use multiple data stream protocols. Using ODBC helps resolve this problem for application developers.
With ODBC, the data stream protocol differences are resolved at the driver level. That is, each driver emits the data stream using the protocol established by the server. The SQL Server ODBC driver emits TDS directly—it does not translate or otherwise encapsulate DB-Library function calls.
Efforts are underway to establish common data stream protocols. IBM® DRDA architecture has defined a data stream protocol known as FD:OCA. The International Standard Organization (ISO) has proposed another data stream standard, RDA (ISO RDA).
The choice of IPC mechanism is constrained by the operating system and network being used. For example, Microsoft SQL Server on OS/2 uses named pipes as its IPC mechanism, SYBASE SQL Server on UNIX uses sockets over TCP/IP or IPX/SPX sockets, and SYBASE on VMS uses DECnet™ Sockets. In a heterogeneous environment, multiple IPC mechanisms may be used on a single computer.
SQL Server for Windows NT has the ability to communicate over multiple IPC mechanisms. SQL Server communicates on named pipes (over either NetBEUI or TCP/IP network protocols) with Windows, Windows NT, MS-DOS, and OS/2–based clients. It can also simultaneously support TCP/IP Sockets for communication with Macintosh, UNIX, or VMS clients and SPX sockets for communications in a Novell NetWare environment. SQL Server for Windows NT is planned to support Banyan VINES in the first quarter of 1994 as well.
A network protocol is used to transport the data stream protocol over a network. It can be considered as the "plumbing" that supports the IPC mechanisms used to implement the data stream protocol, as well as supporting basic network operations such as file transfers and print sharing.
A back-end database can reside on a LAN that connects it with the client application, or it can reside at a remote site, connected via a wide-area network (WAN) and/or gateway. In both cases, it is possible that the network protocol(s) and/or physical network supported by the various back-end databases are different from that supported by the client or each other. In these cases, a client application must use different network protocols to communicate with various back-end databases.
The network transport protocols supported within SQL Server for Windows NT include NetBEUI, TCP/IP, SPX/IPX using NWLink, and VINES IP.
Microsoft SQL Server Net-Library architecture for client-server applications is based on the Net-Library concept that abstracts the client and server applications from the underlying network protocols being used. The figure below shows how SQL Server and related products can be accessed from practically any network environment.
Figure 17. Net-Library architecture
The Net-Library architecture provides a method of sending TDS (used by Microsoft SQL Server, Open Data Services, and SYBASE) across a physical network connection. The Net-Library architecture also provides a transparent interface to the DB-Library APIs and the SQL Server driver for ODBC.
Net-Libraries are linked dynamically at run-time. With the Microsoft Windows NT, Windows, and OS/2 operating systems, Net-Libraries are implemented as DLLs, and multiple Net-Libraries can be loaded simultaneously. With MS-DOS, Net-Libraries are implemented as terminate-and-stay-resident (TSR) programs, and only one can be loaded at a time.
The Net-Library architecture can be divided into two components—server-side Net-Libraries and client-side Net-Libraries.
Server-side Net-Libraries were first introduced with Microsoft SQL Bridge. They are also used by Network Manager in the Microsoft SQL Server Network Integration Kit for Novell NetWare Networks and in the Microsoft SQL Server Network Integration Kit for Banyan VINES Networks. SQL Server on the Windows NT platform uses this same architecture and has the ability to accept client requests across multiple network protocols at the same time.
The diagram below illustrates the integration of server-side Net-Libraries with the various SQL Server–based products on the Windows NT platform. The default Net-Library is named pipes.
Figure 18. Server-Side Net-Library Architecture on the Windows NT platform
When a server-side Net-Library is loaded by an application such as SQL Server for Windows NT, Net-Library implements a network-specific way of establishing communication with clients and, in some cases, registers itself on the network. SQL Server looks at the Windows NT Registry to determine which Net-Library to load on startup and which parameters to pass them. The SQL Server Monitor process also uses server-side Net-Library to communicate with clients and to search the Registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server) for network-specific parameters.
At startup, SQL Server will search for values of the ListenOn and connection_string Registry entries under the Server subkey. Each connection_string Registry value is read and passed on to the associated Net-Library (for example, named pipes) that is listed in the ListenOn field in the Server subkey. Each Net-Library acts upon the connection_string differently.
By default, SQL Server always listens on named pipes, allowing (at minimum) access from client applications running on the same machine. If desired, named pipes access can be turned off by using the Registry Editor to explicitly delete the named pipes entry from the SQL#Server\Server subkey.
Remote stored procedure calls and the Microsoft SQL Administrator tool also use the DB-Library/Net-Library architecture under Windows NT.
When a call is made to open a connection to SQL Server, the API involved (DB-Library or the SQL Server driver for ODBC) determines which client-side Net-Library should be loaded to communicate with SQL Server or Open Data Services. (This is described in more detail below.)
The diagram below shows client-side Net-Libraries used to communicate with SQL Server for Windows NT on the server side.
Figure 19. Client-side Net-Library architecture
The Net-Library DLLs and IPCs for each network protocol supported by SQL Server for Windows NT are listed in the following table. These files are installed automatically using the SQL Server Setup utility on the server side and the SQL Client Configuration Utility on the Windows, Windows NT, and OS/2–based client side. The AUTOEXEC.BAT file is used to load the MS-DOS client Net-Library.
The server-side Net-Library is used by SQL Server and ODS applications. If SQL Server and ODS are on the same computer, ODS uses an alternate pipe.
Interface |
Protocol |
Clients Supported | Client Net-Lib |
Server Net-Lib |
Comments |
| Named Pipes | NetBEUI or TCP/IP | LAN Manager, Windows for Workgroups, and Windows NT–based clients | DBNMPIPE.EXE (MS-DOS), DBNMP3.DLL (Windows), DBNMPP.DLL (OS/2), DBNMPNTW.DLL (Windows NT) | SSNMPNTW.DLL | This network setup will provide SQL Server Integrated Security with the Windows NT User Account Database. |
| NWLink | Windows NT–based clients | DBNMPNTW.DLL (Windows NT) | SSNMPNTW.DLL | ||
| Windows Sockets | TCP/IP | UNIX and MAC clients | Part of SYBASE Open Client | SSMSSOCN.DLL | This configuration provides multiple vendor integration. |
| PC clients: e.g., FTP PC/TCP, Novell LAN WorkPlace, Sun PC-NFS, DEC® Pathworks™, TCP/IP for LAN Manager | SYBASE Net-Libraries | SSMSSOCN.DLL | with SYBASE. The corresponding Net-Libraries are available from SYBASE. | ||
| Windows Sockets | NWLink (IPX/SPX) | NetWare 3.10+ (MS-DOS and Windows) and OS/2 clients | DBMSSPX.EXE (DOS), DBMSSPX3.DLL (Windows), DBMSSPXP.DLL (OS/2) | Novell: SSMSSPXN.DLL | The servername is registered with the Novell bindery service. |
| NWLink | DBMSSPXN.DLL (Windows NT) | ||||
| Vines Sockets | Vines IP | Banyan Vines, 4.11 (rev.5)+ and Windows NT clients | DBMSVINE.EXE (DOS), DBMSVIN3.DLL (Windows), DBMSVINP.DLL (OS/2), DBMSVINN.DLL (Windows NT) | Banyan VINES: SSMSVINN.DLL | Registers to Street talk as the given service. Banyan VINES will automatically handle look-ups of partial names or nicknames. |
Using NetBEUI as the network protocol, the client workstation always uses a broadcast to locate the SQL Server(s) on the network. Also, with TCP/IP the client workstation always uses a broadcast to locate the SQL Server(s), provided that the servername and IP address are not located in the LMHOST file on the workstations.
As shown by the preceding table, in a Novell NetWare environment, SQL Server for Windows NT requires NWLink (installed through Network Control Panel) and the SSMSSPXN.DLL. This DLL is automatically installed on the server side, with the appropriate Registry entries, when you use SQL Server Setup and choose Change Network Support, then NWLink IPX/SPX.
The following is a sample of what is added to the Registry for SQL Server for Windows NT on a Novell Network:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQLServer\Server
ListenOn: REG_MULTI_SZ: SSNMPNTW, \\.\pipe\sql\query SSMSSPXN, CORAL (computername)
Windows and OS/2-based client workstations require the Novell NetWare 3.10 or higher level of IPX. The SQL Client Configuration Utility that ships with SQL Server for Windows NT is used to specify the default network that the Windows and OS/2-based clients will use. By choosing Novell IPX/SPX, the required DBMSSPX3.DLL is automatically installed on the Windows-based client side, and BMSSPXP.DLL is installed on the OS/2 client side. This will add the appropriate entries in the WIN.INI file or the OS/2.INI file, respectively.
The following is a sample of what is added to the WIN.INI for Windows-based clients communicating with SQL Server for Windows NT on a Novell Network:
[SQLSERVER]
DSQUERY=DBMSSPX3
MS-DOS-based clients require the same level of IPX that the Windows-based workstations do. DBMSSPX.EXE must be installed on the MS-DOS computer. This TSR can be loaded either manually or from AUOTEXEC.BAT.
Windows NT–based client workstations use NWLink, which is installed through Network Control Panel. After installation, use the Client Configuration Utility to specify that the default network is Novell IPX/SPX. This, in turn, installs the required DBMSSPXN.DLL on the Windows NT–based client side.
The following is a sample Registry entry for Windows NT–based clients communicating with SQL Server for Windows NT on a Novell Network:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQLServer\Client\ConnectTo
DSQUERY: REG_SZ: DBMSSPXN
This section has shown how Windows NT Advanced server can be integrated into existing environments to serve as a database server, while using existing NetWare servers for NOS (file and print) functions. Customers can use their existing MS-DOS, Windows (all types), and OS/2–based clients to communicate with database servers running on Windows NT Advanced Server using a variety of common communications mechanisms.
Windows NT–based computers can easily be integrated into a predominantly NetWare environment, making the benefits of an advanced operating system available to an existing network. This paper has presented an overview of how Windows NT–based computers can effectively function either as a client of NetWare servers or as an application server for NetWare.