## MS BackOffice Unleashed

- Reasons for Integrating with Netware and UNIX
- Netware Integration Considerations
- File Sharing with Netware
- Print Sharing with Netware
- UNIX Integration Considerations
- File Sharing with UNIX
- Print Sharing with UNIX
- Distributed Processing with UNIX
- Summary

#
— 13 —

##
NT Integration with Netware and UNIX

One of the most unusual features of Windows NT is its built-in capability of integrating with computers that run different operating systems. Those familiar with the UNIX world may point out that UNIX had a series of utilities that are fairly standard across the various product families that enable you to communicate with other UNIX computers or computers that have these standard UNIX protocols. There are two areas where the integration found in NT is radically different from this standard communications protocol approach:

- The level of integration is much deeper. It involves the capability of logging on to these remote systems and treating the remote resources exactly as Microsoft network resources are treated. For example, the only way that you can tell which network a printer is connected to is if you look at the top of your tree view when you select that printer. The complex details of communicating with radically different systems is well hidden from the users.
- The baseline Windows NT package comes with the integration utilities for UNIX, Netware, and Macintosh environments built in. Although you can often find add-on packages for other computer environments that allows integration, Windows NT provides it as part of your basic cost. The only major environment that is an add-on is the IBM mainframe and AS/400 connectivity provided by the SNA Server in BackOffice.

This chapter covers the integration of Windows NT with the two major environments that you are likely to encounter in corporate networks: Novell Netware and the various flavors of UNIX. My goal is to provide an overview of the connectivity techniques. I also point out some architectural and integration considerations that you may have to consider. I treat each of these environments separately because the tool sets are different.

###
Reasons for Integrating with Netware and UNIX

Why bother integrating with Netware? Microsoft can take on and beat any competitor right? Well the current outlook for Windows NT is quite bright if you read all of the trade journals. It has a family of operating systems that run the same applications from large servers to small desktop workstations. Its operating systems run on a wide variety of hardware platforms from those using powerful Reduced Instruction Set Computer (RISC) technology to the common Intel PC. So why cooperate with Novell?

For one, Novell still has the largest market share in the PC server world. Its lead was larger just a few years ago when NT was being introduced. It was advantageous for those early sales personnel who were trying to get organizations to try this new product to be able to say that you could integrate these new servers with your existing servers without taking any great risk. Also, there are many environments that have to integrate with other computer environments over which the first set of administrators have no control. They may stay with Netware until the end of time and it is your job to interface with them.

Although Netware integration was Microsoft's way to enter into the PC server market smoothly, its UNIX integration strategy was aimed at letting them enter into the "real" server market with equal ease. Although there are still some shops that have and love their mainframes, most of the shops that were down sizing when NT was first introduced had adopted UNIX servers as their compute platform. Unlike Netware, which focuses its main efforts on file and printer sharing, NT also possesses a reasonable computer processing environment. Therefore NT was also designed to compete with the smaller UNIX boxes that were on the market. With recent advances in PC technology and the support for Windows NT provided on the DEC Alpha boxes, Windows NT can now be used by some of the largest and most powerful computers on the market.

Of course, there are die-hard Macintosh users out there who may feel offended by the fact that I am not including Macintosh integration in this chapter. My excuse for not doing this is that in BackOffice, I am focusing on the Windows NT Server product. The Macintosh integration was always more focused towards allowing Windows NT workstations to access Macintosh resources and vice versa. The Apple product line never really had a large server product that was a target for Windows NT Server.

So there are a number of good reasons why Windows NT has built in so many integration capabilities for dealing with the UNIX and Netware environments. Although much of it may have been strategic positioning on the part of corporate giants, it has some good side effects for users and administrators. It enables us to use expensive resources that are currently attached to these other networks. It also enables users on these systems to access a number of NT resources, thereby helping us to justify our resources. Finally, for administrators, it enabes us to form a unified computer environment (see Figure 13.1) that is easier to maintain and administrate.

FIGURE 13.1. Integrated computer environment.

###
Netware Integration Considerations

The good news about integration with the Novell Netware product family is that it is almost mindless. If it were totally mindless, this would be a really short section. However, there are a few things that you need to consider when getting up your interface with the Netware world. The considerations that I want to talk about in this section follow:

- Gateway or individual workstation access
- Protocols
- Frame types
- Sensitivity to NetBEUI

