Much has been made of the idea that you no longer need WINS in a pure Windows 2000 environment because DNS handles all name resolution in Windows 2000. However, many older applications still require WINS. For example, the Map Network Drive function, the My Network Places, and the Net command with supported options such as net view all require WINS name resolution. So if you’re running older applications like these on your network, WINS is still pretty important. In this Daily Feature, I’ll show you how to troubleshoot a problematic WINS installation in a Windows 2000 network.

WINS locates resources on a network by name
WINS stands for Windows Internet Naming Service. It’s a name resolution service that uses the NetBIOS method to locate computer resources on a network by name. It’s the follow-on from the LMHOSTS file, and it’s an automatic system insofar as you don’t need to manually update name records. WINS is slightly misnamed because, contrary to what its name implies, it can’t be used to resolve names over the Internet. That requires DNS.

In Windows 2000, WINS is classed as a ”legacy” name resolution method because Windows 2000 relies on DNS for all its name resolution needs, and DNS uses the Winsock API rather than the NetBIOS API. However, WINS remains the de facto name resolver in Windows NT 4 and earlier operating systems, and Windows 2000 Server ships with a WINS server because Microsoft recognizes the need for backwards compatibility.

Common errors
The most common errors you’ll encounter on a network running WINS usually fall into two categories: PC client and/or WINS server. It’s likely that the first indication of a WINS problem will come from a client PC, so it makes sense to start troubleshooting there. The vast majority of WINS-type errors can be cured at the client.

WINS client problems
The most prevalent errors with WINS clients are ones such as Network Path Not Found or Name Not Found. The first things you need to do, in roughly this order, are:

  • Check the network cable’s physical connection to the network card and to the LAN socket.
  • PING the localhost to determine whether the machine’s TCP/IP stack responds properly. If it doesn’t, you may need to reinstall it.
  • On a Windows 2000 machine, verify that Enable NetBIOS Over TCP/IP is selected in the client’s Advanced TCP/IP properties. If it’s disabled, WINS resolution won’t work.
  • On a Windows 2000 client, verify that the TCP/IP NetBIOS Helper Service is started.
  • Run the IPCONFIG /ALL command to get a detailed summary of how the client’s TCP/IP stack is configured. In particular, check the Primary and Secondary WINS server IP addresses.
  • Assuming that the WINS servers’ entries are correct, try pinging the WINS server. If it responds, you know this client’s connectivity is not suspect.
  • If the error message was received while trying to connect to a different computer, open the WINS server console to check that both the client’s and the required resource’s WINS records exist in the WINS database.
  • At a command prompt, run the command NBTSTAT –RR on both the client and the required resource. This forces both machines to release and refresh their WINS records.

If WINS servers aren’t specified on a client, that client will, by default, try to resolve NetBIOS names by sending a broadcast to the network. If the required resource is on a different subnet, then these broadcasts can’t be routed because broadcasts aren’t routed in MS TCP/IP. This leads to errors. That’s why you need to configure WINS Proxy agents to “catch,” “bundle,” and forward these broadcasts between subnets.

If you’re getting this type of error, make sure that any WINS proxies in use are installed and correctly configured. If you have more than one subnet without WINS servers, make sure that you actually set up WINS proxies in the first place so that clients can register with the WINS servers.

If you receive a Duplicate Name error, you need to find the corresponding WINS database entry on that client’s Primary WINS server and delete it if it’s a static record. You can manually add the correct record, or you can try to do it automatically by running the NBTSTAT –RR command at a command line.

WINS server problems
If your clients are working fine, you need to turn your attention to the WINS servers. Just as with the clients, you need to check the server’s physical network connections first. Then you should verify that the WINS service is actually flagged as STARTED in the Services node of the Computer Management MMC. If it’s stopped, attempt to restart it. If it won’t start, perform a reboot to see if that clears the air.

If rebooting doesn’t work, refer to the WINS database. If specific clients seem to be having problems, you need to check the accuracy of their records on the WINS server. They may have changed IP address and failed to update this information in WINS. If you have any static entries, you may want to migrate them to dynamic entries by using the Enable Migrate box in Replication Partners Properties. Dynamic mappings are better and often more accurate than their static counterparts.

It may be that WINS replication has failed. This often leads to mismatched record information, which can cause WINS-type problems. You may want to review your WINS replication strategy. If you’re using a large number of WINS servers (i.e., more than 15), you definitely need to address this.

You also need to check the version ID on the WINS records. If there’s a discrepancy between WINS servers, this could be part of the problem. WINS version IDs are incremented for actions like a change of IP address.

If WINS is running on a domain controller, you should consider moving the service, because WINS registration and logon authentication traffic is often most intense at the same time of day. This can prevent the server from registering itself in WINS because it’s too busy answering authentication calls. Similarly, make sure the actual WINS server registers itself in the local database. Don’t configure a secondary WINS server—it can be problematic if records of ownership are split across different WINS servers.

Finally, avoid installing WINS on multihomed servers. WINS registrations can become corrupted on servers that have more than one network interface if the WINS server can’t work out which subnet the requests came from.