In this chapter, you learn how to
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.
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.
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.
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:
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.
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).
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:
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.
Clients running Microsoft Networking client software can access shared files and printers on a Novell NetWare server in one of the following three ways:
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.
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."
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:
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:
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:
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.
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.
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:
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:
Using Novell's SYSCON.EXE to prepare the NetWare 3.1x server for the Gateway Service for NetWare.
Creating the NetWare group NTGATEWAY and granting all file, directory, and printer rights to be shared.
Creating a supervisor equivalent user for system maintenance and to run NetWare utilities.
Creating NetWare user accounts for shared access to the NetWare server, and assigning them to the NTGATEWAY group.
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:
Displaying installed Network Services in the Network property sheet.
Selecting Gateway (and Client) Services for NetWare in the Select Network Service dialog.
Specifying the location of the Gateway Service for NetWare distribution files in the Windows NT Setup dialog.
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)
The Network property sheet displaying Gateway Service for NetWare as an installed network service.
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.
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:
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:
Setting the preferred server and other options in the Gateway Service for NetWare dialog.
Enabling the gateway and entering account name and password information in the Configure Gateway dialog.
Entering a share name, specifying the associated network path, and designating a drive letter by which the share can be accessed.
The completed Configure Gateway dialog, showing the newly created share.
See "Working with Share Permissions," (Ch. 13)
Assigning permissions for the newly created share in the Access Through Share Permissions dialog.
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:
Setting up a shared network printer with the Add Printer Wizard.
See "Configuring Locally Attached Server Printers as Shared Resources," (Ch 13)
Displaying available print queues for a Windows NT server.
Specifying that the printer won't be the default printer for Windows applications.
The Add Printer Wizard's final step in adding a print queue for a NetWare printer.
See "Sharing and Securing Network Printers,"(Ch. 13)
Specifying a Share Name for the printer.
Microsoft Networking clients now see the shared NetWare printer as they would any shared printer available on the Windows NT server.
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.
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.
To install File and Print Services for NetWare (FPNW), follow these steps:
Installing File and Print Services for NetWare from the distribution diskette.
Specifying volume location, supervisor account information, and performance tuning in the Install File and Print Services for NetWare dialog.
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.
Entering the password for the account to be used to run File and Print Services for NetWare.
The Network property sheet, displaying File and Print Services for NetWare as an installed network service.
The NWLink IPX/SPX Properties sheet's General page, which allows you to specify protocol properties for each adapter.
Enabling IPX/SPX RIP routing on the Routing page of the NWLink IPX/SPX Properties sheet.
The NWLink IPX/SPX message box that warns you that the internal network number is invalid.
The random internal network number generated by Windows NT Server.
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:
Displaying statistics and configuration parameters for the FPNW gateway in the File and Print Services for NetWare on Servername dialog.
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:
Displaying user statistics and managing users with the Users on Servername dialog.
Displaying volume statistics and managing volumes in the Volumes Usage on Servername dialog.
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.
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.
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.
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).
Creating a single network logon for NetWare clients across two Windows NT domains.
To install Directory Service Manager for NetWare, follow these steps:
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.
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.
Entering and confirming the password for the account to be used for DSNW.
The Network property sheet displaying DSMN as an installed network service.
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.
The initial status of DSMN's Synchronization Manager.
Displaying available NetWare servers in the Select NetWare Server dialog.
Specifying a user name in the Connect to NetWare Server dialog.
The default NetWare users and groups propagated to Windows NT Server by DSMN synchronization.
Specifying changes to the default settings of the Propagate NetWare Accounts to Windows NT Domain dialog.
The Synchronization Manager's message after a trial run succeeds.
Displaying the trial run log file in Notepad.
Synchronization Manager's warning to back up your NetWare bindery before proceeding.
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.
Synchronization Manager's message that the selected accounts have been propagated.
Synchronization Manager displaying the newly propagated NetWare server, allowing you to manage it.
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.
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:
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:
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
RFC | Title | RFC | Title |
0768 | User Datagram Protocol | 1122 | Requirements for Internet Hosts-Communication Layers |
0783 | TFTP Protocol Revision 2 | 1123 | Requirements for Internet Hosts-Application and Support |
0791 | Internet Protocol | 1134 | Point-to-Point Protocol: A Proposal for Multi-Protocol Transmission of Datagrams over Point-to-Point Links |
0792 | Internet Control Message Protocol | 1144 | Compressing TCP/IP Headers for Low-Speed Serial Links |
0793 | Transmission Control Protocol | 1157 | A Simple Network Management Protocol (SNMP) |
0826 | Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48-bit Ethernet Address for Transmission on Ethernet Hardware | 1179 | Line Printer Daemon Protocol |
0854 | Telnet Protocol Specification | 1188 | A Proposed Standard for the Transmission of IP Datagrams over FDDI Networks |
0862 | Echo Protocol | 1191 | Path MTU Discovery |
0863 | Discard Protocol | 1201 | Transmitting IP Traffic over ARCNET Networks |
0864 | Character Generator Protocol | 1231 | IEEE 802.5 Token Ring MIB |
0867 | Daytime Protocol | 1334 | PPP Authentication Protocols |
0894 | Standard for theTransmission of IP Datagrams over Ethernet Networks | 1533 | DHCP Options and BOOTP Vendor Extensions |
0919 | Broadcasting Internet Datagrams | 1534 | Interoperation Between DHCP and BOOTP |
0922 | Broadcasting Internet Datagrams in the Presence of Subnets | 1541 | Dynamic Host Configuration Protocol |
0959 | File Transfer Protocol | 1542 | Clarifications and Extensions for the Bootstrap Protocol |
1001 | Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods | 1547 | Requirements for an Internet Standard Point-to-Point Protocol |
1002 | Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications | 1548 | The Point-to-Point Protocol (PPP) |
1034 | Domain Names-Concepts and Facilities | 1549 | PPP in HDLC Framing |
1035 | Domain Names-Implementation and Specification | 1552 | The PPP Internetwork Packet Exchange Control Protocol (IPXCP) |
1042 | Standard for the Transmission of IP Datagrams over IEEE 802 Networks | 1553 | Compressing IPX Headers over WAN Media (CIPX) |
1055 | Nonstandard for Transmission of IP Datagrams over Serial Lines: SLIP | 1570 | PPP LCP Extensions |
1112 | Host Extensions for IP Multicasting |
Windows NT Server 4.0 provides two important tools for integrating Windows NT with UNIX:
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:
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.
To install DHCP, follow these steps:
The warning that adapters now using DHCP must be assigned a static IP address before installation can proceed.
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.
After you install DHCP, follow these steps to configure it:
Using the DHCP Manager to configure and manage DHCP.
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.
The DHCP Manager message that lets you activate your newly defined DHCP scope.
DHCP Manager displaying the newly defined scope.
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:
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.
To install WINS, take the following steps:
The Services page of the Network property sheet, showing Windows Internet Name Service installed.
After you install WINS, follow these steps to configure it:
The opening window of WINS Manager.
The WINS Server Configuration dialog.
The advanced options of the WINS Server Configuration dialog.
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:
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.
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.
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:
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
SunOS | HP-UX | SCO |
A/UX 3.0 | Intergraph | SEQUENT |
AIX | ISC SVR3V4 (POSIX mode) | SGI |
Apollo Domain/OS sr10.3 (BSD4.3) | Linux | SOLARIS |
BSDI | Net BSD | SunOS |
Data General UX | NeXT | SVR4 |
Free BSD | OSF1 | ULTRIX |
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.
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:
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.
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.
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:
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.
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 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 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.
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.
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:
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.
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.
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:
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.
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:
© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.