When using the intraNetWare Client for NT, many customers experience slow performance during login, printing, and file access. Many times, Novell's client is slower than Microsoft's client for NetWare. This TID addresses the several causes of slow performance. One solution or more of these solutions may be used to increase performance. Because all of these components are related, it is impossible to predict what performance gain a workstation will see.

Other technical information documents (TIDs) have been written about this issue. This TID does not contain all the information from each TID mentioned. This TID does provide a summary of issues related to slow performance with the intraNetWare client for NT.

Note: The intraNetWare Client for NT does perform well. However, reduced performance can result when loading multiple network clients and services. Additionally, NT's default configuration for name resolution will enhance the problem.

The most significant contributors to slow performance are as follows:

1-MUP mishandling UNC requests:
Microsoft's multiple UNC provider (MUP) does not pass requests asynchronously. Under certain common configurations, it may take as long as 25 seconds for the client to resolve a request for a NetWare server (if the name is not in cache), or as long as 30 seconds if the server name does not exist on the network. Because NT's MUP cache is cleared every 15 minutes, the MUP will need to relocate the NetWare server once the name has expired from the cache. (It may be helpful to reference TID# 2928430 for a more detailed explanation of why some requests made to NetWare file servers are slower than others.)

2-Unnecessary requests made by the intraNetWare Client for NT:
When obtaining a local file handle to associate with a NetWare file handle, Novell's CLNWIN32.DLL erroneously sends the server name "SPECIAL" to the MUP. This name is intercepted by each file system, and then is broadcast on the wire by each network provider. A packet trace of the problem reveals NBT packets requesting a server called SPECIAL ("NS: Query req. for SPECIAL" sent to the primary & secondary WINS servers and then eventually it was broadcast multiple times on the network). These requests for \\SPECIAL would take 15 or 20 seconds. The request is usually seen right after the request to "Open Stream" (open the login script).

Because this name is used internally, it does not need to be broadcast. It may take the workstation as long as 30 seconds to time out from this request.

3-NT machine configured as an H-Node:
(Note: This only applies if the workstation is using the Microsoft redirector.)
If a name is asked to be resolved by the Microsoft redirector, the node type determines how this name is resolved. If a UNC request is passed to the MUP, and the MUP does not have the computer name in cache, the name is broadcast through all redirectors.

When the name is passed to the Microsoft redirector it tries several methods of resolution. First is requests the name from the primary WINS server, if present. If the WINS server does not have the name registered, the redirector tries the secondary WINS server, if present. Each WINS server request takes approximately 2 seconds to return a response. If either WINS server does not have the computer name in the database, the redirector then broadcasts 4 Netbios requests, taking 4 seconds each, in an additional attempt to resolve the name.

1 - MUP.SYS mishandling UNC requests:
Obtain the latest MUP.SYS from Microsoft. Reference document Q171386 when requesting this file. A hot fix has not been generated for this file, but should be available in the next service pack. Then promote the NetWare redirector by going to Control Panel, Network, Services, NetWork Access Order button, and promote NetWare Services to the top of the network provider list.

OR

Use Microsoft Service Pack 4.

This solution is acceptable, even for networks using a lot of Microsoft Networking. Because Microsoft's name resolution time can be extreme (up to 30 seconds), compared to Novell's name resolution time (usually 1 second), the change in speed for Microsoft networking will hardly be noticed.

2 - Unnecessary requests made by the intraNetWare Client v4.11a for NT:
Obtain CLNWIN32.DLL dated 7-10-97 or later. This dll is included in the patch to the 4.11a client called nt411p1.exe. To obtain this file, use the File Finder on http://support.novell.com.
*NOTE* This version of CLNWIN32.DLL applies ONLY to the 4.11a build of the client. It will cause problems with later revisions (eg. the 4.12 NDS for NT client) since they were written to different code bases.

OR use the NT client version 4.3 or later.

This fix will not impact performance as much as the other options listed.

3 - NT machine configured as an H-Node:
Configure the workstation as an P-Node. If a WINS server is implemented, in contrast to the H-Node configuration, the P-Node configuration will only query the WINS servers. If all WFWG, WIN95 and WINNT machines are using the WINS server, the Netbios broadcasts will not be missed because all the Microsoft machine names will be resolved.

The node type can most easily be changed by using DHCP. The node type is configured when the IP stack gets and IP address assignment from the DHCP server.

The Microsoft redirector's name resolution is time consuming when the MUP is looking for Netware server, a 3rd party server or if the server name does not exist. Switching the computer type from an H-Node to an P-Node is highly recommended when a WINS server is available.

Note: All of these solutions are interrelated, and depends on individual environments. As explained previously, not all environments are affected by poor performance. Any one solution may not be appropriate for your environment.

Understanding all the implications of these changes is beyond the scope of this TID, but the most useful information and facts are highlighted in this TID.