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:
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.
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.
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:
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:
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:
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.
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:
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.
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.
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:
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.
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).
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..
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.