The first topic that I want to cover is the basic architecture of your Novell connection. Microsoft Windows NT provides you with two basic options for connecting to the Novell world as shown in Figure 13.2. The first option lets you share the Novell resources on your server and then share those shared resources with members of your network. This may be desirable if you have different local area network segments that you have to deal with. Perhaps you wish to isolate your NT network traffic from the Novell network traffic. You could accomplish this by putting two network cards in your server, one attached to each network. The Gateway service would be installed as an option under Windows NT networking (the Network icon under Control Panel). You would then access the desired Novell resources and share them back to the user community. You have to coordinate a gateway user ID and password with the Novell administrator to make this connection work.

FIGURE 13.2. Novell gateway versus direct connections.

The other option that you have for Workstations running Windows NT and Windows 95 is to simply connect directly from those resources to the Novell server. This direct connection is the simplest connection to set up. It does require that each of your users have accounts on both the Novell server and therefore both you and the Novell administrator (which could also be you) have to establish the appropriate groups and privilege sets. It does minimize network traffic in that you do not have to transfer all requests to the NT server and then out to the workstation requesting the information.

The next issue that you have to deal with is the communications protocol. The Novell world grew up with its own protocol set known as IPX/SPX. Back then, there was not a universally accepted local area network protocol set. The early network protocols were somewhat limited in their capabilities to be routed and perform more complex functions. The TCP/IP protocol set was being developed, but it was rather complex for the early PC computer networks at the time. It probably would have been too demanding on early PCs. Therefore, Novell came up with its own suite that works well.

However, it is not the industry or Microsoft standard. The industry (that is, the Internet) favors the TCP/IP suite. The Microsoft network world grew up with the NetBEUI protocol. The NetBEUI protocol set works well for simpler functions, but it cannot be routed nor does it support tasks such as client server database access well. For purposes of our discussion here, it also does not work with Novell servers. Novell is offering increased support for TCP/IP in its products, but the bulk of Netware installations use IPX/SPX. Therefore, if you want to play in the Novell server world, you pretty much have to adopt the IPX/SPX protocol set. Complaining about this protocol is pretty much like complaining about SNA in the mainframe world—it doesn't do you much good.

It's easy to use IPX/SPX under Windows NT and Windows 95. As a matter of fact, it is usually one of the default protocols that you will see in your installation process. Once you select the protocol, all you have to make sure of is that you pick the appropriate service (gateway or Netware link). This protocol cooperates well on Microsoft networks and I have not seen it cause any problems for the other protocols selected.

You may have to adjust some of the settings for the IPX/SPX protocol occasionally—for example, one setup parameter for the IPX/SPX protocol that I have observed some sensitivity to in the Netware world is its frame type parameter. The frame is a construct that wraps around the content of your message to facilitate transmission across the network. It is one of those details that is normally reserved for network design types. However, I have noticed several Novell networks that used the 802.3 (ethernet) frame type that could not communicate well with NT workstations that used the default setting for frame type (auto detect). We had to switch the setting under the IPX/SPX protocol on the Network utility on Control Panel (see Figure 13.3) to have a frame type of 802.3 and everything worked well. Be aware that you may have to adjust some of the advanced settings to allow your workstations and servers running Windows NT to be compatible with other devices on your network.

FIGURE 13.3. Setting the frame type for IPX/SPX.

The final little note that I can offer you is that I have seen some Novell networks that are really sensitive to the presence of the NetBEUI protocol on which many Microsoft networks run. We had a network that was working quite well with NetBEUI and Netware co-existing, and then they performed an upgrade of the Novell network. We started using a new network card in the server and a few other network changes, but we could not even get our machines to talk to one another. Our solution, achieved by trial and error, was to eliminate the NetBEUI protocol from our Network. It was easier than getting the Novell folks to change and Microsoft networks will work well as long as they have just one common protocol (IPX/SPX). Although this was not an elegant solution, it did minimize the amount of work that was needed, and we were able to get everything done without changing our hardware or implementing complex software solutions. (The joys of a flexible, modern operating system.)

What I thought that I would end this section with are a few other miscellaneous thoughts to consider:

- You might want to work with the Novell administrators to establish common group names and other similar integration issues. Who knows, you may have to take over Novell users one day if your company likes NT a lot.
- A common response center is helpful where you have both Netware and NT working together. You can try and explain to users until you are blue in the face which resources are yours and which ones are supplied by the Novell people, but they will still come to you if you are their primary care giver.
- You might want to set up with the Novell administrator to have the utilities and permissions to monitor one another's systems. For example, if a print job intended for a Novell printer appears to be stuck, it would be helpful if you could run the Novell printer control utility to see what is going on.

