Introduction
WINS is definitely not a sexy subject these days. DNS has taken over as the name resolution solution of choice. However, there are still plenty of applications out there in the wild that remain dependent on WINS, and if you don’t have a working WINS infrastructure and you need to use those apps, bad things are going to happen. If your network is still floating in the WINS boat, then you still have to be concerned about WINS names resolution and have to deal with troubleshooting WINS client name resolution issues. The most common WINS client problem is failed name resolution. When name resolution fails at a client, try the following troubleshooting tips to see if you can identify the source of the problem.
Confirm that the Name Resolution Failure was for NetBIOS Names
The old NetBIOS names were single label names and were limited to 15 characters. An example of a NetBIOS name would be SRV1. In contrast, DNS names have multiple labels that denote a host name and a domain name, such as SRV1.domain.com.
If the short name was used at the client, Windows might use NetBIOS name services, such as WINS or NetBT broadcasts, in its initial attempts to resolve the name. If a DNS name (FQDN) is used, DNS is likely the cause of the failed name resolution. Newer versions of Windows will try DNS first, and try to resolve the name by trying to fully qualify the name. So check on the DNS suffixes the client is trying to use before deciding that there is a WINS name resolution failure. Depending on your configuration, if DNS name queries fail, we then try NetBIOS name resolution methods.
Confirm that the client is using an application or version of Windows that requires WINS to resolve names
These days, most Windows computers or applications do not require WINS or NetBIOS over TCP/IP (NetBT). However, many older applications were written to the old NetBIOS interface and were designed to work on single segment networks where NetBIOS name resolution was the preferred or predominant method of name resolution. Businesses often have applications that they’ve been running for many years, especially proprietary applications that were custom written for their company or industry.
In modern Windows environments, DNS replaces WINS as the name resolution method of choice. However, if you are using legacy applications, you have to make sure that they are able to use DNS name resolution. The easiest way to determine this is to use Network Monitor 3.4 and check for name resolution requests on the wire. If you see only NetBIOS queries, or unusual DNS queries, then you know that your application has some legacy limitations and you’ll need to investigate those and determine if they will work with a WINS client configuration.
Confirm that the Client is configured to use the Correct WINS Server
Confirm that your clients are configured to use both TCP/IP and WINS. Client configuration of WINS-related settings can be done manually by an administrator setting the TCP/IP configuration of the client, or it can be done dynamically by a DHCP server providing the client its TCP/IP configuration.
Confirm that your WINS client computer has valid IP addresses. To check the IP configuration of a client computer, use the ipconfig /all command. Verify that the client computer has a valid IP address, a valid subnet mask, a default gateway, and both a primary and secondary WINS server.
You might have to fix the NetBT settings in DHCP to resolve the problem. After you address the problem, you can either use the ipconfig /renew command to force the client to renew its IP configuration with the DHCP server or you can update the TCP/IP configuration for the client manually. Note that ipconfig /renew will only be helpful in fixing a WINS related problem if you have fixed the issue at the DHCP server.
Confirm that the client has basic connectivity with its configured WINS servers
Confirm that a client has basic TCP/IP access to the WINS server. Ping the IP address of the WINS server. If the client uses a WINS server at IP address 192.168.1.1, enter ping 192.168.1.1 at the command prompt on the client computer and press ENTER. Use ipconfig /all at the command prompt to find out what the IP address of the WINS server is, if you’re not sure about the address.
After successfully ‘pinging’ the WINS server, use the nbtstat –RR command at both the client and the resource server that the client seeks to locate by name. This command forces the WINS client service on each computer to send name release and refresh requests to the WINS server and reregister their names.
However, if you don’t receive a positive response from the WINS server, the problem might be a network connectivity issue. This could be a connectivity issue between the client and WINS server or the WINS server itself might be down.
Confirm that the WINS Servers are Running and the Database is Accurate
Try using the Event Viewer on the WINS server or the WINS management console to see if WINS is 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. It might be that you can’t find the name in the WINS database. If that happens, check to ensure that replication is configured correctly and is operational between your WINS servers.
Troubleshoot the Server Side of the WINS Name Resolution Problem
If a WINS server can’t resolve a name, it will most often respond to the client in one of two ways:
- A negative query response back to the client: “Name not found”.
- A positive response – but the information is incorrect.
Most WINS-related problems start as failed queries at a client, so it is a good practice to start with examination of the client. If you determine that a WINS-related problem does not originate at the client, go on to the following tips to further troubleshoot the source of the problem at the WINS server of the client.
Confirm that the WINS server is paying attention to the client
Confirm that the WINS server service is actually running on the WINS server. If WINS is running, search for the name requested by the client to see if that name is actually in the WINS database.
If you find that the WINS service won’t start or if you’re seeing database corruption errors, you can use WINS database recovery techniques to restore the WINS database. Of course, that assumes that you have backed up the WINS database. If there are no backups, then there won’t be any restores. If the name does not appear in the server database, verify that replication is configured correctly and is operational between your WINS servers. For more information, see “Troubleshooting WINS replication” in this section.
Don’t get whacked by Static Mappings
Ever been nailed by HOSTS file entries? The same thing can happen to you when you configure static mappings in WINS. You should avoid static mappings if you can, since even clients assigned static IP addresses can register their names in WINS. If the information returned to a client during name resolution is incorrect or stale, check to see if the name entry in the WINS server’s database is a static entry. If you do have a static record that’s causing the problem, do the following to fix things:
- In Replication Partners Properties, check the Enable Migrate box. This will allow WINS to overwrite static records with dynamic records.
- Edit the static mapping to update the mapped address information.
- Delete the static entry from WINS.
What about WINS Replication?
In some WINS deployments, the use of one-way replication partnerships, such as push-only or pull-only partners, can create situations where names are not regularly replicated to all servers in the network.
The following issues are consistent with problems with the WINS server:
- You can’t connect to a WINS server using the WINS management console.
- The WINS client service or WINS server service is down and you can’t start it.
Sometimes there is no problem with name registration and the problem is with replication of the name changes across the WINS replication network. These are seen more often on large networks with complex replication designs and a large number of WINS servers in use.
Check out the following tips after you confirm that the primary client and server issues are resolved and you think there might be a problem with your WINS replication network.
Confirm the design and functionality of your WINS replication network
There is a limit to the number of WINS servers you should have. In general, don’t go over 20 for your entire WINS replication network. Also, a hub-and-spoke replication topology that uses push/pull partnerships between each WINS hub server and its member spoke servers is the best way to go.
In some cases, you might need to use push-only and pull-only partner relationships. At a minimum, establish reliable support procedures for occasions when you might need to manually trigger replication between WINS servers configured to operate using these types of limited replication partnering. Make sure you carefully consider the implications when deploying push-only or pull-only partnerships. Consult a WINS expert if you’re not sure about this.
Confirm the record numbers for WINS entries when replicating to other WINS servers
WINS version ID record numbers for WINS name entries are incremented in the WINS database by each server that owns and registers a name record. The version ID is stored with each name record, and WINS uses it for version tracking when a record is replicated to other servers. The Version IDs are incremented only for certain types of record changes. For example, when a name is refreshed, WINS typically does not increment the version ID. For other changes, such as a change in IP address, WINS increments the version ID in most cases. If the version ID is not incrementing for a name record to all servers in the WINS replication network, you can use the WINS management console to increase the starting version count for the server and correct the problem.
Summary
In this article, we went over some of the things you can do to resolve WINS name resolution problems. Most networks have modern Windows operating systems and use DNS preferentially, but on many business networks, there may still be some applications and services that are WINS dependent. If you have one of those networks, you still need to be aware of WINS and how to troubleshoot simple WINS problems. Have fun!
