Integrating WinFrame and Windows NT into another network operating system is done in most cases by making use of tools inherent in the Windows NT operating system. Many of these tools are automatically installed as part of your Windows NT setup, and others can be installed at another time. The following sections describe some of these tools.
WinFrame provides great network integration tools.
NetWare integration Integrating a WinFrame server into a Net-Ware network is no different than setting up any other Windows client for NetWare. You simply install a compatible protocol stack and a client shell during the WinFrame installation. Microsoft uses NWLink to provide an IPX/SPX compatible transport and GSNW (Gateway Service for NetWare) for the NetWare client. You can add both of these after the initial installation by using the Network configuration applet in the control panel.
NetWare integration is the same for WinFrame as for any other client for NetWare.
With GSNW, which is illustrated in Figure 5-3, you access file and print resources on NetWare servers from your Windows NT device. You also create a gateway to share NetWare resources with Microsoft networking client computers that do not have NetWare client software. You can also run NetWare utilities and NetWare-aware applications from your WinFrame session.
FIGURE 5-3
GSNW applet
GSNW allows you to configure a WinFrame session to act as a NetWare client. When you log on to your WinFrame session, GSNW will log you on to a preferred server as a NetWare 3.x or 4.x bindery emulation client or to a preferred context and tree, which is the location of an object in a directory tree, as an NDS (Novell Directory Services) client. Depending on the preferences you set, you can then choose to run the appropriate NetWare login script to utilize NetWare file and print resources. You can also connect to these resources using a Microsoft tool such as File Manager or by using the Net Use command. You refer to the NetWare resources with the UNC path. For example, you can map a public directory on a NetWare volume named SYS, on a file server named FS1, by typing the following at an MS-DOS prompt:
net use P: \\FS1\SYS\public
You can connect NetWare directories to a WinFrame server.
To connect to a NetWare server from a WinFrame session, you must have an account on the WinFrame server or domain and on the NetWare server or tree and context. WinFrame supplies tools to synchronize these accounts. These tools will work only in bindery mode, however. One of these tools is the NetWare User Access for WinFrame Tool. This tool allows you to migrate NetWare accounts into your WinFrame server or Windows NT domain. The tool copies the user’s name and group information. It does not copy the NetWare password. You can have WinFrame synchronize the bindery passwords by choosing the Config button in the User Manager For Domains dialog box. An administrator sets a pre-ferred NetWare server and a Domain Admin account. This setting gives the NetWare server the ability to update the WinFrame pass-word when a user changes his or her NetWare password.
You can synchronize WinFrame and NetWare accounts.
NDS lovers, do not despair. NetWare has come to the rescue. With the IntranetWare Client for Windows NT, WinFrame version 1.7, compatibility has arrived. You can find information about this product at:
http://www.novell.com/intranetware/
The IntranetWare Client for Windows NT is installed on the Win-Frame server, not on the WinFrame clients themselves. When a WinFrame client logs on to the WinFrame server and runs a virtual session, the user is given the ability to log on to an Intra-netWare Server.
Installation of the IntranetWare Client for Windows NT will not replace the WinFrame Graphical Identification and Authentication (GINA) with the IntranetWare GINA because the WinFrame GINA includes code that is necessary for proper system operation. A user is first logged on to the WinFrame server by entering his or her user credentials into the WinFrame GINA. During the initial reboot after installing the IntranetWare Client for Windows NT, the user is presented with an input screen for entering preferred/default settings. These settings include server, tree, and context. The WinFrame user credentials are then compared with the preferred IntranetWare settings for an IntranetWare credential match. If the WinFrame username and password match those for a user in the preferred tree and context, the user is automatically authenticated to IntranetWare. If the credentials do not match, the IntranetWare GUI Login Screen is displayed for login to an IntranetWare Server.
WinFrame can synchronize with the Novell Intranet-Ware client for Windows NT.
The Workstation Manager feature of IntranetWare is dependent on the IntranetWare GINA for proper operation. The Workstation Manager is not supported with WinFrame because the Intranet-Ware GINA is not installed on the WinFrame server.
The preferred/default settings of server, tree, and context can be entered during the initial reboot after installation of the Intranet-Ware Client for Windows NT or entered or changed on the Novell IntranetWare Client Service Configuration page under the Client tab. You access this page by selecting the Networking icon found in Control Panel within the Main group, selecting IntranetWare Client for Windows NT, and clicking the Config button.
These default settings are global and will be the default settings for any WinFrame client that accesses IntranetWare through the WinFrame server. If individual IntranetWare user settings are different from the default settings, they will not be remembered for future logins by that user; therefore, users will always be presented with the preferred/default settings (server, tree, and context) of the system at login.
OS/2 LAN servers In this section, we’ll cover the integration of WinFrame servers with IBM OS/2 LAN Server 4.0 servers. The information also applies to IBM LAN Manager 2.x. Like Microsoft Windows NT servers, IBM OS/2 LAN servers belong to logical groups called domains and the domain controller manages information about users, groups, and workstations within a domain. Unfortunately, IBM LAN Server 4.0 cannot participate in Microsoft domains or share account information with a Microsoft domain controller or a WinFrame server. You can, however, find ways to bridge these incompatibilities.
OS/2 LAN servers use a domain structure similar to that of Windows NT.
IBM LAN server domains are viewed and treated as workgroups under WinFrame. To let users with accounts on other systems access WinFrame and Windows NT resources, you can create local accounts for those users in WinFrame domains containing those resources. You can then place those accounts in local or global groups in the domain and assign necessary permissions to those groups. Although you can give permissions directly to local accounts, I recommend that you don’t. These permissions will be difficult to maintain if you later upgrade those other systems to WinFrame and no longer require the use of local accounts. Rather, if you assign the permissions to groups and you later replace other systems with WinFrame after giving those users local accounts, you can then delete the local accounts and provide those users with WinFrame accounts.
WinFrame treats IBM LAN server domains as workgroups.
Another way to handle the integration of these environments is to configure the LAN Server as a workstation. A WinFrame server can connect to stand-alone LAN Server 4.0 servers or to LAN Server 4.0 servers participating in a LAN Server 4.0 domain. LAN Server 4.0 and WinFrame servers cooperate because they both use server message blocks (SMBs) to communicate between the redirector and the server software. The NetBEUI frame (NBF) and TCP/IP protocols used by WinFrame are also able to work with NetBEUI and TCP/IP protocols written for LAN Server 4.0. LAN Server 4.0 servers can act as backup domain controllers in a WinFrame server domain. Both local and global user accounts are replicated to LAN Server 4.0 servers acting as backup domain controllers. Because LAN Server 4.0 doesn’t support trust relationships or local groups, a LAN Server 4.0 server can never be a primary domain controller.
UNIX You’ll find many approaches to utilizing the services of a UNIX server in a WinFrame domain. WinFrame and Windows NT are naturally able to talk to a UNIX server because of the networking tools built into the operating system. By loading the TCP/IP protocol and the associated tools, such communication is very easy. Some of these tools, such as Telnet, FTP, Gopher, DNS, DHCP, TCP/IP Print services, and SNMP, allow you to connect to a server, browse and transfer files, print to and from a UNIX server, and even manage the server and its network resources.
WinFrame com-municates with UNIX through built-in networking tools.
UNIX shines when it comes to server applications with data. Many SQL applications use a UNIX server to store the data. Most SQL engines have a compatible client for Windows NT so that the application front end can sit on a 32-bit Windows client while the data, and in some cases the logic, sit on the UNIX server. (See the “Two-tier client/server” section in Chapter 2, starting on page 30, for more information about multitiered applications.) In many cases, this works well until the company spreads out and the bandwidth is consumed, in which case the application then slows down. WinFrame has solved this problem in many instances. By placing the client on a WinFrame server, the client and the server can always be next to each other. The user logs on to the WinFrame server with a thin-client/server device or software client, and very little information traverses the thin pipe. This setup saves a lot of money that would have to be spent on either revamping the application or increasing the bandwidth.
You can run SQL on a UNIX server with the client on a WinFrame server.
Other UNIX applications are written to run completely within a UNIX environment. This restriction means that you need a UNIX server and workstation. To use such applications on a Windows client, you need a third-party application that will allow you to run a remote session. You can use a Windows-based Telnet application to emulate the required workstation mode, such as VT100 or X Windows. Many of these applications that are made to run on Windows NT or WinFrame, such as Hummingbird, PCXware, and JSB DeskView, let you configure the session for the needs of the UNIX application. You can also use Chameleon NFS, which gives you NFS server support for sharing and using UNIX drives. These applications also work well with a WinFrame server because they can use lots of bandwidth.
For databases specific to UNIX, use a terminal-emulation program on the WinFrame server.
Microsoft File Manager and Print Manager tools WinFrame allows you to run login scripts to configure a user’s environment from a Windows NT or WinFrame domain or from a NetWare server or NDS tree. These login scripts can be used to automatically map drives, configure printers, copy files, and start applications. The administrator can also choose to have users log on to a local network to set up their resource connections. When they connect to the WinFrame server, WinFrame automatically maps their Client Network drives and printers. The users, however, can control their own environments if the administrator wants them to. The two most powerful tools for exercising this control are Windows NT File Manager and Print Manager.
Run login scripts to automate drive and printer mapping on a WinFrame server.
File Manager and Print Manager are both graphical utilities used to configure, browse, and utilize network file and print services. WinFrame comes with clients for Microsoft Networks, NetWare Networks, and Client Networks.
NetWare Networks include both 3.x and 4.x bindery servers and NDS trees. The client network is controlled by the Client Network Service and allows the client to map a WinFrame session to the client machine’s local drives or network connections established before starting the session. Most other network resources will show up under Microsoft Networks, including Windows 95, LAN Manager and LAN Server, and Windows for Workgroups.