Troubleshooting WINS clients

Article
03/27/2012

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2, Windows Server 8 Beta

Troubleshooting WINS clients

What problem are you having?

Name resolution failed at client computer.
Clients do not use load balancing when connecting to a multihomed server.

Name resolution failed at client computer.

Cause: The type of name resolution used is not appropriate. Determine whether WINS or DNS is being used for name resolution and if the name failure is occurring for a NetBIOS or fully qualified domain name (FQDN).

Solution: NetBIOS names are 15 characters or less and are typically used to provide named access to NetBIOS services based on a computer or group name, such as Messenger, Server, or Workstation. For example, the short NetBIOS name "PRINT-SRV1" might refer to a computer used for print and file sharing. It might also be known by a full DNS computer name "print-srv1.example.microsoft.com" when referring to this same computer as a Windows Server 2003 family shared or published printer resource.

For the DNS example name used above, Winsock-based host name resolution is used to associate an IP address to a named computer and further identify it in a system of domains, either on an intranet or the Internet. This is needed for an entirely different set of applications such as to access Web, SMTP mail, FTP, or LDAP servers.

The key point is that each of these name schemes, WINS or DNS, require name resolution for different names used in different applications, and for locating different types of network services. NetBIOS has its own set of applications that demand NetBIOS name resolution, the absence of which can cause network failures. These can be repaired or detected through an Lmhosts file used temporarily to troubleshoot or correct the name resolution failure.

DNS and FQDNs use Winsock-style host name resolution and are primarily used for Active Directory and Internet use. For this type of name resolution, you can also repair or detect most problems through a Hosts file used temporarily to troubleshoot or correct the name resolution failure.

Verify the exact form of the name that has failed during resolution and determine whether the correct type of name resolution was involved.

Cause: The client could be using an application or version of Windows that requires the use of WINS to resolve names.

Solution: Not all Windows computers or applications require WINS or NetBIOS over TCP/IP (NetBT). For example, if the failed name resolution occurred as part of a URL entered in a Web browser or FTP program or as part of an address in an Internet e-mail program, the problem is more likely related to DNS.

Name resolution could fail when any clients need access to shared resources not published through Active Directory. Resources such as these could include legacy file servers, print servers, domain controllers or member servers used to complete logon or browsing of Windows NT domains. Some examples of applications that a client might use and need WINS to assist in name resolution include My Network Places, the Map Network Drive feature in Windows Explorer, or the net command (Net.exe) and any of its supported options, such as net use or net view.

Cause: The client computer may not be correctly configured, or may not be able to use WINS.

Solution: First, determine whether the client is configured or enabled to use both TCP/IP and WINS. Client configuration of WINS-related settings can be done in one of the two following ways:

Manually, by an administrator setting the client TCP/IP configuration.
Dynamically, by a DHCP server providing the client with TCP/IP configuration.

In most cases, computers running earlier versions of Microsoft operating systems are already able to use WINS once TCP/IP is installed and configured for the client. For Windows XP, administrators can optionally disable NetBIOS over TCP/IP (NetBT) for each client. By disabling NetBT, WINS cannot be used at the client.

In addition, determine whether the client has a valid IP configuration. To check a client IP configuration, use the ipconfig /all command. You can use ipconfig /all|more as a way to slow or pause viewing of the output of this command for screen-by-screen review.

In the command output, verify that the client computer has the following configured for the network where it is connected:

a valid IP address
a valid subnet mask
a default gateway
Primary and secondary WINS servers

If the client does not have a valid configuration, you can either use the ipconfig /renew command to force the client to obtain a renewal of its IP configuration with the DHCP server or you can update the TCP/IP configuration for the client manually.

Cause: The client may not have basic connectivity with its configured WINS servers.

Solution: To verify whether a client has basic TCP/IP access to the WINS server, first try pinging the WINS server by its IP address.

For example, if the client uses a primary WINS server of 10.0.0.1, type ping 10.0.0.1 at the command prompt on the client computer. If you are not sure what the IP address is for the WINS server, you can usually learn it by repeating the previous command, using ipconfig /all|more if necessary to pause the displayed command output so you can read the WINS server information.

If the WINS server responds to a direct ping of its IP address, try using the nbtstat -RR command at both the client and also at the resource server that the client is attempting to locate by name. This command forces the WINS client services on each computer to send name release and refresh requests to the WINS server and re-register their names.

If the WINS server does not respond to direct pinging of its IP address, this indicates that the source of the problem more likely stems from network connectivity issues between the client and WINS server. If this is the case, follow basic TCP/IP network troubleshooting steps to fix the problem.

Cause: The primary or secondary WINS server may not be able to service the client.

Solution: At the primary or secondary WINS server for the client, use either Event Viewer or the WINS console to see if WINS is started and currently running. If WINS is running on the server, search for the name previously requested by the client to see if it is in the WINS server database. If the name does not appear in the server database, check whether replication is configured correctly and operational between your WINS servers.

Clients do not use load balancing when connecting to a multihomed server.

Cause: The WINS server providing name resolution for the multihomed server name to network clients is running an earlier version of Windows NT Server that has not been updated.

For all versions of Windows that support NetBIOS over TCP/IP (NetBT), network clients configured to use WINS attempt to resolve any NetBIOS-based name for a computer to its IP address or addresses. To perform this resolution, clients query the WINS server for the address of the multihomed server and receive a list of addresses that are always in the same order. NetBT then takes and sorts the list, arranging multiple IP addresses according to the following three categories:

Any IP addresses located on the same subnet as the client are given first priority in the list.
Next, IP addresses located within the same network class are listed.
Finally, any remaining addresses are listed.

Then, NetBT starts at the top of this list and pings the first address to make sure it is valid. If it gets a reply, it uses the address. If there is no reply, it goes on to the next address.

The problem is that for earlier versions of WINS, within these three categories, the order of addresses is left unchanged from the list provided by the WINS server. This means that, as long as the first address in the list is online, it will be the one that is always used by every WINS client. This does not provide load balancing or 'round-robin' rotation, as DNS servers can perform when more than one name-to-address mapping is available.

Solution: Upgrade WINS servers to a Windows Server 2003 operating system; or update servers running earlier versions of Windows 2000 and Windows NT Server to the most current Service Pack

Share via

Troubleshooting WINS clients