by Brad Rhodes and Bob Thompson
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.
There are several levels at which two diverse operating environments can integrate. Among them are the following:
This chapter explores the capability of Windows NT and BackOffice environments to integrate with Novell NetWare and the UNIX operating system.
Windows NT Server 4.0 uses a protocol-independent networking architecture, which enables 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 the gap quickly, many network managers will find it necessary to support both NOSs on a temporary basis as their organizations make the 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 enable 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's subsequent withdrawal of 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 battle 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 previously exclusive Novell shops and, accordingly, is improving NetWare's integration with Windows NT. Plans include porting 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, Novell networks depended on IPX/SPX, and UNIX networks used TCP/IP. Each network and transport protocol is fast and reliable, and each has advantages and drawbacks, explained as follows:
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.
NOTE: 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 that barely appeared in sales charts to a major competitor of NetWare. Windows NT Server, in contrast to NetWare, provides a superior application server platform. The Microsoft BackOffice suite 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 Figure 14.1) enables NetWare clients to communicate with a server application using Novell NetBIOS, Winsock, and Remote Procedure Calls (RPCs).
FIG. 14.1
Connect 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 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.
Using a Client Operating System with Built-In NetWare Support
Windows 95 and the Windows NT 4.0 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. The MPR API provides a consistent application interface to the local file system, remote Windows network servers, and NetWare servers.
See "The Windows NT 4.0 Multi-Protocol Router (MPR)," [Ch. 9]
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.
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 Mac OS. The primary drawbacks to installing Novell client software are as follows:
NOTE: The problems attendant to installing Novell client software 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 the two following 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 IPX.COM was replaced by the Novell Open Datalink Interface (ODI), which breaks down the services formerly provided by IPX.COM into the following 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 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 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 enable 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 is bundled with Windows NT Server 4.0 (see Figure 14.2). 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 enables 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.
FIG. 14.2
Microsoft Networking clients access shared resources on a Novell NetWare server
with the Gateway Service for NetWare.
NOTE: An added benefit of using GSNW is that it can be deployed with Remote Access Service to provide remote Microsoft Networking clients access to NetWare file and print services transparently.
See "Network Configuration For RAS," [Ch. 12]
Before implementing GSNW, the Windows NT Server administrator and the NetWare administrator should consider the following issues:
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:
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:
NOTE: At this point, the NWLink IPX/SPX Protocol Configuration dialog box 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 a good reason before you attempt to do so.
When the bindings review is complete, the Network Settings Change dialog box 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 box displays to prompt you to choose one of these servers as the default server to which GSNW connects. 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:
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:
See "Administering Windows NT Server," [Ch. 7]
FIG. 14.15
Assign permissions for the newly created share in the Access Through Share
Permissions dialog box.
Installing and Configuring a GSNW Print Gateway
Installing a GSNW print gateway enables Microsoft Networking users to 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 that the gateway is mapped to.
To install and configure the GSNW print gateway, follow these steps:
See " Administering Windows NT Server," [Ch. 7]
FIG. 14.20
Specify 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 as a diagram in Figure 14.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.
FIG. 14.21
Emulating a NetWare 3.12 server with the Windows NT 4.0 File and Print Services
for NetWare.
NOTE: 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 enables Microsoft clients to access a Novell NetWare server. File and Print Service for NetWare enables 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 an administrator can centrally manage user accounts for both NetWare and Windows NT servers. See the section "Directory Service Manager for Netware" later in this chapter.
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 utilities that are compatible with NetWare, 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 "Directory Service Manager for NetWare," translates NetWare account information to Windows NT Server, re-creating NetWare user and group information, files and directories, security and permissions, and logon scripts.
CAUTION: Although File and Print Services for NetWare enables 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:
- 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.
- Server Name is completed with the default value of SERVER_NAME_FPNW. Accept this name or specify an alternate server name for users 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 enable you to determine server performance and resource usage, as follows:
Minimize Memory UsageñUsing 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ñProviding moderately high server performance with moderate memory usage, this choice is most appropriate for a general-purpose server that shares files and printers as well as runs applications.
Maximize PerformanceñProviding the highest server performance at the expense of increased memory usage, this choice is most appropriate for a server that is dedicated to sharing files and printers.
FIG. 14.24
Enter the password for the account to be used to run File and Print Services for
NetWare.
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:
The Users, Volumes, and Files buttons in the File and Print Services for NetWare dialog box enable you to manage the FPNW gateway, as follows:
After you finish configuring and managing the FPNW gateway, click OK to accept the changes and close the File and Print Services for NetWare dialog box.
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 enables you to manage user accounts on Windows NT servers and NetWare servers using a single integrated database. The Multi-Protocol Routing Service enables 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 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 (see Figure 14.34).
FIG. 14.34
Directory Service Manager for NetWare connects 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 username. 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 Figure 14.35).
FIG. 14.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:
NOTE: 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.
NOTE: If you're installing directly from the distribution CD, the DSMN distribution files are located in d:\dsmn\nt40\processor; 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.
Configuring and Managing Directory Service Manager for NetWare
After you install DSMN, follow these steps to configure and manage it:
CAUTION: 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.
- User Must Change PasswordñIf marked, this specifies that a user must immediately change his password when he first logs on.
- Add Supervisors to Administrators GroupñIf marked, this 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, this specifies that Novell File Server Console Operators will be added as members of the Windows NT Console Operators group.
- Use Mapping FileñIf selected, this specifies that individual user propagation parameters are based on the contents of an ASCII mapping file.
- The Password sectionñThis enables you to specify how passwords are assigned on the newly created Windows NT accounts. Select one of the option buttons to determine password assignments, as follows:
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 username for each account
Password IsñEnables 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
After you complete the Propagate NetWare Accounts to Windows NT Domain dialog box as shown in Figure 14.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.
FIG. 14.43
Specify changes to the default settings of the Propagate NetWare Accounts to Windows
NT Domain dialog box.
NOTE: 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.
This section describes the integration of the Microsoft BackOffice components with the UNIX operating system. Ever since the earlier research releases of UNIX at AT&T, it has been a landmark operating system. The UNIX system has led the way to open computing. The majority of client-server and Internet systems owe a large part of their heritage to the UNIX operating system.
Microsoft has put considerable effort into ensuring that the BackOffice products integrate well with UNIX. This shows Microsoft's commitment to open computing, and ensures that network managers in homogenous operating environments will be able to integrate the BackOffice components into their operations. This section addresses how BackOffice and the UNIX operating system interact at each of these levels.
Prior to the development of Windows NT, Microsoft developed the Xenix operating system. Xenix was a 16-bit port of the original AT&T UNIX Operating system developed to run on the Intel 80286 processor. In addition, Microsoft joined with IBM to develop the MS-Net or LAN Manager Network Operating System. The LAN Manager operating system provided file and print sharing. The main advantage of the LAN Manager Operating System is that it was installed on top of the main operating systems. The LAN Manager Operating system was primarily supported on OS/2 and UNIX. The LAN Manger was based on the NetBIOS protocol. Sytek Inc., Sunnyvale, California, developed the NetBIOS specification in 1984.
The end result for the Windows NT operating system is broad support of communications architecture. In a heterogeneous network environment, the Windows NT Server provides a large number of connectivity options out of the box. For UNIX, providing LAN manager connectivity is typically an expensive third-party upgrade.
Microsoft has relied heavily on the capability to encapsulate NetBIOS communications traffic into different transport layer protocols. Supported transport layer protocols include TCP/IP, IPX/SPX, and the native Windows NT NetBEUI. Microsoft will increasingly move to network components that do not rely on NetBIOS encapsulation. The Windows NT network components will be engineered to natively speak the differing protocols. See the discussion in the section "Common Internet File System" later in this chapter to see more about how Microsoft is going to sever its ties with the NetBIOS interface.
In order to provide a basic set of connectivity with the UNIX environment, Windows NT ships with the necessary TCP/IP client applications. These client applications include Telnet, FTP, lpr, and SNMP. In addition, the Windows NT resource kit contains very useful UNIX like servers for these same applications. These server components include a Telnet service, an FTP service, and an lpr service. The lpr service and client applications are common UNIX utilties that allow users on one UNIX machine to print to printers on another UNIX machine.
NOTE: In the Windows NT operating system, a server type application is typically run as a service. In the UNIX operating system, a server application is often a daemon, which is a background process.
The POSIX operating environment provides many of the commonly used UNIX command-line options. With POSIX and Telnet server service installed, it is possible for a user logged on to a UNIX system to Telnet to a Windows NT server and use many of the same command-line options from the UNIX system. Many server type utilities that have existed on UNIX rely on UNIX commands to get their jobs done. This is why the POSIX system is often important. These UNIX demons could not be ported to Windows NT unless these commands were available.
POSIX for Winodows NT is an optional operating system extentsion that is shipped with Windows NT. (POSIX stands for Portable Operating System Interface.) The POSIX standard has been accepted by IEEE and the ISO standards bodies. POSIX specifies a base level of operating system APIs and command line utilities. This base is very similar to UNIX and includes commands such as ls to list a directory and cd to change a directory. By default, the POSIX subsystem on Windows NT is installed and configured. When a POSIX application is started, the POSIX subsystem is started and application is launched.
For many years, system administrators have remote shelled between UNIX systems to ease administration. The 4.0 version of Windows NT now ships with a rexec client. This enables a NT 4.0 workstation to remote execute a command on a rexec server. The rexec is short for remote execution. A command that is proceeded by an rexec will run on a remote host. This has always provided the capability to kick off remote jobs in the UNIX environment. It is now possible to rexec jobs between Windows NT machines and UNIX machines. Windows NT 4.0 does not ship with a service component that provides rexec server capabilities. In order to allow NT 4.0 to be a rexec server, you need to acquire some third-party software. Some providers of these include Seattle Labs, Software Innovations, and Altaman systems.
Windows NT 4.0 ships with a shell called sh.exe that is a part of the POSIX subsystem. This command shell supports a limited set of features when compared to a UNIX shell. A large number of UNIX shell scripts could be very useful in the Windows NT environment. In order to use these shell scripts, the Windows NT administrator must install a third-party command shell. Some of the vendors that are offering good third-party shells for Windows NT that are compatible with UNIX shells include Seattle Labs and Altaman systems.
There are three potential sources for FTP servers that are readily available for the Windows NT Server environment. In Windows NT 4.0 Server, the FTP service was integrated as a part of the Internet Information Server (IIS). Normally, the Internet Information Server is installed during the installation of Windows NT 4.0 Server. If you did not install the IIS component, you need to install the IIS at this point.
See "File Transfer Protocol," [Ch. 17]
The FTP server service is an optional component of IIS. To install this component, follow these steps:
1. Open the Control Panel. Double-click the Network applet icon.
2. Click the Services tab and click the
Add button.3. In the
Select Network Service dialog box, choose MicrosoftInternet Service Manager 2.0 (IIS). Click OK. This brings up the Microsoft Internet Service Manager 2.0 Setup dialog box (see Figure 14.50).
FIG. 14.50
The Microsoft Internet Service Manager Setup dialog box.
Once the FTP server has been installed, FTP clients can connect to your FTP server. An FTP connection enables users to log on to your server and download files.
See "File Transfer Protocol," [Ch. 17]
FTP servers introduce a point of security contention. The majority of users will want to configure their Windows NT server to allow only anonymous connections and assume that all of the files on the server are available to the outside world. Files that contain sensitive information should not be put in the directories that are available to the FTP server. If you choose to implement your FTP server to allow login accounts, you should be aware that the FTP protocol sends username password combinations over the network in a clear text format. People on the network can potentially snoop the username and password, thereby gaining access to the files on your FTP server.
The Telnet server enables clients on UNIX machines to log on and get a command prompt on your Windows NT server. This enables a remote client to launch batch and shell-script jobs that execute on the Windows NT server. Most major operating systems ship some form of Telnet client either with the operating system or as an add-on tool.
The Telnet server that ships with the Windows NT Server 4.0 Resource is a beta version of the telenet server. The latest release of the inbound Telnet server can be gotten from ftp.ntrk.microsoft.com\telnetd. You will need to pick up this version before installing the Telnet server. To install the Telnet server, perform the following steps:
1. Open the Network Configuration dialog box.
2. Select the Services tab. Click the Add button to open the
Add Services dialog box.3. In the Add Services dialog box, select the Have Disk option.
4. In the Directory File dialog box, enter the path to your Windows NT resource kit Telnet directory. If you have gotten the new beta file from the preceding URL, you should receive two options in the Select OEM Option. The first option is the Remote Session Manager. The second option is the Telnetd Service Beta (Inbound Telnet). Choose the Remote Session Manager option.
One last facility that is often found in UNIX networks is the RCP capability. RCP in UNIX stands for remote copy. Remote copy allows one-line copies from a source system to a destination system. RCP is functionally close to FTP but operates a little differently. FTP always requires a user to log on to a server prior to transferring any files. RCP is more automated. RPC sends the username of the current system along with the request to copy the files. The destination system looks at the user ID and sending systems computer name. If the computer name is in a special file, the user identified by the user ID is given permissions as if the person had logged on that server. For this reason, RCP is only possible between systems that have been previously set up.
The previous section explains how Windows NT and UNIX operating systems are able to install communications protocols that enable them to communicate. This section covers the capability of Windows NT and UNIX machines to share files and printers. The following are two possibilities for sharing files in this fashion:
For Windows NT to become a client on a UNIX server, the Windows NT machine needs a Network File System (NFS) client. The same products that allow an NT workstation to be become a NFS client also sell an NT NFS server. When this product is added to an NT system, the NT system will look like an NFS file server to any NFS client.
The Network File System specification was developed by Sun Microsystems Incorporated. The NFS file system heavily depends upon the TCP/IP networking architecture. Like many other file sharing architectures, NFS integrates into the operating system. When a request to open or read a file that is on an NFS shared mount point, the operating system redirects the file system call to the NFS redirector. A typical NFS network is shown in Figure 14.51.
FIG. 14.51
A typical NFS network.
Three RFCs dictate the design and implementation of NFS. RFC 1094 dictates the design of NFS. RFC 1057 defines the RPC specification. RFC 1014 covers the external data representation specification XDR. A good reference for RFCs is found at http://www.cis.ohio-state.edu/hypertext/information/rfc.html.
Once the NFS software is installed on Windows NT machine, the Windows NT machine can attach to an NFS share that is available on the network. When users mount the NFS share, they need to log on to the NFS server because Windows NT does not know how to authenticate the user using the Windows NT login on the UNIX server. Typically, having the NFS software display a login window for the user does this.
One provider of NFS server software for Windows NT goes beyond the typical NFS server: The Intergraph Corporation is now shipping the DiskShare and DiskAccess products. The DiskAccess client enables a Windows 95 or Windows NT computer to access NFS mounts on remote machines. The DiskShare product enables the users on Windows NT workstation and server machines to create NFS drive shares. These drive shares are available to any NFS client.
The DiskShare product enables the administrator to create NFS shares directly from the Explorer or My Computer file browsers. It is a multithreaded product that runs kernel mode service. This design provides a scalable efficient NFS solution for Windows NT.
DiskShare relies on the Windows NT native security to authorize access to resources. It enables the user to create a mapping file that maps an incoming NFS username to an Windows NT username. This mapping can be one NFS username to one Windows NT account name, or multiple NFS usernames to one Window NT account. The security access to the files in the NFS share are checked using the normal Windows NT file access protocols. NFS relies on UNIX numeric user Ids (UIDs) to determine access to files. The DiskShare product enables the user to map these UIDs to Windows NT user accounts.
In addition, users that are mounting the NFS share from Windows-based clients running Intergraphs DiskAccess client are authenticated using their actual Windows login. See Chapter 4, "Enterprise Planning and Implementation," to understand Windows NT security.
When users are using the DiskAccess product, they are able to view NFS share points like any native Window NT share point. The DiskAccess product is implemented as multithreaded Ring 0 Virtual Device Driver. This architecture ensures maximum performance when the machine is heavily loaded. When the DiskAccess product is from a Windows NT machine, each user of the machine can configure a login password and username that is sent to the NFS share.
The second alternative to provide file and print sharing between UNIX and Windows NT Server is to install UNIX software that enables the UNIX system to "talk" the Windows NT native networking language. The basic package that facilitates the integration of Microsoft networking into the UNIX operating system is the LAN Manger for UNIX (LMU 2.2). The LAN Manager for UNIX is the result of a partnership between Microsoft and AT&T GIS. In addition to providing LMU for AT&Ts version of UNIX, the partnership provides for LMU source code to be sublicensed to other UNIX vendors.
NOTE: Due to the three-way split of AT&T, the former AT&T GIS operating unit is changing its name back to NCR.
The success of the LMU partnership has led AT&T and Microsoft to develop Advanced Server for UNIX (AS/U). AS/U is equivalent to Microsoft's Advance Server operating system running on the UNIX platform. The security groups and domain organization are identical between the two products. This allows NT and AS/U servers to serve users on the same domain. From the network clients' perspective, there is no difference between the AS/U and Windows NT Server systems. AS/U ships with native tools for server management that are different from the Windows NT tools. Since the AS/U and Windows NT servers are nearly identical, the administration tools from Windows NT can configure and manage an AS/U server. Likewise, the AS/U tools can configure and operate with Windows NT servers.
There are a large number of possiblities to deploying AS/U and Windows NT in a mixed environment. A small example is provided here to help explain how AS/U and Windows NT server can integrate. The network diagram is shown in Figure 14.52.
FIG. 14.52
The Advanced Server UNIX platform in a heterogeneous network environment.
The AS/U diagram in Figure 14.52 shows a network with client workstations running Windows and Windows 95, a Windows NT Server, and several UNIX servers. The UNIX servers have been in place for some time. They share each others files via the NFS network file system. The UNIX box that is running AS/U allows all of the clients running only Windows Networking to log on to any of the NFS shared drives. In this fashion, the AS/U operating system can provide a gateway from the Microsoft networking protocols to the NFS shared resources.
In Figure 14.52, it is important to note that the AS/U participates in the Windows NT Domain just like any other Windows NT Server. This includes participating in the Windows NT Domain, trust level relationships, and DHCP and WINS integration. The last service that AS/U provides is the capability to abstract the UNIX print spooler. This means that the Windows clients in Figure 14.52 are able to print directly to the AS/U printer share. The AS/U printer share maps the spooled print job to a UNIX print queue, which can reside anywhere on the UNIX network.
AT&T has sublicensed the AS/U source code to DEC for OSF/1 and VMS operating systems, HP for HP/UNIX and SCO for SCO-UNIX, Bull, SNI, and Olivetti operating systems. Unipress is porting the AS/U to Sun's Solaris operating system and IBM's AIX operating system. Almost all of the major UNIX vendors will offer AS/U.
Windows NT and Windows NT Advanced Server ships with a printing service that supports UNIX style printing. UNIX systems use a de facto standard for managing print jobs. This standard is based on the lpr, short for line printer, and lpd, short for line printer daemon printer client and printer server. The lpr command-line tool was used on UNIX systems to specify the destination and file to print. The lpr tool would then spool the print job to the line printer daemon lpd. The lpd server would manage ensuring that the job was spooled and printed correctly.
The Windows NT lpd is added to the system in the Network Configuration dialog
box. You can get to the Network Configuration dialog box by choosing S ettings,
Control Panel and double-clicking the Network icon. Once you are
in the Network Configuration dialog box, click the Add button. This
brings up the select network service dialog box. In this dialog box, the lpd service
is installed by selecting Microsoft TCP/IP Printing.
Once the printing service has been installed you can send print jobs by setting up a normal printer connected to the lpd spooler. You can also send print jobs directly to the lpd server running on the Windows NT system or a UNIX system. To send a print job from a Windows NT system to a lpd server, use the lpr command-line tool. The lpr command-line tool works identical to the lpr tool in UNIX.
Once the lpd daemon has been set up on the Windows NT system, this system can receive print jobs from UNIX hosts. This enables Windows clients and UNIX clients to share the same printers. The lpqñline printer queryñutility allows a user to query the line printer for its status, including number of documents to print.
See "Managing Access to Shared Resources," [Ch. 7]
Once jobs have been sent to the lpd server, you can monitor the status of a an lpd server by using the lpq command, which produces a list of all of the jobs currently in the lpd servers printer queue.
In addition to the normal printing of jobs via the lpr and lpd tools, Windows NT has enhanced TCP/IP printing tools. The original tools first shipped with Windows NT covered the base requirements called for in RFC 1179. These enhancements were added to the base solution to address what many UNIX people had come to expect from lpr and lpd tools in the UNIX environment. They include the capability to source jobs from any available port between 512 and 1,023. Windows NT Server 4.0 also has the capability to print multiple data files per control file and to correctly handle host naming when in print-through mode.
You saw how it was possible for a Windows NT system to adopt the UNIX methods of sharing files and how a UNIX system could adopt a Windows NT method of sharing files. This section describes two new file systems that are being proposed as the standard file system for the Internet.
Why is there a need for a standard file system for the Internet? Currently, the HTTP standard for transmitting data does not provide applications and application developers with a rich set of commands that enable an application to read, write, lock, delete, or share files. The following two standards compete as the common file sharing system for the Internet:
Neither of these systems is meant to replace the HTTP traffic common with Web browsers. They are more targeted at the older FTP method of transferring files.
The WebNFS specification is a minor upgrade to the NFS specification that has been a popular file sharing protocol in UNIX systems for a long time. Because NFS is already based on the TCP/IP protocol, the system can be adopted to the Internet without much change.
WebNFS primarily changes the way that an NFS client attaches to a file on an NFS server. The problem with the normal NFS protocol is that it took more than four request response pairs to obtain a mount point and mount the file handle to the mount point. Once the client acquires the mount point, it must issue a lookup command for each component of the directory. For instance, to get the file nfs://ftp.sun.com/pub/projects/whizbang/src/main.c would take five lookup transmits. Each lookup transmit would move the client closer to the actual file that is desired.
NFS was designed for the LAN environment in which this type of penalty would not be that big of problem. When this is translated to the Internet (where the server could be half the way around the world), the multiple requests to traverse the directory would cause a very long delay. The new WebNFS protocol enables the client to jump to the actual file handle with one request.
One additional change to the NFS specification is the inclusion of a URL-based file specifier. An NFS URL looks like nfs:://test.hp.com/pubdir/pcdir/filedir/drivers.txt. This change enables WebNFS browsers to access NFS files directly.
The advantages of NFS over FTP is that NFS will almost always recover a file transfer that is in progress, whereas FTP is rarely able to recover an interrupted file transfer. NFS is able to handle all of a clients request over one TCP connection. FTP demands a new request for each new request. This can cause a burden on heavy traffic sites.
The advantages of WebNFS over HTTP are that WebNFS does a better job of managing a clients interaction with the server. It uses less resources that equivalent HTTP activity. WebNFS browsers can follow the same links that an HTTP-based browser can. The NFS specification allows multiple simultaneous connections to the server. This enables a WebNFS client to issue five reads for five different files, and the server will begin responding as soon as it can. The data for complex pages can be interleaved. The downside of the WebNFS specification is that CGI scripts cannot be executed.
The main goal of WebNFS is to create an NFS file system that is much more efficient over Internet or WAN type connections. The NFS file system remains geared toward the LAN environment.
The Common Internet File System (CIFS) system proposed by Microsoft as a standard Internet file system based on the Server Message Block (SMB) protocol. Microsoft has submitted the CIFS 1.0 specification to the IETF for approval. In 1992 SMB became an X/Open standard. After its approval by X/Open, there were several ports of the SMB to different UNIX systems. One such popular port was the Samba system written for the Linux operating system.
The SMB file sharing system is often referred to as the DOS/Windows File API on the wire. The transmissions are very much like a serialized version of how a DOS/Windows program reads and writes a file. SMB has always had powerful commands. Each of the SMB commands can typically do a lot. This is in contrast to the NetWare protocol, which has taken 30 function calls to do the same that one SMB function call does.
The CIFS is an enhanced version of the SMB file system. The first thing the CIFS does is to remove unneeded components, stripping SMB down to just a file sharing protocol. This removes printing, login, and file browsing out of the file sharing protocol. The second change was to remove SMB reliance on NetBIOS naming. Under CIFS, the SMB name resolution can use any name resolution, including NetBIOS and DNS. Some carryovers from the SMB to CIFS are the capability to chain requests and advance caching control.
CIFS adds some additional features to SMB to enhance its use as an Internet file sharing platform. These enhancements include support for Microsoft's DFS file system. The DFS file system enables a network administrator to construct a file share that is the combination of many physical subdirectories. Each of these subdirectories could link to a subdirectory of the root share. Another helpful feature is file or directory change notification. This way the client could access a share point and ask to be notified when a file appears. CIFS adds client-side cancellation of pending requests, enabling the client to stop a file transfer. CIFS also includes files with 64-bit offsets, Unicode file names, and file streams. CIFS includes fault tolerance improvements and optimizations for slow links.
There are some issues facing CIFS being accepted as an Internet standard protocol. These issues mainly are the differences between UNIX and Windows NT. The Windows NT security model uses text-based usernames to identify users. UNIX systems use userIDs to identify users. It is not clear how the text-based CIFS username will be translated to UNIX-based UserIDs. It is even less clear if you are to have a UNIX system using CIFS to connect to another UNIX system. Again there is no clear way to map the UserID to the username.
The two proposed standards are going to be compared over the next year as they both vie for the number one spot. They both can access files with one command. CIFS actually is a little more efficient in this regard because CIFS can open and lock the file in one request. CIFS is made to enable existing DOS and Windows applications to lock files over the Internet. This could prove to be bad in that a lot of these older applications would lock all of their files. In a large multi-user environment, this could cause problems. The applications written to manage NFS files are primarily targeted at UNIX and are more careful about the locking of files. Table 14.1 gives a list of comparisons for the CIFS and NFS file systems.
Table 14.1 A Comparison of CIFS and NFS
| CIFS Architecture | NFS Architecture |
| Connection oriented | Not connection oriented |
| Places burden of managing connection onto the server | Does not support locking to maintain a stateless connection. This will create problem with PC applications that lock files. |
| Caching support | Increases complexity of client and server. |
| Most operations between Client and Server are atomic | Most operations can be repeated whether the previous operation worked or not. Service is stateful. |
The Remote Procedure Call (RPC) was originally implemented by Sun Microsystems for their version of the UNIX operating system. Sun Microsystems received approval from the Open Network Computing (ONC) as a standard for RPC implementation. This version of RPC is commonly known as the ONC/RPC specification. The Open Software Foundation chose to enhance ONC/RPC to be included as a part of its Distributed Computing Environment (DCE).
RPC enables a procedure on one client to call a function that actually ends up executing on a separate client. This paradigm becomes a very powerful tool for implementing distributed applications. Instead of custom writing the message protocols between the client and server, developers can implement the message passing part of the programs as function calls. In addition, RPC is independent of the network protocol that is used.
The magic of RPC is done by implementing a stub function call that is linked into the RPC program. This stub function call is linked from a library that is generated by running the RPC function calls through an Interface Definition Language (IDL) compiler. The IDL compiler generates a library function that can be called from any language. When the client stub function is called, it marshals all of the arguments to standard format. It packages the arguments to the function call and forwards the call to the server. The server unpackages and unmarshals the arguments. The function runs on the server. Once the server has completed the function, it marshals and packages the return parameters and sends them back to the requesting client.
Marshaling of the arguments refers to the conversion of the arguments to a standard operating system independent format. One of the bigger problems when passing data from one system to another is the variation in the format of the data. Some machines always break word boundaries on 32-bit intervals, while others use 16- or 64-bit intervals. Some machines use little endian data representation while others use big endian. The endian of a processor is the bit ordering within the byte. Marshaling enables the data to be converted and formatted in a standard fashion. This guarantees that the client and the servers can reside on different operating systems with different hardware architectures.
To extend its network computing model in Windows NT, Microsoft has implemented a version of RPC in the Windows NT operating system. The Microsoft RPC version differs somewhat from the DCE/RPC. Primarily the differences are in the RPC directory services. The DCE/RPC directory services are based upon the Cell Directory Services (CDS). Microsoft chose to offer a proprietary RPC Locator with Windows NT server. Microsoft has also included a CDS compliant directory service. In order to use non-TCP/IP protocols in RPC processing, you will need to use the Microsoft RPC Locator. If you are integrating Microsoft RPC into your existing RPC infrastructure, the CDS directory service ensures that Directory services are available across the enterprise.
RPC directory services provide the client a method of locating services. When a client issues a call to an RPC function, the RPC component uses the RPC Locator to locate a server that is advertising the function that is getting called. RPC then routes the function call to that server.
The Microsoft implementation of RPC supports a wider range of protocols than most RPC offerings. Table 14.2 shows the protocols that are supported and the operating systems that are supported. The key for the table is as follows:
Table 14.2 Microsoft RPC Supported Protocols
| Protocol | DOS | Win 3.x | Win 95 | Win NT | Mac | UNIX |
| NetBIOS over TCP | C | C | N | C,S | N | N |
| NetBIOS over IPX | C | C | N | C,S | N | N |
| NetBIOS over NetBEUI | C | C | C,S | C,S | N | N |
| TCP/IP | C | C | C,S | C,S | C | C,S |
| Named Pipe | C | C | C | C,S | N | N |
| SPX | C | C | C,S | C,S | N | N |
| DECNet | C | C | N | N | N | N |
| AppleTalk | N | N | N | N | C | N |
| Banyan Vines | N | N | N | C,S | N | N |
| UDP/IP | C | C | N | C,S | N | N |
| IPX | C | C | N | C,S | N | N |
| Local Procedure Call | N | N | C,S | C,S | N | N |
The Microsoft RPC implementation is a robust distributed computing platform. It is the basis for many of the management tools that are used on Windows NT server. The RPC functionality has become a key technology in the distribution of DCOM type objects.
The Network Operating System vendors have really begun to heat up the competition in the delivery of Common Directory Services. These common directory services allow resources on a network to look like they are all organized under one directory tree.
A good example of what this looks like to the end user would be to imagine a directory tree. As the user begins to go up the directory tree, he not only is changing directories on one server, but changing from server to server. As each new server is attached, the user's security is passed to the new server automatically. The user will see a continuous directory tree.
The network managers are another group of people that are driving the use of more common directory services. The benefit of a common directory for network managers is that it is a way to reduce the overwhelming amount of information. Each user ends up with several different usernames on each system and each platform. For instance, a user that uses Windows to logon and use network resources, uses UNIX to process some legacy reports and connects to a SQL database would end up with three separate logins. If all of these products used a single directory source for usernames, then the administrator could configure the user with only one change.
The third group of people to benefit is developers. The process for enabling their applications to manipulate the network resources or usernames requires custom coding for the manipulation of each component. When a directory is in place, the developer can utilize just one set of APIs for the manipulation of users, file sharing, file security, printer sharing, and anything else on the network.
Of course the real benefit to everyone comes when the directories become cross platform. When directories become cross platform, it will be possible for a user to cross different machines utilizing resources without ever knowing it. At that point, users no longer need to remember that their stock information is on server XYZ.
The drive behind reliable directory services has been led by Banyan, maker of the Banyan Vines Network Operating System, and Novell with the NetWare Directory Services. Microsoft is now offering the OLE/DS. Of these vendors, Novell was beginning to get a large amount of attention in this area. NDS was bolstered by a good client implementation for Windows, Window 95, and Windows NT. The majority of these vendors would like to get a user trapped into using their directory services. This makes it much easier for users to access resources on the vendors native operating system. See Chapter 8, "Windows NT Server Directory Services," to see the details of Windows NT directory services.
The speed with which the Internet has exploded onto the computing scene has brought to light a common directory service that is now starting to get a lot of attention from all of the main operating system companies: The Lightweight Directory Access Protocol (LDAP) is now being proposed as the best shot at achieving good cross platform directory services.
The LDAP specification was developed by the University of Michigan and the Internet Engineering Task Force. Currently, LDAP version 2 is the released version of the specifications. LDAP version 3 is currently in the works.
LDAP is a distillation of the Open System Interconnect (OSI) X.500 Directory Service. The X.500 Directory Service has proven to be too much of a burden in all but the largest of organizations. This is especially true for Windows, Mac OS, and DOS clients. LDAP will be used in the following three modes:
Security in the LDAP environment is important because end users will want to control access to information, allowing some people access to the resource and not allowing others. The LDAP 2 specification allows for Kerberos encryption of the password while on the wire. LDAP 3 is looking at implementing the full X.509 security for the directory service.
The capability to replicate directory services becomes very important in large organizations or when considering applying LDAP on the Internet. Without replication, the master server of a large network will become a large potential bottleneck. LDAP 3 is offering some forms of replication.
Netscape was an early adopter of the LDAP specification. Netscape is also a company with little or no legacy directory servers to support. As a result, Netscape is the largest proponent of LDAP and the largest user of LDAP.
Microsoft is beginning to release products that have LDAP support in them. Some of these products include the latest version of the Exchange Mail Server and the upcoming version of Internet Explorer. Microsoft has committed to making LDAP a standard offering component of the operating system with the next release of Windows NT. Microsoft is primarily moving forward with its original ODSI and OLE/DS initiatives. The LDAP connector becomes a service provider interface between the native directory and the LDAP directory.
Novell is also adding LDAP support to their NDS directory service. Novell feels that they have a strong directory offering with good OS support and solid multi-master replication. Its approach to LDAP is the least aggressive of the three vendors.
Netscape has rushed out and became a leader in the implementation of LDAP. It is now adding many features that are nonstandard. These features largely address some of the scalability and encryption problems that exist in the deployment of large LDAP networks.
LDAP is quickly becoming one of the more important standards available on Internet.
Again, with Application Programming Interfaces, two approaches can be taken. The first is to port a UNIX application to the Windows NT system. The second is to port a Windows NT system to the UNIX environment.
One advantage that a programmer can make use of is the availability of the OSF/DCE environment on both systems. This means that the communications portion of the application will not need to be ported from one system to the other, but can be used in tact on either system.
Bringing more of the UNIX API environment to Windows NT will greatly aid in the porting of a UNIX application. There is one application environment that leads in providing this functionality: the NuTCRACKER suite of development tools from DataFocus. Included in the NuTCRACKER SDK are the UNIX environment APIs, a porting guide, and UNIX system libraries. The UNIX system libraries run on top of the Win32 APIs and are tuned to the Windows NT environment. This system includes support for the full UNIX API including fork, exec, pipes, named pipes, message queues, signals, semaphores, and BSD sockets. The tool also includes the MKS Toolkit to aid the UNIX developer. The MKS Toolkit brings vi, cc, and utilities to make the Windows NT development environment more comfortable to the UNIX developer.
The NuTCRACKER X/SDK integrates the X11R5-based X/Server and libraries and the X/Motif libraries to the standard NuTCRACKER SDK. This enables the porting of X Windows applications
Applications ported to Windows NT from UNIX can maintain a very UNIX-centric look or can take advantage of the newly available Win32 APIs as needed.
A second tool that enables the porting from UNIX to Windows NT is the Portage tool from Cnsynsys Computers Inc. It provides similar functions but it is a full port of UNIX SVR4 and UNIX SVR4.2 system in the Windows NT environment. When fully installed, a command window that is exactly like UNIX runs. The developer works in the text mode or the add-on X environment. The command window functions like the MKS toolkit and the Hamilton C Shell.
Microsoft has begun an initiative to support vendors that are porting the MFC and Win32 APIs to the UNIX environment. This initiative is called the Window Interface Source Environment (WISE) in which Microsoft helps these vendors by supplying source code and engineering to help in their implementation of Win32 and MFC on the UNIX. There are two portions of this initiative: the WISE SDK and the WISE Emulator.
Choosing the WISE SDK enables the developer to port the Windows application on the UNIX platform. The resulting application will be targeted at the UNIX system that WISE SDK was engineered for. This produces the most robust and fastest port of the application, but also requires the most time. These tools include support for the latest features of Windows, including OLE, ActiveX, threads, and WinInet APIs. A tool that is considered a leader is the Wind/U toolkit from Bristol Technologies.
The WISE Emulator is more appropriate when the source code for the package is not available. The WISE Emulator will also emulate an x86 processor when it is run on systems that do not have a x86 processor.
In addition to those resources previously mentioned, many other UNIX connectivity utilities are available from third-party vendors. Some of these utilities are available as freeware. They include enhanced Telnet and FTP servers, time servers that enable Windows NT systems to receive distributed time updates from UNIX servers, and Finger daemons that enable Windows NT servers to respond to standard Finger requests. Finger requests enables remote users to obtain user information about users on a system. X/Servers enable users of UNIX-based X Windows clients to log on to Windows NT X Windows servers. A good reference starting point for these and other important tools is the Internet Resources for Windows NT Internet Support page at http://www.microsoft.com/windows/ntserver/tools/isupport.htm.
One of Windows NT 4.0 strongest features is its ability to be deployed in a heterogeneous environment. You learned in this chapter that Windows NT 4.0 could be installed in an existing Novell Netware LAN. You saw that File and Print Services for Netware allows a Windows NT 4.0 server to look just like a Netware file and print server. When there is a large network of Netware clients, this solution allows NT 4.0 to drop into place and appear as just another Netware resource. Further integration of Windows NT and Netware allow the two network operating systems to share directory services. Directory services are the key to locating resources on a network. The more integrated the directory services the more integrated the two operating systems become. The user or the network administrator can move users from NT 4.0 Servers to Netware servers and back with out notice.
In the future, Windows NT, NetWare, and UNIX will continue to increase their ability to integrate. You will see additional work in the area of Lightweight Directory Access Protocol (LDAP) and other directory services integration efforts. For more information on these and related topics, see the following chapters:
© Copyright, Macmillan Computer Publishing. All rights reserved.