Chapter 17

Integrating Windows NT with Heterogeneous Networks

In this chapter, you learn how to

• Integrate Windows NT Server into an existing Novell NetWare environment
• Provide Microsoft Windows NT Server clients with access to UNIX hosts and provide UNIX clients with access to Windows NT Server services
• Use SNA Server for Windows NT Server to connect DOS, Windows, Mac, OS/2, and Windows NT clients to IBM SNA networks
• Build universal clients using Windows 3.11 for Workgroups and Windows 95

Network managers in the real world seldom have the luxury of working in a homogeneous network operating system (NOS) environment. If your organization runs Windows NT Server as its only NOS, consider yourself lucky. If instead, like many system administrators, you must contend with an installed base of mixed NetWare 3.1x and 4.x servers, a UNIX host here and there, and perhaps a System Network Architecture (SNA) host lurking in the glass house, then read on.

Spanning Multiple Network Protocols

Windows NT Server 4.0 uses a protocol-independent networking architecture, which allows it to interoperate with a wide range of NOSs and protocols. With its support for standard network application interfaces, Windows NT Server easily accommodates simultaneous interoperability with Novell NetWare, UNIX, and IBM SNA networks.

NetWare historically has dominated the NOS market, and now holds about two-thirds of both the number of servers installed and the number of workstations using it. Although Windows NT Server is closing this gap quickly, many network managers will find it necessary to support both NOSs on a temporary basis as their organizations transition to Windows NT Server. Others will need to provide such support on a more or less permanent basis in organizations that plan for both NOSs to coexist on a long-term basis. Fortunately, Windows NT Server provides excellent tools for both migration and long-term coexistence.

UNIX is a fact of life in most medium and large organizations, and again Windows NT Server provides many of the tools you need to allow UNIX workstations and hosts to coexist with Windows NT Server. Microsoft has also recognized the continuing importance of mainframe connectivity to the enterprise and has accordingly provided SNA connectivity tools and services with Windows NT Server.

Integration Feuds

Microsoft's chairman, Bill Gates, and Novell's former chairman, Ray Noorda, didn't much like each other or, at least, so it appeared to most observers in the early 1990s. Each seemed determined to make life as difficult as possible for the other, causing much unnecessary suffering among users of Microsoft and Novell NOSs. This disagreement, played out in the trade press over the years, took on the characteristics of an elementary school yard spat.

Client-side support promised by Novell for Windows NT was late in arriving and seemed to many to be a conscious action on the part of Novell to cripple acceptance of Windows NT. For its part, Microsoft promoted the use of Gateway Services for Windows NT Server as a means to allow hundreds of clients to access a Novell server running only a five-user NetWare license. Novell broadsides were answered in turn by Microsoft, culminating when Novell threatened suit against Microsoft for bundling Novell client software with Windows, and Microsoft subsequently withdrawing that software. To this day, configuring a Windows 3.x client to access a Novell server requires installing client software acquired separately from Novell.

Ray Noorda's departure from Novell and Bob Frankenberg's ascension to the helm appear to have resulted in an uneasy truce in this duel of the Titans, although border skirmishes continue. Microsoft and Novell appear to have realized that neither firm is likely to disappear anytime soon as a key player in the NOS market, and that coexistence better serves both their customers and their own interests. Novell recognizes that Windows NT Server will increasingly appear in heretofore exclusively Novell shops and, accordingly, is improving NetWare's integration with Windows NT, including plans to port NetWare Directory Services (NDS) to the Windows NT platform. On its part, Microsoft has implicitly recognized the current dominance of NetWare and now provides excellent tools for coexistence and migration.

Windows NT Network and Transport Protocols

Until recently, the fundamental problem with integrating Microsoft, Novell, and UNIX networks has been that each used a different and incompatible transport protocol. Microsoft networks historically have used NetBEUI, whereas Novell networks depended on IPX/SPX, and UNIX networks used TCP/IP. As observed in Chapter 4, "Choosing Network Protocols," each network and transport protocol is fast and reliable, and each has advantages and drawbacks:

• NetBEUI requires minimal setup and is easy to administer. Because NetBEUI packets contain no network layer header information, however, they can be bridged only and can't be routed, making NetBEUI usable only for LANs. Microsoft is de-emphasizing NetBEUI for enterprise networking, relegating it to peer networking only.
• IPX/SPX was originally designed for local area networking. Like NetBEUI, IPX/SPX is easy to set up and administer. Unlike NetBEUI, however, IPX/SPX can be routed. Because IPX/SPX was originally designed as a LAN protocol rather than a WAN protocol, it lacks subnetting support, variable packet lengths, and other technical features that make it a less-than-ideal choice as a foundation on which to build an internetwork, at least when considered in isolation. Still, because it combines the ease of use of NetBEUI with much of the flexibility and power of TCP/IP, IPX/SPX can be a good choice as the shared network and transport protocol for a heterogeneous network, particularly one that heavily depends on Novell NetWare servers. Microsoft refers to its IPX/SPX implementation as NWLink.
• TCP/IP was designed from the ground up for internetworking. As the lingua franca of the Internet, TCP/IP provides in abundance all the tools needed to build an internetwork. The sole drawback to TCP/IP is that it can be extremely complex to administer, both on the server side and on the client side. If your environment includes UNIX hosts or workstations, or if you want to set up a corporate intranet or connect to the Internet, you must run TCP/IP.

The Novell-centric view is that everyone should speak IPX/SPX. Although Novell has made some half-hearted, expensive, and poorly received attempts to provide native TCP/IP support-for example, NetWare/IP-the Novell world continues to revolve around IPX/SPX. Similarly, in the UNIX universe, you either speak TCP/IP, or no one listens to you. Many networks, particularly those growing from smaller peer-based environments, depend on NetBEUI, so this protocol, too, needs to be accommodated.

Windows NT Server 4.0 installs only NWLink IPX/SPX transport by default, but allows additional transport protocols to run simultaneously. If your network includes NetWare servers, you should leave NWLink installed. If your network includes UNIX hosts, spans multiple sites, or connects to the Internet, you should also load TCP/IP transport when you install Windows NT Server.

Fortunately, Microsoft has realized the importance of all three of these protocols to those who need to build heterogeneous networks and has provided support for each of the three protocols in Windows NT Server 4.0. You can run one, any two, or all three of these protocols simultaneously to provide the fundamental network and transport layer support you need to build your network. This broad network and transport layer support provides the foundation for linking heterogeneous networking components.

Integrating Windows NT Server with Novell NetWare

The almost seamless integration of Windows NT Server 4.0 with NetWare is one of the major reasons for the phenomenal growth of Windows NT Server sales. In less than two years, Windows NT Server has grown from an also-ran product, which barely appeared in sales charts, to a major competitor to NetWare. Windows NT Server, in contrast to NetWare, provides a superior application server platform. The Microsoft BackOffice suite (the subject of the chapters in Part V, "Windows NT Server and Microsoft BackOffice") provides a solid foundation for developing client/server applications, and competing client/server application development tools from other vendors increasingly are being ported to the Windows NT Server environment.

All these applications can be accessed natively by Microsoft clients, as well as by NetWare clients, by using either the Novell NETx network shell or the VLM (Virtual Loadable Module) requester. The IPX/SPX protocol (NWLink) provided with Windows NT Server (see fig. 17.1) lets NetWare clients communicate with a server application using Novell NetBIOS, Winsock, and Remote Procedure Calls (RPCs).

17.1

Connecting Windows NT and NetWare servers to a NetWare client with NWLink.

Although Windows NT Server's support for diverse network and transport layer protocols has eliminated one problem, still remaining is the issue of what core protocol is used for communication between servers and workstations. Microsoft uses the Server Message Block (SMB) protocol for this purpose, whereas NetWare uses NetWare Core Protocol (NCP). If NetWare clients are to be able to access Windows NT servers, and if Windows NT clients are to be able to access NetWare servers, something must be done to translate between these two fundamental but incompatible protocols. Microsoft provides the following two utilities to bridge this gap:

• Gateway Service for NetWare (GSNW) allows clients running Microsoft client software to access shared files on a NetWare server and to print to NetWare printers. GSNW translates the upper layer SMB calls to and from NetWare NCP calls. GSNW is included with Windows NT Server 4.0.
• File and Print Services for NetWare (FPSN) allows Windows NT Server to emulate a NetWare 3.12 server. Novell clients can access shared files and printers in the same way that they would access shared resources on any NetWare 3.12 server. FPSN avoids the translation between SMB and NCP by simply dealing with NetWare clients directly as NCP devices.

With a market share that now stands at about 65 percent and is gradually declining, Novell has little motivation to provide tools to make it even easier for Windows NT Server to coexist with or replace NetWare. On the other hand, with market share now at about 10 percent and growing explosively, Microsoft Windows NT Server has everything to gain from readily making available such tools to ease coexistence and migration. Fortunately, Microsoft, recognizing its second-place position in the networking business, has taken responsibility for bridging the core protocol gap by providing a set of tools designed to facilitate integration of Windows NT Server with NetWare servers.

Accessing Novell NetWare Servers Using Microsoft Clients

Clients running Microsoft Networking client software can access shared files and printers on a Novell NetWare server in one of the following three ways:

• Use a client operating system, such as Windows NT Workstation or Windows 95, that provides built-in support for both Microsoft Networking and NetWare. As supplied, these clients provide full access to NetWare 3.1x servers. They allow you to access NetWare 4.x servers using bindery emulation mode, but don't provide NDS support. You can update your Windows 95 clients to provide full NDS support by installing the Service for NetWare Directory Services, available in Windows 95 Service Pack 1, which you can download from www.microsoft.com.
• Add a Novell NetWare client protocol stack to a client to provide full access to NetWare services. The Novell NetWare client coexists with the Microsoft Networking client and supports full NDS access on NetWare 4.x servers. You can download the 32-bit client for Windows 95 from ftp.novell.com/pub/updates/nwos/nc32w952 and for DOS/Windows 3.1+ from ftp.novell.com/pub/updates/nwos/cl32dw21.
• Install Gateway Service for NetWare (GSNW) to let clients running only Microsoft Networking client software access NetWare server resources via gateway services provided by Windows NT Server.

The method you use for a particular client depends on both the operating system that client is running and the level of NetWare connectivity you need to provide to that client.

Using a Client Operating System with Built-In NetWare Support.

Windows 95 and Windows NT 4.0's Workstation and Server versions include the Windows NT Multiple Provider Router (MPR) API, which isn't to be confused with the Multi-Protocol Routing Service, described later in this chapter. The MPR API provides a consistent application interface to the local file system, remote Windows network servers, and NetWare servers.

