Delays Connecting to NetWare Servers in Mixed Network

This article was previously published under Q194827
This article has been archived. It is offered "as is" and will no longer be updated.
IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:
256986 Description of the Microsoft Windows Registry
When you are working in a mixed network server environment, connecting toNovell NetWare servers (using Novell's IntraNetWare Client [Client32]version 2.2) and to Microsoft Windows NT and other SMB-based servers(using Microsoft's Client for Microsoft Networks), connecting to a NetWareserver may sometimes take a long time.
This problem can occur if all of the following conditions exist:

  • TCP/IP is used to connect to Microsoft Network servers.
  • The IPX/SPX-compatible protocol and Novell's IntraNetWare Client 2.2 are used to connect to NetWare servers.
  • Domain Name Service (DNS) is used to resolve TCP/IP network names.
  • The NetWare server is running TCP/IP in addition to the IPX/SPX- compatible protocol.
  • The NetWare server's TCP/IP address is registered with the DNS server, with a DNS name identical to the NetWare server name.

Under these conditions, Windows attempts to resolve the server name firstusing the NetWare network client, then using the Microsoft Networkingclient. When the NetWare server does not respond to the request to resolvethe server name using Service Advertising Protocol (SAP), the MicrosoftNetworking client attempts to resolve the name using DNS. Because theNetWare server is registered with the DNS server, the DNS server may beable to resolve the NetWare server name sooner than the NetWare serveritself can respond to the SAP request.

If this behavior occurs when the conditions listed above exist, the NetWareserver name may be incorrectly marked as a Microsoft (SMB-based) servername when it is saved in the local registry. Subsequently, attempts toconnect to that server name refer to the information stored in the registryand use the Microsoft Networking client first, and try to connect using theNetWare client only after the first attempt times out. Because of thelength of the time-outs specified for DNS name resolution and TCP/IPconnection operations, it may take one minute or more for the first attemptto connect to the NetWare server to time out, after which Windows tries toconnect using the NetWare client.
WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

You can work around this issue by using any of the following methods:

  • Use the Microsoft Client for NetWare Networks to connect to NetWare servers, instead of the Novell IntraNetWare Client. (Upgrading the Novell IntraNetWare Client may also resolve the problem causing slow responses to SAP requests.)
  • Do not register the NetWare server with DNS with a DNS name identical to the NetWare server name.
  • Edit the registry value for the incorrectly cached server name entry so that it is correctly recognized as a NetWare server instead of a Microsoft Networking (SMB-based) server.

    These values are located under the following registry key:
    This key contains a number of values with names of the form "Key<####>" where <####> is a number from 0000 through the maximum number of cached server names.

    1. In Registry Editor, locate this key and these values, double-click each value in turn, and examine the value data. Do not make any changes to the value data.
    2. When you identify the value containing the name of the server that you are having trouble connecting to, note the numeric portion of the value name (Key<####>).
    3. In the same registry key, locate the value with a name of the form "Data<####>" where <####> is the numeric portion of the Key<####> value from step 2 above. Each of these values contain four bytes of data, represented as four pairs of hexadecimal digits. Note the value of the third of these four pairs. The value of this byte indicates which networking client is associated with this server name. A value of 02 indicates a Microsoft Networking server. A value of 03 indicates a Novell NetWare server.
    4. If the server type in the Data<####> value is incorrect (02 instead of 03 for a NetWare server), double-click the Data<####> value to edit its value data. Double-click the third pair of digits to select it, type 03, and then click OK.
    5. Quit Registry Editor and restart Windows for the change to take effect.
    Once a server name is cached correctly, it will not normally change to an incorrect value.
  • A supported fix for Windows 95 and Windows 95 OEM Service Release 2, 2.1, and 2.5 that corrects this problem is now available from Microsoft, but has not been fully regression tested and should be applied only to computers experiencing this specific problem. To resolve this problem immediately, contact Microsoft Technical Support to obtain the fix.

    This fix for Windows 95 (retail release) should have the following file attributes (or later):

          File name    Version    Date       Time     Size      --------------------------------------------------------      Vcache.vxd   4.00.950   11/18/97   7:58pm   19,590 bytes						

    This fix for Windows 95 OEM Service Release 2, 2.1, and 2.5 should have the following file attributes (or later):

          File name    Version     Date       Time     Size      ---------------------------------------------------------      Vcache.vxd   4.00.1111   10/31/97   4:09pm   41,752 bytes						

    This fix allows the Server Name cache to be disabled entirely, if the following registry value is set to a data value of zero:

          Key:   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\                 VCACHE\Lookup\ServerNameCache      Value: MaxElements      Data:  00 00 00 00   (to disable Server Name Cache)						

    The package that installs this hotfix automatically sets this registry value to zero to disable the Server Name cache.

    With this value set to zero, the Server Name cache is not used when resolving network server names, and new entries are not added to the Server Name cache as server names are resolved.

This functionality is included in Microsoft Windows 98, and can be enabled by setting the "MaxElements" registry value to zero, as documented above.

Microsoft has confirmed this to be a problem in Microsoft Windows 95 andOEM Service Release 2 (OSR2).
More information
This issue is documented in the Novell Knowledge Base as document 2929988,"Slow Client Performance Due to DNS Query." The Novell Knowledge Base canbe accessed from the following Internet location:

The third-party contact information included in this article is providedto help you find the technical support you need. This contact informationis subject to change without notice. Microsoft in no way guarantees theaccuracy of this third-party contact information.

For additional information about Windows 98 and Windows 98 Second Edition hotfixes, click the article number below to view the article in the Microsoft Knowledge Base:
206071 General Information About Windows 98 and Windows 98 Second Edition Hotfixes
For additional information about Windows 95 hotfixes, click the article number below to view the article in the Microsoft Knowledge Base:
161020 Implementing Windows 95 Updates

Article ID: 194827 - Last Review: 11/01/2013 22:52:00 - Revision: 2.0

Microsoft Windows 95

  • kbnosurvey kbarchive kbhotfixserver kbqfe kb3rdpartynetclient kbnetwork kbprb KB194827
ERROR: at System.Diagnostics.Process.Kill() at Microsoft.Support.SEOInfrastructureService.PhantomJS.PhantomJSRunner.WaitForExit(Process process, Int32 waitTime, StringBuilder dataBuilder, Boolean isTotalProcessTimeout)