Troubleshooting Win2K and NetWare Interoperability
Getting networks to play well together isn't always as easy as it should be -- especially when you may have inherited one as the result of a merger. Written from the perspective of a Windows networking manager, we take a look at how to get Novell and Microsoft networks to co-exist and provide transparent services for users.
I have received a lot of letters from readers who've been through corporate mergers involving one company buying another. In many of these situations, the administrators are asked to make two totally dissimilar networks work seamlessly together. In this article, I'll address some of the problems that you might encounter when trying to make a Microsoft Windows 2000 network interoperate with a Novell NetWare network.
There are several different ways to join NetWare and Windows networks. The most popular solution by far is Microsoft's Gateway (and Client) Services for NetWare (GSNW) because it comes free with Windows, and because you can attach thousands of Windows users and only use one NetWare client access license. (Novell offers a similar product that makes a Windows server appear as if it were a NetWare server.)
|"When you're troubleshooting problems on a network that you didn't help design, don't take anything for granted."|
For the purposes of this article, we will assume that you're using GSNW and the associated client, and that your goal is to be able to share file and print resources across the two networks. We will further assume that you've used Gateway (and Client) Services for NetWare to join the two networks, and that you've been able to establish at least some level of communications between them. However, even after basic communications have been established, there are still lots of problems that can prevent users from seamlessly accessing both networks, and we will address those specifically.
One of the most frequent problems is when the two networks are functioning well, and suddenly Windows users stop being able to access the NetWare servers. There are a number of things that can cause this. The nature of GSNW is to use a single Windows user account for all Windows clients to access NetWare resources. Therefore, this makes for a single point of failure and means that the first place that you should look is the gateway account itself.
Make Sure GSNW Is Logged In
If communications were partially or fully functional at one point, then something has to have happened to have caused them to cease. If none of the servers in question have been rebooted recently, the problem could be that login time restrictions were accidentally placed on the gateway account, and the gateway account was forced to log out. It's also possible that another administrator could have inadvertently disconnected the gateway account from the Netware server or even accidentally deleted the gateway account. These situations may seem far-fetched, but I've seen them happen and they're worth looking into.
Alternatively, the gateway account's password may have expired, or the gateway account may have been accidentally removed from the NTGATEWAY group on the NetWare server. There's also another cause that tends to be a bit more elusive: As a Windows administrator, it's easy to get used to the Per Seat method of licensing in which the server simply assumes that each client has a valid client access license. However, NetWare's license is based on how many users are concurrently logged in. If all of the NetWare server's licenses are in use when the gateway account tries to login, none of the Windows clients will be able to access the NetWare server through the gateway.
Of course, problems can also occur on the Windows 2000 server that's acting as the gateway. Be sure to check if the Client Services For NetWare service or the NWLink protocol were somehow uninstalled. Having the gateway account's password expire on the Windows server could also cause problems.
Check the Gateway Account
So far, I've dealt with situations in which communications were working well and then came to a grinding halt. However, not all problems are quite so simple. Sometimes, you may encounter a situation in which Windows clients can gain partial access to a NetWare network, but can't access everything that's necessary.
In such a situation, the first place that you should check is the gateway account. You know that the gateway account is functional because Windows users are getting partial access to the NetWare network, but there's a chance that the gateway account may have insufficient permissions to the NetWare network. Therefore, the first step in the process is to assure that the gateway account does indeed have access to the desired resources.
If you've double-checked the gateway account's permissions, but you're still having problems, the problem may be caused by some sort of communications mismatch. Keep in mind that many administrators come from a pure Windows background and may be used to running TCP/IP or NetBEUI exclusively. However, the Client Services for NetWare depend on the Windows server running the NWLink protocol. The NWLink protocol is the Windows equivalent to NetWare's IPX / SPX protocol. In a situation in which communications are only partially functional, you might take a closer look at the NWLink configuration.
The IPX / SPX protocol relies on something called a frame type. Frame types are unique to IPX / SPX, so administrators that have always dealt with TCP/IP or NetBEUI may never have been exposed to them. Without getting into a long discussion, they help define the physical network medium. There are four different frame types that can be used with IPX / SPX, including Ethernet 802.2, Ethernet 802.3, Ethernet II, and Ethernet SNAP. In an IPX / SPX environment, servers can't communicate with workstations or other servers unless they share a common frame type. By default, the NWLink protocol is designed to automatically detect the frame types that exist on the network. However, there are situations in which the auto-detection process doesn't completely work.
One such situation involves multiple frame types being installed on the network. For example, suppose that the NetWare server that your gateway server links to has the 802.2 and the 802.3 frame types installed. Now, suppose that the other servers on the network had only one of those two types installed. All of the NetWare servers would be able to communicate with each other because there is a common frame type. However, NWLink may sometimes only detect one frame type or the other and thus would only be able to communicate with some of the NetWare servers.