Any workstation running either of these 32-bit operating systems has access internally to all services needed to use NetWare resources without the need for a separate NetWare-specific protocol stack. NDS isn't supported, although any of these clients can access a NetWare 4.x server running in bindery emulation mode. Installing NetWare support for a Windows 95 client is described fully in Chapter 10, "Configuring Windows 95 Clients for Networking." Installing NetWare support for Windows NT Workstation is described in Chapter 11, "Connecting Other PC Clients to the Network."

Adding a Novell Protocol Stack.

If your clients' operating system doesn't include native NetWare support, or if you require extended access to NetWare 4.1 services, you have no alternative but to install Novell NetWare client software on that client. Novell supplies full-function NetWare client software for numerous workstation operating systems, including DOS, Windows 3.x, Windows 95, Windows NT, OS/2, UNIX, and the Macintosh.

The primary drawbacks to installing Novell client software are as follows:

• Additional effort is required to configure each workstation initially.
• Additional ongoing maintenance is required to support a more complex client environment.
• Additional conventional or base memory is needed for the second protocol stack.

The preceding problems are likely to disappear in the long run, as Microsoft improves NetWare support in its client operating systems. Both Microsoft and Novell are now shipping 32-bit NetWare clients for Windows 95 that provide NDS support.

Adding NetWare client support to coexist with an existing Microsoft Networking client is relatively straightforward, but doing so successfully requires that you first understand the fundamentals of how a Novell NetWare client accesses a NetWare server.

Novell clients require an IPX driver to provide network and transport layer services, and a shell to provide network redirection. Novell clients can use one of two methods for meeting each of these requirements:

• The original Novell client software used a monolithic IPX driver with the NETx shell. The monolithic IPX driver, IPX.COM, is generated for each client using the Novell program WSGEN. The resulting IPX.COM file is specific to the individual client because it's hard-coded for the address and IRQ of the NIC, and so forth. The monolithic IPX.COM drivers are a nightmare to administer; each change to a client configuration requires that the IPX.COM for that client be created anew. More important from an interoperability aspect, IPX.COM supports only a single IPX protocol stack.
• The NetWare shell was originally provided in versions specific to the version of DOS being used. NET2.COM, for example, was used with MS-DOS 2.x; NET3.COM was used with MS-DOS 3.x; and so forth. With the advent of MS-DOS 5.0, Novell shipped a version called NETx, which could be used with any version of DOS. Variants of NETx called EMSNETx and XMSNETx were also provided to take advantage of expanded and extended memory, respectively.

With the advent of NetWare 4.0, Novell altered its client software support. The NETx shell was replaced by the Virtual Loadable Module (VLM) requester. More important from an interoperability standpoint, the monolithic IPX.COM was replaced by the Novell Open Datalink Interface (ODI), which breaks down the services formerly provided by IPX.COM into separate layers:

• The link support layer is loaded first by running the program LSL.COM provided by Novell. The link support layer provides a standardized low-level hardware interface and handles routing of frames to the correct protocol service.
• The Multiple Link Interface Driver (MLID) is loaded next. The MLID is specific to the model of network interface card being used. For example, if you use a 3Com 3C509 Ethernet card, run the MLID 3C5X9.COM. If instead you're using a Novell NE2000 Ethernet card, run NE2000.COM. The MLID provides an interface to the link support layer running below it and to the protocol stack(s) running above it.
• The protocol support layer is the last ODI layer to be loaded. It provides services for one or more network protocols. For example, IPX services are provided by the program IPXODI.COM, which is often the only protocol support to be found on NetWare clients. However, LSL and the MLID can simultaneously load and service additional protocols-for example, TCPIP.EXE.

Clients that use ODI to provide protocol support can use either the NETx shell or the VLM requesters to provide redirection services. Although the VLM requester provides superior services and reduced memory usage, many NetWare clients continue to use the NETx shell. In some cases, this is due to incompatibilities between the VLM requester and a few older network applications. In others, it's simply a matter of inertia. Clients that run the monolithic IPX.COM are limited to using NETx because the monolithic drivers don't support the VLM requester.

Whether you choose to install NETx NetWare shell or the VLM NetWare requester, ensure that your NICs are using Novell ODI drivers. The older monolithic drivers are no longer supported by Novell, are much harder to maintain, and-most importantly-don't let you run other protocols. As mentioned earlier, Windows NT Server is protocol independent. Windows NT Server is bundled with the NWLink protocol, so many NetWare system managers will be happy to learn that they don't have to install a second protocol stack on their clients. Other NetWare administrators may opt to load the Microsoft TCP/IP protocol stack supplied on the Windows NT Server 4.0 CD-ROM, giving their clients simultaneous access to NetWare, Windows NT, UNIX, and the Internet.

Microsoft Networking software uses a methodology similar to but incompatible with ODI to communicate with NICs. This method, called the Network Device Interface Specification (NDIS), offers functionality similar to ODI. Fortunately, both Microsoft and Novell provide shim drivers (or shims) that allow interoperability between ODI and NDIS. Microsoft PC-client software uses the NetWare ODI driver, automatically installing the NDIS-to-ODI shim.

Using Gateway Service for NetWare.

The Gateway Service for NetWare (see fig. 17.2) is bundled with Windows NT Server 4.0. Running as a service on Windows NT Server 4.0, GSNW lets one or more Microsoft Networking clients access NetWare resources. Used with Client Service for NetWare and the NWLink protocol, GSNW allows Windows NT Server clients to access shared files on a NetWare server and to print to NetWare printers. Microsoft Networking clients don't need to run the IPX/SPX protocol because the GSNW translates the upper layer SMB calls to and from NetWare NCP calls.

17.2

Microsoft Networking clients accessing shared resources on a Novell NetWare server with the Gateway Service for NetWare.

An added benefit of using GSNW is that it can be deployed with Remote Access Service to allow remote Microsoft Networking clients to access NetWare file and print services transparently. For more information on Remote Access Service, see Chapter 18, "Managing Remote Access Service."

Before implementing GSNW, the Windows NT Server administrator and the NetWare administrator should consider the following issues:

• NDS support. GSNW is intended primarily for use in a NetWare 2.x/3.x environment and doesn't support Novell NDS. Although a GSNW client can access a NetWare 4.x server, it can do so only through bindery emulation mode.
• Performance. The GSNW uses a single NetWare connection through which all requests are routed to the NetWare server from GSNW clients. On the one hand, this is an advantage because additional NetWare user licenses beyond the single license needed by GSNW don't need to be purchased for each user logging on to a NetWare server from GSNW. The down side of GSNW is that traffic from all GSNW users is routed through a single NetWare connection, so performance can degrade noticeably under a heavy load.
• Shared rights. GSNW uses a single connection to the NetWare server, so all GSNW clients use the same NetWare account. This means that all GSNW clients have identical trustee rights and other permissions, which are determined by the settings for that one account. All GSNW users are assigned to the NetWare group NTGATEWAY.
• Logon scripts. Microsoft networking clients don't execute NetWare logon scripts.
• Backup. The backup software bundled with NetWare doesn't back up GSNW clients.
• Account management. Whether a particular Windows NT client is granted access to GSNW, as well as global restrictions placed on GSNW users that have been granted access, are determined by the Windows NT Server system administrator.

Configuring a NetWare Server to Use Gateway Service for NetWare.

Little needs to be done on the NetWare server to prepare it for use with GSNW, but Supervisor access on the NetWare server is required to use the Novell SYSCON utility to make these changes. To prepare the NetWare server, follow these steps:

1. Log on to the NetWare 3.1x server as supervisor (or supervisor equivalent) and run SYSCON.EXE (see fig. 17.3).

   
   17.3

   Using Novell's SYSCON.EXE to prepare the NetWare 3.1x server for the Gateway Service for NetWare.

2. Create a new NetWare group with the mandatory name NTGATEWAY (see fig. 17.4). Grant this group the file, directory, and printer rights that you want available to all users of the shared gateway.

   
   17.4

   Creating the NetWare group NTGATEWAY and granting all file, directory, and printer rights to be shared.

3. Create a new NetWare user with the same name and password as that used to log on to the Windows NT Server running GSNW (see fig. 17.5). This user is granted NetWare Supervisor Equivalent rights. This account is used by the system manager for maintenance and can also be used by the Migration Tool for NetWare, which requires full access to the NetWare server. With this account, logging on to the NetWare server from the computer running Windows NT Server allows you to run NetWare utilities, in addition to using NetWare files and printers.

   
   17.5

   Creating a supervisor equivalent user for system maintenance and to run NetWare utilities.

4. Create one or more new NetWare user accounts (see fig. 17.6) to be used by GSNW users, and assign each of these accounts to the NTGATEWAY group. Each account inherits the rights granted to the NTGATEWAY group and can also be assigned additional file and directory access rights of its own.

   
   17.6

   Creating NetWare user accounts for shared access to the NetWare server, and assigning them to the NTGATEWAY group.

Installing Gateway Service for NetWare.

After you make the necessary changes to your NetWare server, the next step is to install the GSNW on your Windows NT Server. Proceed as follows:

1. In Control Panel, double-click the Network tool to display the Network property sheet. Click the Services tab to display installed network services (see fig. 17.7).
2. Click Add to display the Select Network Service dialog (see fig. 17.8).

   
   17.7

   Displaying installed Network Services in the Network property sheet.

   
   17.8

   Selecting Gateway (and Client) Services for NetWare in the Select Network Service dialog.

3. Select Gateway (and Client) Services for NetWare and click OK to display the Windows NT Setup dialog (see fig. 17.9).

   
   17.9

   Specifying the location of the Gateway Service for NetWare distribution files in the Windows NT Setup dialog.

4. In the text box, type the drive and path name where the GSNW distribution files are located, and then click Continue to begin copying files. Windows NT Setup displays the progress of the file copying operation.

   

   At this point, the NWLink IPX/SPX Protocol Configuration dialog may appear if you have more than one NIC installed in your server, or if Windows NT can't automatically configure the protocol. If so, specify which NIC is to be used to link to the NetWare server. Windows NT Server normally detects the correct frame type needed by this NIC to communicate with the NetWare server and installs it as a default, showing the Frame Type as Auto Detected. If for some reason you need to change the frame type, choose one from the Frame Type list box. Other tunable parameters are stored in the Registry and can be changed by clicking the Advanced button.

   There's usually no reason to alter these settings. Make sure that you have good reason before you attempt to do so.

   

   

   See "Using the Registry Editor," (Ch 9)

   

5. After all files are copied, the Network property sheet reappears, with Gateway Service for NetWare now visible as an installed network service (see fig. 17.10).

   
   17.10

   The Network property sheet displaying Gateway Service for NetWare as an installed network service.