###
File Sharing with Netware

Once you have gone through the initial setup and resolved any problems (which are actually quite rare, I was just lucky to run across the ones that I describe previously), it is actually easy to access Netware file resources. Windows NT and Windows 95 appear to the Novell servers just like traditional Netware clients. They play all the games by Novell rules.

You are somewhat limited in that you cannot share resources using Novell except on the server. They do not share workstation directories as we can under NT. However, you have whatever access privileges that your Novell logon ID commands when you attach to one of their servers. The privileges include all of our favorites such as read only, change and full access.

So what do users see when they try to access a Novell shared directory resource? Well, they see their traditional File Manager, Network Neighborhood, or Windows Explorer display. If they have set themselves up for Netware networking, they will have another option at the root of their directory trees that lets them access resources on the Novell network. There are no visual differences for the user when accessing Novell shared directories. You have to know what the resource is called and on which server it is located. If you were not paying too much attention when you first started down the directory hierarchy, you might not even notice that you are on Novell networks (unless you see a lot of share names such as system, volume1, and so on, which are traditional on Novell servers).

There are a few considerations with Novell file sharing that you should keep in mind:

- The network segments on which the Novell servers reside could be much busier than your segments.
- You may have lower bandwidth connectivity to remote Novell sites. This could make transfers to these locations take longer than those you would experience on your network.
- The Novell administrator may enforce different password conventions such as aging, complexity, and so on. You may want to coordinate these conventions so that users can have a single password and user ID that works both for the Novell networks and the Microsoft networks.

###
Print Sharing with Netware

A good reason to interface with the Novell world, especially when NT is new in the environment, is to get access to all those expensive printers that are located on the Novell network and scattered around the building. The great thing about Novell printer access is that it, again, tries to give the user exactly the same interface as they are used to when accessing Windows NT network resources. There are a few printer connectivity options that you might want to be aware of in the Netware environment. Figure 13.4 shows the three basic configurations.

FIGURE 13.4. Basic Netware printer configurations.

The first configuration is where the printer is connected through a traditional printer cable to the Novell server. The Novell server provides the printer queue that sequences the print jobs. This print server process has a control utility (printcon) that can be used by people with the appropriate accesses to start and stop the queue, to remove jobs from the queue, and so on. It is not as convenient as the NT printer control utilities, but it accomplishes a similar function and gets the job done.

The second Novell printer configuration uses a printer queue on the Novell server and a printer that is attached directly to the local area network. This is similar to network attached printers under NT. The key is that you have to access the printer controls for the server that is maintaining the print queue in order to control printing on this printer. This configuration allows a lot of flexibility for placing printers throughout your building.

The final configuration is a step back to the early days when network connected printers were either too expensive or just not available. It uses a PC (usually an older model) that acts like a miniature Novell server by running a print spooling process. This process runs under DOS as opposed to the real Novell server operating system. It gets the job done and was an option to get printers to remote parts of the building that were far away from the servers.

With this introduction behind us, all I have left to say is that connecting to Netware printers is just like connecting to Microsoft network printers. You go under the printers option in Control Panel and select the option to add a printer. Follow through the setup wizard panels, selecting a network printer as opposed to a local printer. When you browse the network to find your printer, you will see the Novell printers (assuming that you have set yourself up for Novell networking and logged in to the Novell network at start up). Select the one that you want and complete the driver specification panel that specifies the type of printer that you will be using. After that, it will appear as a valid printer in your list of printers and you may even forget to which network it is attached.

###
UNIX Integration Considerations

The integration of Microsoft networks with UNIX is not quite as easy as integration with Netware. That is not to say that it is difficult either. It is just that many of the ease of access paradigms that exist in the Netware and NT worlds were just never used in the UNIX world. The still access disks in much more of a static link fashion. They do not advertise the services that they provide in the same way that PC network servers do. However, there are ways of getting at their data and computing resources. You can co-exist quite well in the UNIX world.

Figure 13.5 shows some of the basic techniques that I want to discuss with regard to integration with the UNIX environment. There are four basic connectivity utilities that are provided under Windows NT:

- Telnet terminal connections
- File transfer protocol
- LPR/LPD printing
- Remote procedure calls

FIGURE 13.5. NT integration with the UNIX environment.

