Does your network run both Microsoft Corp.’s Windows NT and Novell Inc.’s NetWare network operating systems? If so, you may find that your network is congested because of the extra traffic that comes from running multiple network operating systems. And the performance of network workstations may also suffer a negative impact. In this article, I’ll discuss the Gateway Services for NetWare (GSNW) that comes with Windows NT. As I do, I’ll explain why implementing GSNW can help your network perform better, and may even save your company money. I’ll also discuss circumstances when it’s better not to use a gateway.
What is GSNW?
Gateway Services for NetWare is a native Windows NT service that lets NetWare-deaf clients access a NetWare server. Even if a client has only a Microsoft Network client loaded, it can access files on a NetWare server by logging into a Windows NT server that’s running this special service first. There’s no magic behind the way GSNW works–it’s actually quite simple. As you may know, Windows NT Server can function both as a server and a workstation. Because of its ability to function as a workstation, users can log into a Windows NT server and access resources on a NetWare server. GSNW expands on this simple idea. GSNW authenticates into a NetWare server as soon as the Windows NT server is brought online. Once running, GSNW treats the connection to a NetWare server in a similar manor to a local resource, such as a hard disk partition. As a result, Windows NT is free to distribute access to the NetWare server via a Windows share point.
Advantages of using Gateway Services for NetWare
Obviously, there are certain advantages to using such a powerful service. Under normal circumstances, Novell requires a client license for every computer that logs into a NetWare server. Microsoft claims that because GSNW consumes only one connection, legally you need only one client license to the NetWare server. As you can imagine, if you accept this way of thinking, you can save a considerable amount of money by not buying multiple NetWare client licenses. If your conscience gets the better of you, you can enforce your NetWare client license limit through the gateway. As I mentioned earlier, GSNW attaches clients to the NetWare server via a Windows NT share point. After establishing the NetWare gateway, you manually tell Windows NT where you want each share to point. At the same time, you can use a radio button in the same dialog box to limit the number of clients allowed to simultaneously access the share point. You can either choose to allow an unlimited number of clients to use the share point, or limit access to the number of NetWare client licenses you have.
Reduced memory and overhead requirements
As you might imagine, reconfiguring your network to use GSNW can be quite a chore. Thankfully, this hard work has benefits besides a questionable licensing technicality. One such advantage is the lower memory requirements and processing overhead on the client machines. As you may recall, in the days of DOS, it was practically impossible to load a NetWare client and a Microsoft network client into memory and still have enough free memory to run a program. As a result, most of the time, businesses with multiple server platforms had to choose whether clients could access one or the other. Although this limitation may seem to be a non-issue in the days of Windows 98 and Windows 2000, a frightening number of businesses still use DOS. Even with all the new operating systems that have been released in the last several years, many of these businesses continue to use DOS because of its stability. (The rationale I hear most often is, “If DOS has been working flawlessly for the last 15 years, why change now?”) GSNW has advantages for the rest of us non-DOS users, too. As I mentioned, running GSNW means that clients only need to have one network requester installed. As a result, clients such as Windows 98 have less overhead than if they had to juggle between two clients–and more memory and processing power are available for the applications, because less are being used by the operating system. Having fewer operating system components running simultaneously means that the chances of Windows crashing is slimmer.
Enhanced consistency
Another potential advantage of using GSNW comes into play on the administrative side. As you probably know, network problems tend to be much easier to correct if your network has some level of consistency. By having all NetWare users access the NetWare servers via the gateway, you instantly know where to look for a problem, should something go wrong.
Disadvantages of using Gateway Services for NetWare
After all the points I’ve made so far, it may sound as though you should immediately load GSNW without another thought. However, this isn’t necessarily the case. Running GSNW has some potentially significant disadvantages, particularly from the security and performance standpoints.
Performance reductions
Performance may or may not be an issue on your network depending on several factors, including such things as:
- The number of network users
- How many NetWare servers you have
- What kind of hardware your servers use
- What those servers are used for (perhaps the most important factor)
The reason is that once you implement GSNW, all traffic destined for a NetWare server will pass through a Windows NT server to get there. As a result, the Windows NT servers must handle their own workload, plus much of the workload normally carried by the NetWare server. The problem is compounded if a single Windows NT server controls a gateway to multiple NetWare servers. Having a single Windows NT server controlling a gateway to multiple NetWare servers doesn’t have to be a big deal. If the Windows NT server is a dedicated gateway and the NetWare servers are only used for routine file sharing, you probably won’t have many problems, as long as your hardware is sufficient. However, if any of those NetWare servers normally experience a high volume of disk access, or if the Windows NT server is used heavily for other purposes, running GSNW may not be the right choice for your network.
Minimizing bottlenecks
Just because one or more of your servers has a high volume of disk activity doesn’t necessarily mean you have to give up on implementing a NetWare gateway. You can take some steps to minimize the impact of the gateway’s bottlenecks. One of the best things you can do is to place the Windows NT server and the NetWare servers on a separate LAN from the workstations. As you might recall, Windows NT is capable of using two or more network cards and routing traffic between them. Simply connect one network card to the same hub your workstations are attached to. Connect the other network card to a different hub, and plug the NetWare servers into this hub. At minimum, the hub that connects to all the servers should run at 100Mbps. It would be nice to have high-speed hubs for the rest of the network as well, but it’s more important for the servers to be attached to high-speed hubs than for the workstations to be. Isolating the servers on separate networks limits the amount of traffic that must flow across each network and improves productivity. For example, the protocol of choice for most Windows NT networks is TCP/IP, primarily because TCP/IP is routable and is the protocol required for Internet access. NetWare networks use the Internetwork Packet Exchange/Sequenced Package Exchange (IPX/SPX) protocol. On a network that contains both NetWare servers and Windows NT servers but no gateway, every client must use IPX/SPX and TCP/IP. Therefore, the network quickly becomes congested with traffic, because most machines send every transmission twice (once for each protocol). By segmenting your network, you cut the amount of network traffic in half. The TCP/IP traffic is isolated to the workstations and the IPX/SPX traffic remains on the server side. The only machine that runs both protocols is the gateway Windows NT server. Even on this machine, the protocols can be isolated by adjusting the bindings between the network cards and the protocols.
Security issues
Another issue to consider when implementing the GSNW is security. GSNW essentially does away with any security on the NetWare server, because the gateway uses one user account to access the NetWare server. This account usually has administrative privileges on the NetWare server. Therefore, any user who authenticates to the NetWare server via the gateway will have the same permissions as the gateway account. The only real way to get around this problem is to create multiple gateway share points. You can establish read-only access, full access, or no access to each share point. If some users need to have read-only access to a directory, whereas other users have full access or no access, you can create a single share and set the permissions through Windows NT. The real problem comes in setting access to subdirectories. For example, suppose that you have a directory called accounts. Now, suppose that beneath the accounts directory, you have directories called A, B, and C. If the share point points to the accounts directory, then users will have the same rights to any subdirectories beneath accounts that they have to the accounts directory. For example, if a user has full access to accounts through a gateway share, then they automatically have full access to A, B, and C. The only way to prevent this access would be to create a share for A, another share for B, and still another share for C. You could then set the appropriate rights for each share. Although this may sound like a viable solution, it typically results in an excessive number of shares. This arrangement can be especially confusing if your users are accustomed to having a network drive letter mapped to each available share. Another problem results from overlapping permissions. In another example, suppose that your NetWare server has the directory structure I used in the previous example. Now, create separate share points for accounts, A, B, and C. If a user needs read-only access to everything and needs full access to B, you might think that the easy way to set his access is to grant read-only rights to accounts and let those rights propagate to the subdirectories. You can then grant full access to B. The problem with doing so is that you’re working with share permissions rather than NTFS permissions. As a result, if the user tries to access B through the accounts share, he will still have the read-only permission associated with the accounts share point. The only way for him to get full access to B is to go directly to the B share. As you can see, the permissions problems can be solved, but it may be difficult for the end users to get used to.
Conclusion
In this article, I’ve discussed the pros and cons of setting up a Windows NT gateway to a NetWare server. I then went on to discuss some other issues that you’ll face with performance and licensing if you do choose to establish such a gateway, and talked about solutions to some potential problems with Gateway Services For NetWare.
Brien M. Posey (Brien_Posey@xpressions.com) is an MCSE who works as a freelance technical writer and as a network engineer for the Department of Defense.