6. Click Close to complete the installation of Gateway Service for NetWare. Windows NT Server then configures and stores the affected bindings.

When the bindings review is complete, the Network Settings Change dialog appears to notify you that you must restart Windows NT Server before the changes will take effect.

Choosing a Preferred NetWare Server.

If more than one NetWare server exists on your network when GSNW is first run, the Select Preferred Server for NetWare dialog displays to prompt you to choose one of these servers as the default server to which GSNW should connect. You can either choose one of the servers as the default preferred server for that logon account, or choose none. Based on your selection, the preferred server is determined as follows:

• If you specify a server, that server remains your preferred server until you explicitly change it. Because the server that you first attach to performs the logon validation that's then used to determine user access to server resources, specifying a server is normally preferable.
• If you specify no preferred server, GSNW locates the nearest NetWare server each time you log on. Understand that nearest means the NetWare server that responds the fastest at the moment you log on, so if you choose the None option, you can't predict to which server you'll connect.

Enabling the Gateway and Activating Shares.

After you create the necessary group and user accounts on the NetWare server and install GSNW, the next step is to enable GSNW. Follow these steps:

1. From Control Panel, double-click the GSNW tool to display the Gateway Service for NetWare dialog (see fig. 17.11).

   
   17.11

   Setting the preferred server and other options in the Gateway Service for NetWare dialog.

2. Click Gateway to display the Configure Gateway dialog. Mark the Enable Gateway check box, and fill in the Gateway Account, Password, and Confirm Password text boxes, as shown in figure 17.12.

   
   17.12

   Enabling the gateway and entering account name and password information in the Configure Gateway dialog.

3. Choose Add to display the New Share dialog (see fig. 17.13). Enter a Share Name by which the resource will be known. Next, enter the Network Path associated with the share. Optionally, enter a Comment to further describe the shared resource. Finally, select a drive letter from the drop-down list to be assigned to the share.
4. The User Limit section allows you to specify the maximum number of users who can access the share concurrently. Select either Unlimited, or select Allow and use the arrow keys to specify a maximum allowable number of concurrent users.
5. After you complete all this information, click OK to accept your changes.

   
   17.13

   Entering a share name, specifying the associated network path, and designating a drive letter by which the share can be accessed.

6. The Configure Gateway dialog reappears, with the new share visible (see fig. 17.14). Use the Add button to create additional shares as needed. Use the Remove button to remove unneeded shares.

   
   17.14

   The completed Configure Gateway dialog, showing the newly created share.

7. To set permissions for the shares you've just created, choose Permissions to display the Access Through Share Permissions dialog (see fig. 17.15). Use this dialog to set permissions as described in Chapter 13, "Sharing and Securing Network Resources."

   

   See "Working with Share Permissions," (Ch. 13)

   

   
   17.15

   Assigning permissions for the newly created share in the Access Through Share Permissions dialog.

Installing and Configuring a GSNW Print Gateway.

Installing a GSNW print gateway lets Microsoft Networking users print to NetWare printers. After Gateway Service for NetWare is installed and enabled, and a print gateway is configured, a NetWare printer appears on the Windows NT Server computer simply as another shared printer. Access to and control of shared NetWare printers is determined by setting the properties for the shared printer from within the Printers folder on the Windows NT server. Print jobs sent to the gateway are redirected to the NetWare print queue to which the gateway is mapped.

To install and configure the GSNW print gateway, follow these steps:

1. From the Start menu, choose Settings and then Printers to display the Printers folder. Double-click the Add Printer icon to display the Add Printer Wizard (see fig. 17.16).

   
   17.16

   Setting up a shared network printer with the Add Printer Wizard.

   

   See "Configuring Locally Attached Server Printers as Shared Resources," (Ch 13)

   

2. Select the Network Printer Server option, and click Next to display the Connect to Printer dialog (see fig. 17.17).

   
   17.17

   Displaying available print queues for a Windows NT server.

3. In the Shared Printers list, double-click NDS tree names and NetWare 3.1x server names to expand the display and list the shared printers available with each server. When you've located the printer to be shared, select it and click OK.
4. The Add Printer Wizard next prompts you to specify whether you want this printer to be the default printer for Windows applications (see fig. 17.18). Select Yes or No and then click Next.

   
   17.18

   Specifying that the printer won't be the default printer for Windows applications.

5. The Add Printer Wizard informs you that the printer has been installed successfully (see fig. 17.19). Click Finish to complete the installation and return to the Printers folder. At this point, the shared printer is installed but not yet enabled.

   
   17.19

   The Add Printer Wizard's final step in adding a print queue for a NetWare printer.

6. To enable the newly created shared printer, right-click its icon to display the context-sensitive menu, and choose Properties to display the print queue property sheet.
7. Select the Shared option button and enter a name for the shared printer (see fig. 17.20). The rest of the printer configuration process is described step by step in Chapter 13, "Sharing and Securing Network Resources."

   

   See "Sharing and Securing Network Printers,"(Ch. 13)

   

   
   17.20

   Specifying a Share Name for the printer.

8. Choose OK to accept your changes and return to the Printers folder. Close the Printers folder. The shared printer is now available for use by authorized GSNW users.

Microsoft Networking clients now see the shared NetWare printer as they would any shared printer available on the Windows NT server.

Accessing Microsoft Windows NT Servers Using NetWare Clients

Many LAN administrators are faced with integrating a new Windows NT server into an existing network that includes a large installed base of NetWare clients. You may have scores or hundreds of clients, each already running Novell client software to access the existing NetWare servers. Visiting each workstation to install and configure new network client software is expensive, time-consuming, and disruptive. Fortunately, Microsoft offers a way to avoid this effort and cost by using the existing NetWare client software to access the new Windows NT server.

File and Print Services for NetWare, shown diagrammatically in figure 17.21, is a $100 utility available from Microsoft that runs on Windows NT Server. Running File and Print Services for NetWare causes the Windows NT 4.0 server to appear to Novell clients as a NetWare 3.12 server. Unlike GSNW, the performance of File and Print Services for NetWare is very good and doesn't degrade under heavy load. Microsoft positions File and Print Services for NetWare as a product that not only eases integration of Windows NT into a NetWare environment, but one that also serves as an excellent transition tool.

17.21

Emulating a NetWare 3.12 server with Windows NT 4.0's File and Print Services for NetWare.

It's easy to confuse the purposes of Gateway Service for NetWare versus File and Print Services for NetWare. They're exactly opposite. Gateway Service for NetWare allows Microsoft clients to access a Novell NetWare server. File and Print Service for NetWare allows Novell clients to access a Windows NT server.

File and Print Services for NetWare uses as its foundation Windows NT Server's NWLink, GSNW, and an enhanced version of the bundled Migration Tool for NetWare. With Directory Service Manager for NetWare (described in a later section), an administrator can centrally manage user accounts for both NetWare and Windows NT servers.

NetWare clients can access a Windows NT server running File and Print Services for NetWare by using either the NetWare NETx shell or the VLM requester. Installing File and Print Services for NetWare creates a NetWare volume called :SYSVOL, which has a directory structure analogous to a NetWare SYS: volume, including the LOGIN, PUBLIC, MAIL, and SYSTEM directories. Clients can continue to use NetWare-compatible utilities, including ATTACH, LOGIN, LOGOUT, SETPASS, MAP, SLIST, CAPTURE, and ENDCAP to access shared files and printers.

File and Print Services for NetWare also includes an enhanced version of the basic Migration Tool for NetWare bundled with Windows NT Server. The Migration Tool for NetWare, covered more fully later in the section "Migrating from Novell NetWare to Windows NT Server," translates NetWare account information to Windows NT Server, re-creating NetWare user and group information, files and directories, security and permissions, and logon scripts.

Although File and Print Services for NetWare allows workstations running Novell client software to access the Windows NT server without using Microsoft client software, you must still provide each such client with a Windows NT Server user access license.

Installing File and Print Services for NetWare.

To install File and Print Services for NetWare (FPNW), follow these steps:

1. From Control Panel, double-click the Network tool to display the Network property sheet, and then click Add to display the Select Network Service dialog.
2. Click Have Disk to display the Insert Disk dialog. Enter the drive and path where the FPNW distribution files are located, and then click OK to continue.
3. The Select OEM Option dialog appears (see fig. 17.22). You're installing FPNW, so select File and Print Services for NetWare. Click OK to continue. Windows NT Setup copies the distribution files from the diskette.

   
   17.22

   Installing File and Print Services for NetWare from the distribution diskette.

4. After all files are copied, the Install File and Print Services for NetWare dialog appears (see fig. 17.23). Use this dialog to specify the location of the NetWare SYS: volume, enter the supervisor account information, and tune server performance. Set the following values:
   • Directory for SYS Volume is completed with the default value of C:\SYSVOL. Accept this location, or specify an alternate drive and directory name. The location you specify must reside on an NTFS partition if you want to set NTFS file access permissions and NTFS directory access permissions to control access to the volume.

   
   17.23

   Specifying volume location, supervisor account information, and performance tuning in the Install File and Print Services for NetWare dialog.

   • Server Name is completed with the default value of SERVER_NAME_FPNW. Accept this name or specify an alternate server name that users will use to access this server. The name you specify can't be the Microsoft computer name for the server.
   • Password and Confirm Password requires that you enter and re-enter the supervisor account password for the NetWare server.
   • The options in the Tuning section allow you to determine server performance and resource usage:

   Option Description

   Minimize Memory Usage Uses minimal memory at the expense of slower FPNW performance. This selection is most appropriate for a server that's used primarily for purposes other than sharing files and printers-for example, an application server.

   Balance Between Memory Provides moderately high server performance with moderate memory usage. This choice is most appropriate for a general- purpose server that will share files and printers as well as run applications.

   Maximize Performance Provides the highest server performance at the expense of increased memory usage. This choice is most appropriate for a server that will be dedicated to sharing files and printers.

5. After you fill in all required values, click OK to accept your changes. The File and Print Services for NetWare dialog appears (see fig. 17.24).

   
   17.24

   Entering the password for the account to be used to run File and Print Services for NetWare.

6. Enter and confirm the password to be used to run File and Print Services for NetWare and click OK. Windows NT Setup copies the FPNW distribution files to your server.
7. After all files are copied, the Network property sheet appears (see fig. 17.25), with File and Print Services for NetWare visible as an installed network service.

   
   17.25

   The Network property sheet, displaying File and Print Services for NetWare as an installed network service.

