DetailPage-MSS-KB

Microsoft small business knowledge base

Article ID: 257577 - Last Review: October 20, 2013 - Revision: 2.4

Hotfix Download Available
View and request hotfix downloads
 
This article was previously published under Q257577
This article has been archived. It is offered "as is" and will no longer be updated.

SYMPTOMS

If your program uses the gethostbyname function, the returned list of IP addresses may not include the virtual IP addresses created by the Cluster service, or it may list IP addresses that are not currently owned by this node.

CAUSE

When the Cluster service adds or removes a virtual IP address, the TCP/IP protocol does not update the cache from which it returns the IP addresses.

RESOLUTION

To resolve this problem, obtain the latest service pack for Windows 2000. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
260910  (http://support.microsoft.com/kb/260910/EN-US/ ) How to Obtain the Latest Windows 2000 Service Pack
The English version of this fix should have the following file attributes or later:
File name: Q257577_w2k_sp2_x86_en.exe
Version: 1.10.101.0
This package includes updated versions of:
Clusres.dll
Dnsapi.dll

STATUS

Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article. This problem was first corrected in Windows 2000 Service Pack 2.

MORE INFORMATION

In Windows NT 4.0, gethostbyname(local node name) returned a list containing all IP addresses instantiated on the server, including cluster virtual IP addresses. In Windows 2000, the same operation usually returns only the IP addresses that are permanently assigned to the server; however, it can sometimes return the entire list just like Windows NT 4.

The behavior change is a side effect of the implementation of the DNS resolver service. The resolver caches the list of local IP addresses at startup. When it is asked to resolve the local node name, it returns the list from its cache instead of consulting a DNS server. The problem is that the resolver does not listen for PNP address change notifications from the TCP stack, but it does receive these notifications from the DHCP client. When the resolver receives a change notification from DHCP, it updates its cached list of local IP addresses by querying the TCP stack. The result is that when clustering instantiates a new address, the resolver does not learn about it unless/until a subsequent DHCP address change occurs. The same is true when cluster addresses are removed. Since DHCP address changes are rare, gethostbyname usually excludes cluster IP addresses when resolving the local node name.

In Windows 2000, MSMQ came to depend on the new behavior in its active/active scenario in a cluster and is therefore broken with the hotfix behavior. MSMQ uses RPC for client/server communication. At startup in the server process, RPC uses gethostbyname to determine the list of IP addresses to listen on. In its active/active configuration, one MSMQ server process is associated with the local node name, while another is associated with a cluster virtual server. If gethostbyname returns the virtual server IP address to the process associated with the local node name, then both processes will listen on that address. The result is that clients attempting to connect to the virtual server process can be mistakenly connected to the local node's process. Thus, MSMQ depends on the fact that cluster virtual IP addresses usually are not returned by gethostbyname when resolving the local node name.

APPLIES TO
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server
Keywords: 
kbnosurvey kbarchive kbhotfixserver kbqfe kbbug kbfix KB257577
Share
Additional support options
Ask The Microsoft Small Business Support Community
Contact Microsoft Small Business Support
Find Microsoft Small Business Support Certified Partner
Find a Microsoft Store For In-Person Small Business Support