There is one important file sharing tool from the UNIX world that is not supported in the basic Windows NT package. UNIX has its own version of directory sharing known as the Network File System or NFS. Originated by Sun Microsystems, it is supported by almost all the popular UNIX systems that are out there, although some still require you to purchase it as a separate product from the operating system. In the NT world, there are NFS products available from third-party vendors, but not currently from Microsoft.

I am hesitant to recommend any one NFS vendor in the Windows NT world. They are still relatively young products, although they are often ports of packages that have existed for some time in other computer environments. New products tend to leap frog one another in terms of performance and capabilities. Therefore, I would recommend that you check out the products that are currently on the market if you need to use NFS. With the ready access to the Web, it is easy to look up product information and you can often download trial versions of products for in-house testing.

The first issue to address when working with UNIX integration is that of the protocols used. In terms of the basic communications protocol, that is almost always TCP/IP when dealing with the UNIX world. They tend not to support the wide range of protocols that are found in the PC world. Also, many people in the field feel that they are better founded by working only with a protocol that is a vendor neutral international standard. That's OK, NT works well with TCP/IP so you can adapt to the needs of the UNIX world.

There are a series of higher level functional protocols that you will be dealing with for connectivity. These include telnet, FTP, LPR/LPD, and RPC. How's that for a series of acronyms? The key is now in knowing the internal details of how messages are built using these protocols. That is what the software and network engineers get paid to do. All you have to know is what they can do for you and when you want to use them. Anyway, let me give you the basic translation of these protocols.

- Telnet is a basic protocol for terminal emulation across a network to log on to a remote computer's command line.
- FTP stands for File Transfer Protocol. It is a standard that enables you to send (put) and receive (get) files to and from a remote computer via the network.
- LPR/LPD stands for Line Printer Requester/Line Printer Daemon. It is a pair of protocols that lets the requester transmit jobs to the print server.
- RPC stands for remote procedure call. It is the UNIX tool for starting a job on another computer similar to the remote command server in the Windows NT Resource Kit.

Another integration concept that you need to master is that of the server process and the client process. UNIX boxes have been multiprocessing since their creation. They tend to think of computing as having a large series of specialist processes running at the same time to split up the work load. When you look at a UNIX system that has almost no users logged in to it, you will still find dozens of processes running. These processes were often designed separately by different design teams and have little knowledge of one another. This is in contrast to Windows NT's integrated approach to the operating system. Anyway, you will find that most of these utilities are designed to have both a server process that allows other computers to access your resources and a client process that enables you to access the resources of other computers. The key is that the remote server is a separate process in the operating system that must be running for you to complete your connection. Figure 13.6 illustrates this basic concept.

FIGURE 13.6. Server and client processes for UNIX networking services.

###
File Sharing with UNIX

Your basic tool for file sharing between UNIX and Windows NT is the File Transfer Protocol. It is a simple command-line utility where you specify the IP address or alias for the server to which you want to connect. You then can issue one or more of the following commands to interact with the remote file system:

- ascii—this instructs to send only characters that are in the ASCII character set, performing any translations as needed. This deals with the fact that operating systems have different internal representations for characters (EBCDIC for IBM mainframes, for example) and a neutral standard is needed for communications. This will transfer text files, but it will not transfer binary, executable files.
- bell—toggles on and off the bell sound for those of use who like to keep things nice a quiet.
- binary—the opposite of ASCII. This sends the internal binary representation of characters over the telnet session. It usually requires a compatible computer and operating system on the other end for the files to be understandable.
- cd—change the remote directory to the directory specified by this command. It allows you to move around as you would in the DOS/Windows file system with the exception that UNIX systems use forward slashes as opposed to backslashes in their directory hierarchy (/usr/bin as opposed to c:\winnt\system32, for example).
- delete—enables you to delete the single file specified in this command from the remote system.
- dir—lists the directory on the remote computer. This is not normal FTP, but is provided for the DOS/Windows types who are used to this command.
- disconnect—terminates your FTP session with the remote computer.
- get—transfer the single file specified from the remote computer to your local computer.
- help—provide a list of commands. You can enter help plus one of these commands to get a very brief description of the command.
- lcd—change your local directory (the computer at which you are sitting) to the directory specified.
- ls—provide a listing of files in the directory specified on the remote computer. If not directory is specified, you will get the list of files in the current directory on the remote computer.
- mdelete—deletes multiple files on the remote computer that match the criteria specified (*.txt, for example).
- mget—transfer multiple files from the remote computer to the local computer that match the criteria specified.
- mkdir—create a new directory with the name specified on the remote computer.
- mput—transfer multiple files from the local computer to the remote computer that match the criteria specified.
- open—connects the user to the remote computer specified. You will be prompted for your user ID and password.
- prompt—many FTP commands are designed to ask you whether you really want to take certain actions (in a multiple file copy, for example, you would be asked about each file). This command toggles the prompting on and off for these commands.
- put—sends the single file specified to the remote system.
- pwd—lists on the screen the current working directory on the remote system.
- quit—terminate the FTP client process.
- rename—enables you to change the name of the file specified on the remote server to a new value.
- rmdir—deletes the directory specified on the remote server.
- verbose—many FTP commands can give you short and to the point feedback or tell you about all of the details. This commands toggles the detailed discussions on and off.