8. Click Close to complete the installation. Windows NT Server begins Bindings Configuration. After configuring the bindings, it stores the bindings and then finally reviews the bindings.
9. After Windows NT Server finishes configuring, reviewing, and storing the bindings, it displays the NWLink IPX/SPX Properties sheet (see fig. 17.26). Enter the Internal Network Number and specify parameters for each NIC. Use the Adapter drop-down list to select each adapter, and specify a frame type. Leave the frame type set at Auto Frame Type Detection unless you're experiencing problems connecting to the NetWare server.

   
   17.26

   The NWLink IPX/SPX Properties sheet's General page, which allows you to specify protocol properties for each adapter.

10. Click the Routing tab (see fig. 17.27). If you want your Windows NT server to act as an IPX/SPX router, mark the Enable RIP Routing check box. After you complete the NWLink IPX/SPX Properties sheet, click OK to continue.

    
    17.27

    Enabling IPX/SPX RIP routing on the Routing page of the NWLink IPX/SPX Properties sheet.

11. If the internal network number you provided in step 10 is invalid, the NWLink IPX/SPX message box shown in figure 17.28 appears. When you click OK to return to the NWLink IPX/SPX Properties sheet, Windows NT Server generates a random internal network number for you (see fig. 17.29). Accept this randomly generated number, or enter a correct internal network number of your own. Choose OK to continue.

    
    17.28

    The NWLink IPX/SPX message box that warns you that the internal network number is invalid.

    
    17.29

    The random internal network number generated by Windows NT Server.

12. Windows NT again configures, stores, and reviews the bindings. The Network Settings Change message box appears to warn you that you must restart Windows NT Server before the changes take effect. After the server restarts, FPNW is available.

Configuring and Managing File and Print Services for NetWare.

After you install File and Print Services for NetWare, you must configure it before Novell NetWare resources are available to users. Follow these steps to configure FPNW:

1. From Control Panel, double-click the FPNW tool to display the File and Print Services for NetWare on Servername dialog (see fig. 17.30). The File Server Information section displays various statistics about the associated NetWare file server and the FPNW gateway to that server.

   
   17.30

   Displaying statistics and configuration parameters for the FPNW gateway in the File and Print Services for NetWare on Servername dialog.

2. The FPNW Server Name text box displays the default name assigned to the FPNW gateway when it was installed. You can assign another name or accept the name as is.
3. Enter a short description of the FPNW gateway in the Description text box, if needed.
4. The Home Directory Root Path text box displays the NetWare volume assigned to this gateway when it was installed. You can assign another volume, or accept the volume displayed.
5. The Default Queue drop-down list is initially set to <NONE>. The list displays all NetWare print queues available on the server. Select one of these queues to specify it as the default print queue for FPNW users.

The Users, Volumes, and Files buttons in the File and Print Services for NetWare on Servername dialog allow you to manage the FPNW gateway, as follows:

• Click Users to display the Users on Servername dialog (see fig. 17.31). The Connected Users list displays the name, Network Address, Node Address, and Login Time for each user. You can use this list to Disconnect a user, to Disconnect All users, or to Send Message to a user or users. The Resources list displays the Drives and Opens for each resource.

17.31

Displaying user statistics and managing users with the Users on Servername dialog.

• After you finish managing users, click Close to return to the File and Print Services for NetWare on Servername dialog.
• Click Volumes to display the Volumes Usage on Servername dialog (see fig. 17.32). The Volume list displays available volumes. For each volume, Users lists the current number of users accessing that volume; Max Users lists the maximum number of concurrent users allowed; and Path lists the Windows NT Server drive and folder associated with the NetWare volume.

17.32

Displaying volume statistics and managing volumes in the Volumes Usage on Servername dialog.

• The Connected Users list displays the name of each Connected User, Connection Time, and Opens for the volume highlighted in the Volume list. You can disconnect a specific user by highlighting that user and choosing Disconnect, or disconnect all users by choosing Disconnect All. After you finish managing volumes, click Close to return to the File and Print Services for NetWare on Servername dialog.
• Click Files to display the Files Opened by Users on Servername dialog (see fig. 17.33). The Opened By list displays the name of the user who opened each listed file. For each open file, For displays the permissions associated with that open; Locks displays the number of Locks on that file; and Volume and Path display the location of the file. Click Close File to close a selected file. Click Close All Files to close all files listed. Click Refresh to update the list of displayed files.
• After you finish managing files, click Close to return to the File and Print Services for NetWare on Servername dialog.

17.33

Displaying file statistics and managing files with the Files Opened by Users dialog.

After you finish configuring and managing the FPNW gateway, click OK to accept the changes and close the File and Print Services for NetWare on Servername dialog.

Other Windows NT Server Integration Tools for NetWare

In addition to GSNW and the File and Print Service for NetWare, two other tools are available for Windows NT Server to aid integration with Novell NetWare environments. The Directory Service Manager for NetWare allows you to manage user accounts on Windows NT servers and NetWare servers using a single integrated database. The Multi-Protocol Routing Service allows your Windows NT server to provide software routing to link networks.

Directory Service Manager for NetWare.

If, in addition to one or more Windows NT servers, your network includes Novell NetWare 2.x/3.x servers or NetWare 4.x servers running bindery emulation, you might consider buying Directory Service Manager for NetWare. Directory Service Manager for NetWare (see fig. 17.34) is used initially to export NetWare user account information into Windows NT Directory Services and to subsequently maintain all Windows NT Server and NetWare Server user account information in a common database.

17.34

Directory Service Manager for NetWare connecting NetWare 2.x/3.x servers to a Windows NT 4.0 domain.

During the initial transfer of NetWare user account information, the administrator has the option of creating a Map File to re-create the NetWare accounts' passwords, assign a single password to all accounts, or set the password to the user name. The Directory Service Manager for NetWare Administrators Guide lists the necessary steps involved to import the NetWare servers user account information. The initial setup process is complicated, so Directory Service Manager for NetWare includes a Trial Run option that creates a log file containing the account information that would be migrated to the Windows NT Server.

After you select the user and groups to be propagated to and from the NetWare servers, any changes to those accounts on Windows NT Server are replicated automatically to the NetWare servers. The replication process isn't bi-directional, so all subsequent changes must be made using Directory Service Manager for NetWare. When the initial migration is complete, the Directory Service Manager for NetWare database doesn't reflect any changes made directly to a NetWare server. Once installed, Directory Service Manager for NetWare provides a single network logon (see fig. 17.35).

17.35

Creating a single network logon for NetWare clients across two Windows NT domains.

Installing Directory Service Manager for NetWare.

To install Directory Service Manager for NetWare, follow these steps:

1. From Control Panel, double-click the Network tool to display the Network property sheet. Click the Services tab.
2. Choose Add to display the Select Network Service dialog. Windows NT Server 4.0 builds a list of available services and displays them in the Network Service list box.

   

   If an older version of Directory Service for NetWare is already installed on the computer, it appears in the Network Service list box. Don't select the older version. Instead, choose Have Disk to install the current version.

   

3. Click Have Disk to display the Insert Disk dialog. In the text box, type the drive and path name where the DSMN distribution files are located, and then choose OK. The Select OEM Option dialog appears (see fig. 17.36). You're installing the full service, so select Directory Service Manager for NetWare and click OK.

   
   17.36

   Choosing the full Directory Service Manager for NetWare in the Select OEM Option dialog.

   

   If you're installing directly from the distribution CD, the DSMN distribution files are located in d:\dsmn\nt40\processor, where d is the drive letter assigned to your CD-ROM drive, and processor is the type of processor installed in your server, such as i386 for Intel computers.

   

4. After Setup installs the files, the Install Directory Service Manager for NetWare dialog appears (see fig. 17.37). Enter and confirm a password of your choice for the service account, and click OK.

   
   17.37

   Entering and confirming the password for the account to be used for DSNW.

5. Windows NT Server returns to the Network property sheet, displaying DSMN as an installed network service (see fig. 17.38).

   
   17.38

   The Network property sheet displaying DSMN as an installed network service.

6. Click Close to complete the installation. Windows NT Server configures, stores, and reviews bindings. The Network Settings Change dialog notifies you that you must restart the server before the changes take effect.

Configuring and Managing Directory Service Manager for NetWare.

After you install DSMN, follow these steps to configure and manage it:

This procedure makes changes to the bindery on your NetWare server. Before you begin, be sure to back up the bindery. To do so, log on to the NetWare server as supervisor or supervisor equivalent from a DOS, Windows 3.1x, or Windows 95 client (you can't run the Novell system utilities from Windows NT). Notify all connected NetWare clients to log off. After they do so, run BINDFIX.EXE. Store the resulting three bindery backup files (NET$OBJ.OLD, NET$PROP.OLD, and NET$VAL.OLD) in a safe place before continuing.

1. From the Start menu, choose Programs, Administrative Tools, and Directory Service Manager for NetWare to run the Synchronization Manager. The title bar displays the domain name you're managing. When first run, the Synchronization Manager displays an empty NetWare Server list box, shown in figure 17.39.

   
   17.39

   The initial status of DSMN's Synchronization Manager.

2. From the NetWare Server menu, choose Add Server to Manage to display the Select NetWare Server dialog (see fig. 17.40). The Select NetWare Server list displays available NetWare servers.

   
   17.40

   Displaying available NetWare servers in the Select NetWare Server dialog.

3. Select one of the servers listed and click OK to display the Connect to NetWare Server dialog (see fig. 17.41). Enter a user name and a password. This account must be either the supervisor or another account with supervisor equivalent privileges on the NetWare server.

   
   17.41

   Specifying a user name in the Connect to NetWare Server dialog.

4. Click OK to display the Propagate NetWare Accounts to Windows NT Domain dialog (see fig. 17.42).

   
   17.42

   The default NetWare users and groups propagated to Windows NT Server by DSMN synchronization.

5. By default, all NetWare users are placed in the Users to Be Propagated list box, and all NetWare groups are placed in the Groups to Be Propagated list box. Use the Add and Remove buttons to move users and groups between the list boxes. Also specify the following settings:
   • User Must Change Password, if marked, specifies that when a user first logs on, he must immediately change his password.
   • Add Supervisors to Administrators Group, if marked, specifies that Novell supervisor and supervisor equivalent users will be added as members of the Windows NT Administrators group.
   • Add File Server Console Operators to Console Operators Group, if marked, specifies that Novell File Server Console Operators will be added as members of the Windows NT Console Operators group.
   • Use Mapping File, if selected, specifies that individual user propagation parameters are based on the contents of an ASCII mapping file.
   • The Password section allows you to specify how passwords will be assigned on the newly created Windows NT accounts. Select one of the option buttons to determine password assignments. No Password specifies that the new account won't be assigned a password. Password is Username specifies that the password will be set to the user name for each account. Password Is allows you to specify a single password that will be used for all newly created accounts. Randomly Generated Password Of specifies that each newly created account will have a randomly generated password with the number of characters specified by the Characters spinner box.
6. After you complete the Propagate NetWare Accounts to Windows NT Domain dialog as shown in figure 17.43, click Trial Run to test your settings. If a problem occurs during the trial run, a message box displays the problem and gives you the opportunity to correct it. Fix any problems reported and rerun the trial run until it completes successfully.

   
   17.43

   Specifying changes to the default settings of the Propagate NetWare Accounts to Windows NT Domain dialog.

7. When the trial run completes successfully, the Synchronization Manager message box (see fig. 17.44) tells you so. Click Yes to display the trial run log file (see fig. 17.45).

   
   17.44

   The Synchronization Manager's message after a trial run succeeds.

   
   17.45

   Displaying the trial run log file in Notepad.

8. Review the log file to make sure that synchronization will take place as expected. When you're satisfied that everything is correct, close the log file to return to the Propagate NetWare Accounts to Windows NT Domain dialog.
9. Click OK to complete the synchronization. The Synchronization Manager message box (see fig. 17.46) notifies you that you should back up your NetWare bindery before proceeding.

   
   17.46

   Synchronization Manager's warning to back up your NetWare bindery before proceeding.

10. When you're satisfied that your NetWare bindery is safe, click Yes to display the Set Propagated Accounts on Servername dialog (see fig. 17.47).

    
    17.47

    The Set Propagated Accounts on Servername dialog specifies which accounts will be propagated, based on group membership.

    

    By default, the Users May Only Change Their Passwords via Directory Service Manager for NetWare check box is marked. If you want users to be able to change their passwords by using standard Novell utilities, unmark this check box.

    

11. Use the Add and Remove buttons to specify the users to be propagated. After you complete this process, click OK to propagate the accounts and display the Synchronization Manager message box shown in figure 17.48. Click Yes to remove the users and groups that weren't selected to be propagated from the NetWare server; click No to leave those users and groups on the NetWare server.

    
    17.48

    Synchronization Manager's message that the selected accounts have been propagated.

12. The Synchronization Manager appears, with the newly propagated NetWare server visible. Select that server and use the NetWare Server menu to manage the server (see fig. 17.49).

    
    17.49

    Synchronization Manager displaying the newly propagated NetWare server, allowing you to manage it.

Multi-Protocol Routing Service.

The Multi-Protocol Routing (MPR) Service (see fig. 17.50) allows a Windows NT server to provide a low-cost, software-based LAN-to-LAN routing solution, allowing small companies to avoid buying an expensive hardware router. The Microsoft MPR Service is analogous to and a direct replacement for the Novell Multi-Protocol Router. MPR is intended primarily for use by small organizations whose only server runs Windows NT Server, as well as by organizations that are replacing NetWare with Windows NT and need a software-based router to replace the Novell MPR.

17.50

The Multi-Protocol Routing Service providing software-based routing between a remote UNIX host and a remote NetWare server.

Windows NT Server provides standard software-based routing support for remote users via its Remote Access Service (RAS), as well as for local users running AppleTalk networks. The optional MPR Service extends this software-based routing support to provide enhanced support for IPX/SPX and TCP/IP networks.

Like other software-based routing products, MPR Service can be used to link networks into a WAN using dial-up or leased lines. Unlike some commercial products, MPR Service doesn't directly support dial-up links using an asynchronous serial port and modem. Instead, all communications links must be made using either NICs or communications support cards that emulate NICs. MPR Service supports a variety of such cards from several manufacturers. These cards can be used to establish links using frame relay, ISDN, x.25, and other telecommunications protocols. Check the latest version of the Windows NT Hardware Compatibility List before buying interface cards to use with MPR Service.

Companies of any size are likely to find Windows NT Server 4.0's MPR Service useful in the following ways:

• Used with an ISDN or frame-relay communications interface, MPR can provide an efficient, low-cost, and high-speed Internet gateway using your existing Windows NT Server.
• Used with one or more high-speed communications interfaces, MPR can provide an inexpensive method to connect branch office networks to the main network without requiring the purchase of expensive dedicated hardware routers for each end.

Integrating Windows NT Server with UNIX

UNIX, in one of its many variants, is commonly found as a host operating system in medium and large companies, often as an application server. Although Windows NT Server is an excellent application server platform, which may eventually supplant UNIX for that function in many organizations, you may need to provide client support for UNIX hosts on a temporary basis, if not permanently. If your organization uses UNIX as a client operating system, perhaps on engineering workstations, you might also be faced with providing client support to allow these UNIX workstations to access the Windows NT server.

Integrating UNIX and Windows NT Server means working with TCP/IP. Although Windows NT Server doesn't implement the full TCP/IP protocol suite, it does include both the basic TCP/IP protocol support and most of the TCP/IP utilities you need to allow Windows NT Server and UNIX to interoperate. You can use available third-party products to fill most of the gaps. Windows NT Server 4.0 includes the following core TCP/IP protocols, utilities, and services:

• Core protocols. TCP, IP, UDP, ARP, and ICMP. Remote Access Service (RAS) also provides SLIP and PPP support.
• Application interfaces. Winsock or Windows Sockets (based on the Berkeley Socket API), Remote Procedure Calls (RPCs), NetBIOS, and Network DDE.
• Basic Utilities. finger, ftp, lpr, rcp, rexec, rsh, telnet, and tftp.
• Diagnostic tools. arp, hostname, ipconfig, lpq, nbtstat, netstat, ping, route, and tracert (traceroute).
• Servers. ftp, lpd, snmp, chargen, daytime, discard, echo, quote, DHCP, and WINS.

The TCP/IP protocol suite evolves continuously. The TCP/IP standards are maintained and published primarily by the Internet Engineering Task Force (IETF). The actual standards documents, called Requests For Comments (RFCs), can be downloaded via the Internet from http://www.internic.net. It's crucial for any TCP/IP implementation to comply with the various RFCs if the implementation is to interoperate with other TCP/IP systems. Table 17.1 lists the RFCs to which the TCP/IP implementation supplied with Windows NT Server 4.0 adheres.

Table 17.1 InterNIC RFCs Supported by Windows NT Server 4.0

Windows NT Server Integration Tools for UNIX

Windows NT Server 4.0 provides two important tools for integrating Windows NT with UNIX:

• Dynamic Host Configuration Protocol (DHCP) allows IP addresses to be pooled and assigned as needed to clients. DHCP is an Internet standard protocol.
• Windows Internet Naming Service (WINS) maps easily remembered Windows machine names to the corresponding IP addresses. WINS is a Microsoft proprietary protocol.

Dynamic Host Configuration Protocol (DHCP).

One of the most labor-intensive and error-prone aspects of managing a TCP/IP network is assigning IP addresses to each host and workstation on the network. IP addresses must be unique. Unintentionally assigning the same IP address to two different computers can cause problems ranging from subtle workstation errors to a complete network crash. In the past, IP addresses had to be assigned manually, with all the difficulties that task implies. Installing a new workstation or relocating an existing one required that a technician make an on-site visit to configure the workstation with the appropriate IP address.

Windows NT Server greatly simplifies IP address management by using the Dynamic Host Configuration Protocol (DHCP). A DHCP server running on Windows NT Server is allocated a block of IP addresses, which are then available to be assigned automatically to workstations as needed. When a workstation running a DHCP client is booted, it requests an IP address from the DHCP server. The DHCP server assigns, or leases, an IP address to that workstation for the duration of its lease period, which is set by NTADMIN.

Using DHCP has the following advantages:

• The DHCP server allows centralized management of IP addressing information. If the DHCP server is set up properly, no address conflicts or TCP/IP configuration errors can occur on connected DHCP clients. Centralized management also means that your IP address management workload is greatly reduced.
• Because workstations are assigned an IP address at boot time, they can be moved freely from location to location without manually reconfiguring the IP address information each time a workstation is moved. This is a particularly useful feature as notebook computers become more prevalent, along with the need to simply plug them into whatever network port happens to be available without further ado.

If a workstation is removed and then reconnected to the same subnet before the lease period has expired, that workstation is assigned its previous IP address, based on the MAC (or hardware) address of the NIC. If the workstation is connected to a different subnet or to the same subnet after the lease period expires, the next available IP address is assigned to it.

The DHCP server is assigned a block of IP addresses, referred to as a DHCP scope. For example, if InterNIC assigns your company the IP C block ranging from 207.104.167.1 to 207.104.167.255, you might choose to subnet this block using a net mask of 224 into six subnets, each supporting 30 hosts. You might then assign the subnet containing the IP addresses 207.104.167.33 through 207.104.167.62 as your DHCP scope, keeping the other subnet addresses for other uses. These 30 available IP addresses can then be assigned to DHCP clients automatically as needed. In addition to the pooled addresses assigned on a first-come, first-served basis to DHCP clients, the DHCP server can reserve specific IP addresses for use by servers and other systems for which a static IP address is necessary or desirable.

See "IP Addresses," (Ch. 4)

If your routers support RFC 1542, which defines forwarding of BOOTP and DHCP broadcasts, only one DHCP server is required to support your entire IP internetwork. If they don't, a DHCP server can serve only DHCP clients located on the same IP subnetwork, and you'll need to install a DHCP server on each subnet for complete coverage of your internetwork.

To be assigned an IP address automatically by the DHCP server, each workstation must have DHCP client software installed and enabled. Windows NT Server and Workstation versions 3.5 and higher have DHCP clients built in, as does Windows 95. You can DHCP-enable Windows 3.11 for Workgroups by installing Win32s and the Microsoft 32-bit TCP/IP VxD supplied with the Windows NT Server CD-ROM. DOS workstations can use DHCP if you install the Microsoft Network Client for MS-DOS 3.0 or higher real-mode TCP/IP driver supplied on the Windows NT Server distribution CD-ROM.

Non-DHCP clients can coexist on the same network with DHCP clients and can use TCP/IP and Windows networking services, but at the expense of requiring some manual intervention. IP addresses for non-DHCP clients must be assigned manually in the old manner, and IP addresses so assigned must be excluded from the DHCP scope to avoid duplication of IP address assignment.

Installing Dynamic Host Configuration Protocol (DHCP).

To install DHCP, follow these steps:

1. From Control Panel, double-click the Network tool to display the Network property sheet. Click the Services tab, and then click Add to display the Select Network Service dialog.
2. Select Microsoft DHCP Server and click OK to begin installing DHCP.
3. The Windows NT Setup dialog prompts you for the location of the DHCP distribution files. Enter the location and click Continue to begin copying the files. Windows NT displays a message saying that any adapters now using DHCP must be assigned a static IP address (see fig. 17.51). Click OK to continue.

   
   17.51

   The warning that adapters now using DHCP must be assigned a static IP address before installation can proceed.

4. Windows NT displays the Network property sheet, shown in figure 17.52 with DHCP installed. Click Close to complete the installation of DHCP.

   
   17.52

The Services page of the Network property sheet, with the Microsoft DHCP Server installed.

Windows NT Server analyzes the changes you've made to your network configuration. It first configures the bindings, then stores the bindings, and finally reviews the new bindings configuration.

Configuring and Managing DHCP.

After you install DHCP, follow these steps to configure it:

1. From the Start menu, choose Programs, Administrative Tools, and then DHCP Manager to run the DHCP Manager (see fig. 17.53).

   
   17.53

   Using the DHCP Manager to configure and manage DHCP.

2. From the Scope menu choose Create to display the Create Scope dialog (see fig. 17.54). Enter the range of IP addresses you want to comprise the scope. You can exclude specific addresses and ranges of addresses from the scope. Specify the lease duration as either Unlimited or as Limited to a specific number of Days, Hours, and Minutes.

   
   17.54

   Entering a range of IP addresses to comprise the DHCP scope and configuring DHCP lease durations.

   

   It's a good idea in general-and in particular if the demand for IP addresses in your organization outstrips the supply-to limit the DHCP lease duration to a reasonable time to prevent an idle client from holding an unused IP address. Many organizations find that two or three days is reasonable, although if IP addresses are in short supply, setting this parameter to one day or less is acceptable. Avoid setting it to too short a period, or clients will constantly be "churning" IP addresses.

   

3. After you complete all fields in the Create Scope dialog, click OK. In the DHCP Manager message box that appears (see fig. 17.55), click No to leave the DHCP scope inactive, or Yes to activate the newly defined DHCP scope. When the scope is activated, the newly defined scope appears in DHCP Manager (see fig. 17.56). When you're finished adding DHCP scopes, close DHCP Manager.

   
   17.55

   The DHCP Manager message that lets you activate your newly defined DHCP scope.

   
   17.56

   DHCP Manager displaying the newly defined scope.

Windows Internet Naming Service (WINS).

A Windows NT Server running TCP/IP and the Windows Internet Name Service (WINS) server software is called a WINS server. A WINS server provides a lookup table to map computer names to IP addresses, allowing users to refer to another computer by its easily remembered name rather than by its numeric IP address. In the Windows NT environment, WINS provides a service analogous to the use of Domain Name Service (DNS) in the Internet Protocol suite. WINS uses NetBIOS over TCP/IP, defined in RFC 1001 and RFC 1002 as p-node.

Using WINS offers the following advantages:

• Simplified management. The WINS server maintains a dynamic lookup table to map computer names to Internet addresses, allowing centralized management of this information. The alternative-maintaining static LMHOSTS files on each client-requires a great deal of manual intervention. Each client must be altered individually each time a host is to be added or an address changed. WINS also centrally manages replication of WINS data, eliminating the need to copy changed host files to multiple servers.
• Reduced network traffic. The data maintained by the WINS server allows a client to perform a single lookup to resolve the IP address of a destination computer, greatly reducing IP broadcast traffic that would be transmitted on the network in the absence of WINS or another address resolution method.
• NetBIOS support. DNS provides address resolution services only to IP clients. WINS supports NetBIOS clients as well.
• WAN support. According to Microsoft, clients on a LAN with a WINS server present can browse domains located beyond the boundary router, even if the destination domain has no local domain controller present. (The prerelease version of Windows NT Server 4.0 used to write this book didn't support the feature.)

The WINS Server software is bundled with Windows NT Server. Installing the WINS Server software is described in the following section.

To use WINS server services, a client must first have WINS software installed. Windows NT Workstation and Windows 95 are both supplied standard with a WINS client, as is the Microsoft Windows client software provided with the Windows NT Server distribution. Clients running Windows 3.11 for Workgroups can use the WINS client software supplied with the TCP/IP add-on for Windows 3.11 for Workgroups, available as TCP32B.EXE from the Microsoft Download Service (206-936-6735) or via Internet anonymous FTP from ftp.microsoft.com. Although DOS workstations can participate in WINS, equipping them to do so requires buying the Workgroup Add-On for DOS from Microsoft.

Installing Windows Internet Naming Service (WINS).

To install WINS, take the following steps:

1. From Control Panel, double-click the Network tool to display the Network property sheet. Click the Services tab, and then click Add to display the Select Network Service dialog.
2. Select Windows Internet Name Service and click OK to display the Windows NT Setup dialog. Type the location of the files and click Continue to copy the files.
3. After all files are copied, Windows NT returns you to the Network property sheet, showing Windows Internet Name Service installed (see fig. 17.57). Click Close to continue the installation process.

   
   17.57

   The Services page of the Network property sheet, showing Windows Internet Name Service installed.

4. Windows NT Server analyzes the changes you've made to your network configuration. It first configures the bindings, then stores the bindings, and finally reviews the new bindings configuration. When this process is complete, the Network Settings Change dialog notifies you that you must restart your computer for the changes to take effect.

Configuring and Managing WINS.

After you install WINS, follow these steps to configure it:

1. From the Start menu, choose Programs, Administrative Tools, and then WINS Manager to run WINS Manager (see fig. 17.58).

   
   17.58

   The opening window of WINS Manager.

2. From the Server menu choose Configuration to display the WINS Server Configuration dialog (see fig. 17.59).

   
   17.59

   The WINS Server Configuration dialog.

3. Set WINS configuration parameters as follows:
   • Renewal Interval specifies how frequently a client re-registers its name. Keep this value set to 4 days or more to minimize network traffic and the load on the WINS server.
   • Extinction Interval specifies what period must elapse between the time that an entry is marked as released (available for reuse) and the time it's marked as extinct (marked for deletion from the WINS database).
   • Extinction Timeout specifies what period must elapse between the time that an entry is marked as extinct and the time that it's actually scavenged from the database. The maximum permissible value is 4 days.
   • Verify Interval specifies the period after which the WINS server must verify that old names not owned by that server are still active. The maximum permissible value is 24 days.
   • In the Pull Parameters section, the Initial Replication check box, if marked, causes the WINS server to pull replica information from partner WINS servers when WINS is initialized, or when a replication parameter is changed. The Retry Count spinner box specifies how many retries will be made to pull the replica.
   • In the Push Parameters section, the Initial Replication check box, if marked, causes this WINS server, when initialized, to notify its partner WINS servers of database status. The Replicate on Address Change check box, if marked, causes this WINS server to notify its partner WINS servers when an address changes in its database.
4. After you set the parameters in the WINS Server Configuration dialog, choose Advanced to expand the dialog to display the Advanced WINS Server Configuration items (see fig. 17.60).

   
   17.60

   The advanced options of the WINS Server Configuration dialog.

5. Set the advanced WINS configuration parameters as follows:
   • The Logging Enabled check box, if marked, causes the WINS server to log database changes to the JET.LOG file.
   • The Log Detailed Events check box, if marked, causes this WINS server to record full detail to the log file. Marking this box can result in substantial performance degradation on your server.
   • The Replicate Only With Partners check box, if marked, causes this WINS server to perform push and pull database replication functions only with partner WINS servers.
   • The Backup On Termination check box, if marked, causes this WINS server to back up the WINS database when the WINS service is stopped, except when the server itself is shut down.
   • The Migrate On/Off check box, if marked, causes this WINS server to treat static records in its database as dynamic when these static records conflict with information received from a new registration or a replication from a partner WINS server. Mark this check box if you're upgrading to Windows NT on systems that previously ran another operating system.
   • The Starting Version Count (Hex) box specifies the highest version ID number (in hexadecimal) for the WINS database. Increase this value if your WINS database becomes corrupted. If this WINS server is partnered with other WINS servers, use a value higher than the version number associated with replicas of this WINS server database on the partner servers.
   • The Database Backup Path text box allows you to enter or browse for a drive and path where the backup copy of the WINS database is to be stored. Specify a local server drive rather than a network connection for this item. If you enter a valid path here, WINS automatically backs up its database to this location every three hours. When WINS is started, it verifies the integrity of its database. If it finds that the database is corrupted, WINS restores the database from this location.
6. After you complete all fields, click OK to close the WINS Server Configuration dialog. When you're finished configuring WINS, close the WINS Manager.

Sharing Windows NT Files with UNIX

The Windows NT TCP/IP core protocols and utilities provide only FTP as a means to share files between Windows NT and a UNIX or other TCP/IP host. Windows NT Server implements FTP in both client and server versions. Similarly, virtually every UNIX implementation includes both an FTP client and an FTP server. It's common, however, for workstations running operating systems other than UNIX to have only FTP client software.

Although FTP is the primary method for copying files between TCP/IP hosts, problems can occur when transferring files between systems with dissimilar file systems. The FTP protocol has built-in translation schemes that work well for common text and unstructured binary files. However, some systems, such as minicomputers and mainframes, have complex file systems and use file formats that might not successfully transfer between unlike systems.

Although FTP can be used to copy files between UNIX and Windows NT Server hosts, this manual process does nothing to provide a shared file system between the hosts. Clearly, something more is needed if Windows clients are to have real-time access to files stored on a UNIX host. Three methods are available for such access:

• Network File System (NFS), a Sun Microsystems product, is complicated to administer and requires that you buy additional software for your Windows NT server. NFS, however, does provide bi-directional access, allowing UNIX clients to access files stored on a Windows NT server as well as allow Microsoft clients to access files stored on UNIX hosts.
• Microsoft LAN Manager for UNIX (LMU) adds the protocol support needed to allow UNIX hosts to participate in Microsoft Networking using the SMB protocol. Using LMU adds another complex product to administer, and LMU is relatively expensive.
• SAMBA is a free product that runs on your UNIX host, allowing it to emulate a Microsoft LAN Manager server. Microsoft clients see a UNIX host running SAMBA as just another Microsoft Networking server and can access files stored on the UNIX file system as though the files were located on an actual Microsoft Networking server. SAMBA is essentially unidirectional, however, and provides only limited batch-mode access using SMBCLIENT for UNIX clients to files that reside on a Windows NT Server volume. The SAMBA home page is located at http://lake.canberra.edu.au/pub/samba/samba.html.

Network File System.

Sun Microsystems, a leading supplier of UNIX workstations and servers, developed the NFS specification and published it in RFC 1094. NFS is now the de facto file server protocol implemented on UNIX systems. Since its original inception, NFS has evolved into NFS version 3 as detailed in RFC 1813. The NFS architecture is designed to be independent of the operating system, file system, and transport protocol used. NFS is built on top of the Remote Procedure Call (RPC) API described in RFC 1057. RPC, an interprocess network messaging protocol, allows networking software developers to port NFS to a wide variety of hardware platforms and operating system environments.

NFS, like FTP, is a client/server protocol. Unlike FTP, NFS provides transparent shared access to remote files across a network. A primary design consideration of an NFS server is to have the minimum possible impact on the host machine. In contrast to a NetWare server, an NFS server uses stateless protocols. (Stateless means that an NFS server maintains no information about the NFS clients it serves.) The NFS protocol burdens the client with maintaining the connection to the NFS server and also requires that the client ensure the integrity of the transactions. If, for example, an NFS server crashes, the NFS client must remount the shared files after the NFS server is rebooted.

Microsoft doesn't supply NFS software for Windows NT Server. Several third-party NFS products are available from companies such as Hummingbird Communications, Intergraph, NetManage, and Process Software. These and other NFS products provide NFS services only to the Windows NT host. Windows NT Server clients can't access NFS imported file systems unless NFS software is first installed on the individual clients.

Using Microsoft LAN Manager for UNIX to Add Microsoft Networking Support to UNIX Hosts.

LMU allows UNIX hosts to participate in a Microsoft Networking environment. Microsoft licensed LMU to AT&T, which has in turn relicensed LMU to other UNIX vendors. LMU implementations are available for different varieties of UNIX, both directly from UNIX vendors (for example, SCO Microsoft LAN Manager for SCO Systems) and from third-party vendors (for example, Unipress Software Microsoft LAN Manager for UNIX).

LMU adds support for the SMB protocol to UNIX hosts. The SMB protocol, developed by Microsoft, IBM, and Intel, is the foundation used for interoperability by all Microsoft Networking products. SMB corresponds in function to the NetWare Core Protocol (NCP) used by Novell NetWare. In addition to Windows NT Server, LMU is compatible with Microsoft OS/2 LAN Manager, Microsoft Windows for Workgroups, IBM LAN Server, MS-DOS LAN Manager, DEC PATHWORKS, 3Com 3+Open, and MS-NET.

Installing the SMB protocol on a UNIX host allows interoperability between UNIX and Windows NT Server and its clients. It's possible to install LMU on just one UNIX host, which then shares NFS imported file systems with a Windows NT server and its clients. This process incurs additional overhead for the NFS-to-SMB gateway and slows performance, although doing so may be a cost-effective alternative to buying multiple copies of LMU for lightly accessed UNIX hosts.

Using SAMBA to Allow UNIX Hosts to Emulate Windows NT Server.

An alternative to purchasing LMU is to install the freely available SMB software SAMBA. Installing the SAMBA suite of programs on your UNIX host allows your Microsoft Networking clients to access UNIX files and printers as though they were resources on a Windows NT server. Originally developed by Andrew Tridgell, SAMBA has since been enhanced and extended using input from "net gurus" all over the world. SAMBA includes the following major components:

• smbd is the SMB server itself, which provides the core SMB support needed to handle client connections.
• smbclient is the client program run on the UNIX host.
• smb.conf is the SAMBA configuration file.
• nmbd is the NetBIOS name server, used to allow clients to locate servers.

SAMBA is officially supplied in source code form only, although user-contributed compiled versions (binaries) for most UNIX platforms can be found on the Internet. SAMBA is freely modifiable and may be distributed under the GPL. Make files are available for compiling binaries for a large number of UNIX variants, detailed in table 17.2. SAMBA source code can be downloaded via anonymous FTP from nimbus.anu.edu.au, in the directory /pub/tridge/samba.

Table 17.2 SAMBA-Supported UNIX Implementations

Building Universal Clients for Microsoft Windows NT, Novell NetWare, and UNIX

As this chapter demonstrates, PCs running Microsoft client software can be provided with access to NetWare server resources, but with some limitations. Similarly, workstations running Novell NetWare client software can be provided with access to Windows NT Server resources by running the GSNW or the File and Print Service for NetWare on your Windows NT server. Here again, some restrictions apply, particularly for those who run NetWare 4.x servers.

The explosion of the Internet and of the use of TCP/IP for internetworking also makes TCP/IP client support very desirable. As a result, what many organizations need is a standardized PC client software configuration that simultaneously provides full support for Windows NT Server, NetWare, and UNIX, and does so with a high degree of stability while consuming minimum conventional workstation memory.

As discussed in Chapter 10, "Configuring Windows 95 Clients for Networking," using Windows 95 as your client operating system minimizes or eliminates the problems of dealing with base memory limitations. Windows 95 used with a supported NIC provides protocol support and redirection services using 32-bit drivers, which eliminate the base memory footprint while providing client services for Microsoft Networking, NetWare, and TCP/IP. Although Windows 95 as shipped doesn't support NDS on NetWare 4.x servers, both Microsoft and Novell have 32-bit client software that does support NDS available for free downloading via the Internet, MSL, or NetWire.

Another alternative is to use more than one redirector or shell with multiple protocol stacks on the clients. NetWare and Windows NT Server both support DOS, Windows, Windows for Workgroups, Windows 95, Windows NT, OS/2, and Macintosh clients. Some NetWare system managers have an almost religious aversion to implementing multiple protocol stacks on their client workstations, let alone multiple redirectors.

These NetWare administrators had good reason to be wary in the past. The 640K limitation on base memory inherent to Intel-based PCs running in real mode made for a tight fit. When DOS, the network protocol drivers, and the NetWare shell were loaded, often not enough memory was left to run large applications, let alone enough to consider adding one or more additional protocol stacks and network shells. Modern client operating systems such as MS-DOS 6.x, Windows 3.11 for Workgroups, and Windows 95 have dramatically simplified the problem of cramming the network software into base memory and have made running dual protocol stacks and redirectors a realistic alternative.

The quest for such a universal client continues, and a perfect solution doesn't yet exist. If, however, like most LAN administrators, you find that most of your clients are running Windows 3.11 for Workgroups or Windows 95, it's straightforward to configure either of these client operating systems to provide simultaneous support for Windows NT Server, TCP/IP, and NetWare.

Configuring Windows 3.11 for Workgroups as a Universal Client

Windows 3.11 for Workgroups provides native networking support only for Windows Networking. It can, however, be used as a foundation on which to build a universal network client using inexpensive or free utilities for TCP/IP and NetWare connectivity. Configuring Windows 3.11 for Workgroups as a universal client requires the following:

• Windows Networking support enabled within Windows 3.11 for Workgroups.
• NetWare support provided by installing the ODI drivers and NetWare client software available from Novell, and then enabling NetWare support within Windows 3.11 for Workgroups.
• TCP/IP support provided by installing a Winsock-compliant stack, available from Microsoft or third parties.
• Windows Packet Driver support provided by installing ODIPKT.COM and WINPKT.COM, available via anonymous FTP from ftp.cica.indiana.edu in the /pub/pc/win3/winsock directory.

Installing Windows Network Support.

Installing Windows Networking support for Windows 3.11 for Workgroups is fully described in Chapter 11, "Connecting Other PC Clients to the Network."

Remember that although Windows 3.11 for Workgroups provides the client software needed to access your Windows NT Server, you must still purchase a client access license for each computer that does so.

Installing Novell NetWare Support.

To add support for NetWare, use the client software provided by Novell. The client software, packaged as several self-extracting archive files named VLMKIT*.EXE, can be downloaded via Internet anonymous FTP from ftp.novell.com or from the CompuServe NetWire forum, or can be purchased on disk directly from Novell. The VLM client software is free if your Novell server is version 3.12 or higher. It's available at a nominal charge for those using NetWare 3.11 servers.

Installing TCP/IP Support.

Adding a TCP/IP protocol stack to Windows 3.11 for Workgroups is done by installing software written to the Windows Sockets specification, commonly referred to as Winsock. Following are some Winsock implementations available from various sources, ranging in cost from free to quite expensive:

• Microsoft distributes a free Winsock implementation for Windows for Workgroups in an archive named TCPIP32B.EXE, which can be downloaded from the Microsoft Download Service (206-936-6735) or via anonymous FTP at ftp.microsoft.com. Earlier versions of this product experienced compatibility and stability problems, but the version now posted for download works reliably. Microsoft's Winsock implementation is unique in its support for both DHCP and Microsoft Networking over TCP/IP.
• Various inexpensive shareware Winsock implementations-most notably, Peter Tattam's Trumpet Winsock-can be downloaded via anonymous FTP at ftp.trumpet.com.au in the /ftp/pub/winsock directory, as well as from many BBSs. These shareware implementations vary widely in quality, features, and bundled applications. The best of them, like Trumpet, are both inexpensive-at $20 a seat or so-and reliable.
• Many commercial Winsock implementations are available, although this market appears to be rapidly shrinking due both to the availability of inexpensive shareware versions and the bundling of TCP/IP support in Windows 95. Commercial Winsock vendors have tried to fight back by bundling various TCP/IP applications with their products-FTP clients, newsreaders, and so forth-but better applications are available for free on the Internet, and these products remain expensive at $50 to $200 per seat.

Pick one Winsock implementation and use it for all your Windows 3.11 for Workgroups clients. There's seldom any reason to look further than Microsoft's free Winsock software. Consider Trumpet Winsock and similar products only if you need telephone dialer support. Consider commercial Winsock implementations only if you need specialized features not available with the free or inexpensive products.

Installing Packet Driver Support.

The next step is to install packet driver support to enable the ODI NIC drivers and Windows itself to handle packets properly. Two programs are universally used to provide these functions in Windows 3.1x installations: ODIPKT handles the ODI packet interface tasks, and WINPKT allows handles the Windows packet interface duties.

ODIPKT.

ODIPKT is used to provide packet driver support to the Novell ODI NIC drivers. The current version of ODIPKT.COM can be downloaded via anonymous FTP from ftp://hsdndev.harvard.edu/pub/odipkt/odipkt.com or from any Web site or BBS that has a Winsock area.

ODIPKT allows a single NIC running ODI to service multiple packet driver protocol stacks, including IPX/SPX and TCP/IP. ODIPKT supports Ethernet, Token Ring, and ARCnet frames.

ODI supports multiple frame types simultaneously on a single physical NIC. Because the frame types typically used with NetWare to transport IPX/SPX packets aren't appropriate to transport TCP/IP packets, it's common to see a single NIC in a NetWare workstation bound to two frame types, such as Ethernet II for TCP/IP, and Novell Ethernet 802.3 or 802.2 for IPX/SPX. One or more frame types are specified for each physical NIC in the NET.CFG file. Each frame type is seen by ODI as a separate logical NIC. The following NET.CFG fragment illustrates a typical configuration:

Link Driver NE2000
port 300
int 10
FRAME Ethernet_II
FRAME Ethernet_802.3

The first three lines name the link driver and specify that the physical Ethernet card is located at address 300 and interrupt 10. The final two lines bind the Ethernet_II frame type appropriate for UNIX as logical board 0 and the Ethernet_802.3 frame type used for IPX/SPX as logical board 1.

ODIPKT depends on buffers supplied by the ODI link support layer (LSL). Make sure that your NET.CFG specifies enough buffers of a size large enough to support your NIC. For example, using 1,514-byte Ethernet frames on a NIC that supports multiple buffers, your NET.CFG may contain the following:

Link Support
          BUFFERS 2 1600

This instructs LSL to reserve two buffers, each of 1,600 bytes.

ODIPKT.COM is typically loaded by STARTNET.BAT and requires only two command-line arguments. The first specifies the logical board number; the second specifies the software interrupt, or vector, to be used, which is specified as a decimal number. A typical STARTNET.BAT fragment might look something like the following:

lsl
3c5x9
odipkt 0 96
winpkt 0x60
ipxodi
vlm /mx

The first line loads the LSL portion of ODI. The second loads the packet driver version of the 3Com 3C509 Multiple Link Interface Driver (MLID). The third loads ODIPKT to support logical board 0 using software interrupt 96 decimal. The fourth line loads WINPKT (described in the following section) and specifies software interrupt 0x60 hexadecimal. (Note that 96 decimal corresponds to 0x60 hexadecimal.) The fifth line loads IPX support for NetWare, and the sixth line loads the NetWare VLM client software into extended memory. ODIPKT must be loaded after LSL.COM and the MLID, but it must be loaded before WINPKT.

WINPKT.

WINPKT is a shim that provides packet support for Windows. The current version of WINPKT.COM can be downloaded via Internet anonymous FTP from ftp.cica.indiana.edu in the /pub/pc/win3/winsock directory, or from any Web site or BBS that has a Winsock area.

WINPKT takes only one command-line argument, which is the software interrupt used by ODIPKT. Make sure that both ODIPKT and WINPKT are using the same software interrupt.

ODIPKT uses decimal notation and WINPKT uses hexadecimal notation.

Using Windows 95 as a Universal Client

Windows 95 is an ideal universal network client. Used with a supported NIC, Windows 95 can provide simultaneous connectivity to Windows NT Server, NetWare, UNIX, and SNA servers, using supplied 32-bit drivers and occupying nearly no conventional memory. The only drawback to using Windows 95 as a client is that, as shipped, the NetWare client software doesn't support NDS. When this book was written, beta versions of 32-bit NetWare drivers with NDS support were available from both Microsoft and Novell. For full information on how to configure Windows 95 as a universal network client, see Chapter 10, "Configuring Windows 95 Clients for Networking."

Although Windows 95 provides client functionality for Windows NT Server, you must purchase a client access license for each computer that uses Windows 95 to access your Windows NT server.

Integrating Windows NT in IBM SNA Environments

Windows NT is bundled with the Data Link Control (DLC) protocol that allows communication with IBM SNA machines and other network devices, such as Hewlett-Packard laser printers with network interfaces. The Windows NT DLC protocol binds with either a Token Ring interface card (TIC) or an Ethernet NIC that supports the Ethernet Version 2 (DIX) framing format.

The order of the bindings section when installing the DLC protocol is very important. If you have more than one NIC (Windows NT supports up to 16), you must ensure that the DLC protocol is bound to the appropriate NIC. By default, the DLC protocol binds to adapter number 0, the first network adapter installed into the system.

The DLC protocol provides the foundations for communication with SNA mainframes and midrange hosts, such as an IBM AS/400. The DLC protocol supports SNA LLC type 2 and type 1 frames. Windows NT doesn't include any user applications that utilize the DLC protocol. Third-party SNA products, such as Wall Data's Rumba for Windows NT, works with the DLC protocol to provide IBM 3270 terminal emulation to a Windows NT system. Rumba is one of the few third-party SNA products that doesn't require the SNA Server for Windows NT.

SNA Server for Windows NT, a component of the Microsoft BackOffice suite, is sold separately from Windows NT Server. Unlike Rumba's relatively simple terminal emulation, SNA Server for Windows NT provides a client/server architecture that allows as many as 2,000 users, or clients, to have 10,000 simultaneous connections to 250 different SNA hosts.

SNA Server for Windows NT provides Windows NT, Windows 95, Windows 3.x, MS-DOS, OS/2, and MAC clients 3,270 and 5,250 terminal and printer emulation, file transfer, and Emulator High Level Language (EHLLAPI) sessions on SNA Hosts. SNA Server for Windows NT also supports the following SNA APIs and protocols:

• Advanced Program to Program Communications (APPC) using the LU 6.2 protocol
• Common Programming Interface for Communications (CPI-C) using the LU 6.2 protocol
• Common Service Verbs (CSV) as defined by the NetView API
• Logical Unit APIs (LUA) using either LUA/Request Unit Interface or LUA/Session Level Interface over LU 0, 1, 2 & 3

Microsoft SNA Server is the only system on the network that uses the SNA protocols. Client systems can run Microsoft Networking (SMB), IPX/SPX, Vines, AppleTalk, or TCP/IP to communicate with SNA Server that translates the communication to the SNA host or hosts.

SNA Server also provides a platform for third-party vendors to develop SNA-based applications for both the clients and the SNA Server for Windows NT.

Migrating from Novell NetWare to Windows NT Server

Windows NT Server includes a superb set of tools to help it coexist with Novell NetWare servers, but Microsoft wants you to replace your NetWare servers with servers running Windows NT. Having seen other NOSs, including some of their own earlier efforts, fall by the wayside as a result of trying to compete head-on with NetWare, Microsoft wisely has avoided attempting the brute-force method with Windows NT Server 4.0. Instead, Microsoft has cleverly positioned Windows NT Server 4.0 as a product that easily coexists with NetWare.

Few independent analysts question that Windows NT Server 4.0 is an even match for NetWare 4.1. Although Novell continues to trumpet the advantages of its NetWare Directory Services over the domain-based directory services model used by Windows NT Server, the reality is that either method works well for most organizations. Also, the method by which Windows NT Server provides application server functions is recognized by most observers as being superior both in concept and in execution to the NLM-based method used by Novell.

What has kept other NOSs, some with unquestionable advantages, from replacing NetWare on a wholesale basis is NetWare's installed base. No one seriously questions that NetWare 3.1x is an obsolescent NOS, eclipsed in power and features by Windows NT Server and other modern NOSs, including NetWare 4.x. Yet the fact remains that only recently have new shipments of NetWare 4.x licenses exceeded those of new NetWare 3.12 licenses. The installed NetWare 3.1x base predominates and is expected to continue its dominant role for some time to come. Even NetWare 2.x has a substantial and continuing presence.

The reason for the continuing dominance of earlier versions of NetWare is quite simple. Like an old shoe, NetWare 2.x/3.x is comfortable. For every NetWare 4.x expert available, a dozen technicians and consultants know the earlier versions of NetWare inside and out. For every true Windows NT Server expert, you find perhaps 100 NetWare gurus. Although this situation is starting to change, many network administrators still find comfort in using the old familiar NetWare 2.x/3.1x.

Recognizing this inertia factor, Microsoft has taken an intelligent approach by positioning Windows NT Server as a product that can coexist peacefully in a NetWare shop and do useful things well that NetWare does poorly or not at all. This guerrilla marketing strategy is beginning to pay off, as LAN administrators, bringing up their first Windows NT Server, quickly realize that Windows NT Server was never anything to be afraid of in the first place.

Whether you plan incremental replacement of NetWare servers with Windows NT Server 4.0, wholesale replacement, or simply continuing coexistence, you should become familiar with the Microsoft Migration Tool for NetWare (see fig. 17.61). This tool automates the process of moving files, directories, file attribute and rights, and user and group account information from an existing NetWare server to a Windows NT server. A basic version of this tool is bundled with Windows NT Server itself. A more advanced, full-function version is included with the optional File and Print Service for NetWare. If you plan to do a migration, do yourself a favor and buy File and Print Service for NetWare to get the advanced version. Its capability to migrate logon scripts alone is worth the $100 price of the File and Print Service for NetWare product.

17.61

The Migration Tool for NetWare, which allows you to migrate Novell NetWare users and groups to Windows NT Server.

The Migration Tool for NetWare can be used in several ways. Following are some of the things you can do:

• Migrate the contents of a single NetWare server to a single Windows NT server
• Migrate the contents of two or more NetWare servers to a single Windows NT server, combining and merging the contents of the NetWare servers during the process
• Migrate the contents of two or more NetWare servers to two or more Windows NT servers, relocating and distributing the contents of the NetWare servers as you choose among the Windows NT servers

Using the Migration Tool for NetWare results in no changes whatsoever to the NetWare server and can be done without taking down either the NetWare server or the Windows NT server. All services on both the NetWare server and the Windows NT server continue to be available to users during the migration process.

The Migration Tool for NetWare offers the option to do a trial migration, allowing you to test the results of a migration before actually making any changes to either server. Potential conflicts, such as duplicate user names, are highlighted during this trial migration process, allowing you to resolve them before doing the actual migration.

From Here...

If you're integrating Windows NT Server 4.0 into an existing PC network, the odds are that your present network is running Novell NetWare. Thus, the first part of this chapter covered Windows NT's Gateway Services for NetWare, File and Print Services for NetWare, and Directory Services Manager for NetWare. UNIX networks running TCP/IP are commonly used by medium- to large-sized firms, so a substantial part of this chapter was devoted to integrating Windows NT 4.0 with UNIX networks. The chapter closed with detailed recommendations for creating universal Windows 3.1+ and Windows 95 clients for Microsoft Windows NT, NetWare, and UNIX networking, as well as a brief discussion of integration with IBM SNA networks and migrating from NetWare to Windows NT networking.

The following chapters contain information related to the content of this chapter:

• Chapter 4, "Choosing Network Protocols," explains how to select one or more of the three principal networking protocols supported by Windows NT based on your network configuration.
• Chapter 10, "Configuring Windows 95 Clients for Networking," shows you how to set up PCs running Windows 95 to take maximum advantage of Windows NT 4.0 networks, including the use of server-based desktop configurations and policies.
• Chapter 11, "Connecting Other PC Clients to the Network," provides the details on setting up Windows 3.1+, Windows for Workgroups 3.1+, Windows NT Workstation 4.0, and Macintosh clients to communicate with Windows NT 4.0 servers.

DISCLAIMER

© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.