Let me give you a brief example of an FTP Session. Here I connect to a remote server, show you the basic directory listing command, show the basic directory listing command with the long option and then download on of the files from the server to my local directory (by the way, UNIX is case-sensitive, and lowercase is much more commanding than uppercase in commands and filenames):

    c:\ ftp unix1 jgreene/hithere

    Connected to unix1.

    220 unix1.

    User (unix1:none)):jgreene

    Password:

    230 jgreene user logged in

    ftp> ls

    200 PORT command successful.

    150 Opening ASCII mode data connection for file list.

    SQLNET.ORA

    TNSNAMES.ORA

    226 Transfer complete.

    26 bytes received in 0.06 seconds (0.43 Kbytes/sec)

    ftp> ls -l

    200 PORT command successful.

    150 Opening ASCII mode data connection for /bin/ls.

    09-28-95 05:56AM 116 SQLNET.ORA

    06-19-96 04:55PM 1831 TNSNAMES.ORA

    226 Transfer complete.

    104 bytes received in 0.05 seconds (2.08 Kbytes/sec)

    ftp> get sqlnet.ora

    200 PORT command successful.

    150 Opening ASCII mode data connection for sqlnet.ora(116 bytes).

    226 Transfer complete.

    116 bytes received in 0.27 seconds (0.43 Kbytes/sec)

    ftp>

Some key points to remember about FTP:

The server has to be running the FTP server process for you to be able to connect to it.

IIS provides an upgraded version of the basic FTP server provided with NT. Think of this as a more rugged version that is designed to handle the potentially large loads of an Internet-connected and very popular server.

The FTP tools think like engineers and computer network types. They require you to know a set of aliases or IP addresses. There is no simple advertising service that lets you pick from a list of available computers. This would be a very long list for computers connected to the Internet (probably in the hundreds of thousands if not millions), so I guess that it is just not practical in this case.

There are a number of third-party FTP tools (such as those from Delrina as part of their CommSuite product) that enable you to have a graphical version of FTP. Some of us grew up with the command line, but others might find it to be a bit of a step backwards.

###
Print Sharing with UNIX

Printers can be expensive resources on your computer networks. You have to scatter them throughout the building to make the close to the users. You may also have to provide a number of specialty printers such as color printers, large size plotters, and duplex printers. The UNIX utilities to connect to a remote printer are rather simple. You have the line printer requester who sends out the jobs and the line printer daemon who receives the job and transfers them to the appropriate local print queue.

To identify a printer on the remote system, you need to specify both the remote system alias or IP address and then the name of the remote print queue. In Windows NT, you also have to install the TCP/IP printing option. It is provided with the basic Windows NT distribution, but it is not one of the default products installed. Anyway, it is a relatively simple system to configure. You also have all your normal Windows NT printer access (it becomes a shared printer on your server that NT people access like any other shared printer).

###
Distributed Processing with UNIX

The UNIX standard for distributed processing is the Remote Procedure Call (RPC). Again, the format is relatively simple in that you specify the name of the remote server along with the procedure to execute. For this function to work, you need to have the Remote Procedure Call server running on the remote machine. This is not heavily used in my experience, but you should be aware of it when you plan to start processes on other machines that support RPC..

###
Summary

This chapter has gone over the basics of connecting to the Novell Netware and UNIX environments. It did not cover all the possible options that you might use based on your individual situations. Instead, it focused on the issues that you will need to think about and the various options that are available to you. The interesting feature is that most of this connectivity to other vendor's environments is provided as part of the basic Windows NT operating system. There are third-party products that try to improve on this baseline which you may investigate as time permits.