Share via


Troubleshooting WINS

This section describes some basic troubleshooting steps for common problems. It also describes how to restore or rebuild the WINS database.

The following conditions can indicate basic problems with WINS:

  • Administrator cannot connect to a WINS server using the WINS console. A message appears stating "The RPC server is unavailable."

  • TCP/IP NetBIOS Helper service on the WINS client is down and cannot be restarted.

  • WINS service is down and cannot be restarted.

First, make sure the appropriate services are running. To do so, complete the following steps at both the WINS server and WINS client:

  1. Verify that the WINS services are running.

  2. If a necessary service is not started on either computer, start the service.

If services do not start properly, you can use Computer Management, available in Administrative Tools in Control Panel, to check the status column of the services and try to start them manually. If the service cannot be started, use Event Viewer to check the system event log and determine the cause of failure.

For WINS clients, "Started" should appear in the status column for TCP/IP NetBIOS Helper Service . For WINS servers, "Started" should appear in the status column for Windows Internet Name Service (WINS) .

Common problems

Following are common WINS problems and steps to solve them.

How can I locate the cause of "duplicate name" error messages?

Check the WINS database for the name. If you find a static record, remove it from the database of the primary WINS server for the client where the duplicate name was detected.

Alternatively, select the Migrate (Overwrite unique static record with dynamic record) check box in Replication Partners Properties for the WINS server. Now the static mappings in the database can be updated by dynamic registrations (after WINS successfully challenges the old address).

How can I locate the cause of "Network path not found" error messages on a WINS client?

Check the WINS database for the name. If the name is not present in the database, check whether the computer uses B-node name resolution. If so, add a static mapping for it in the WINS database.

If the computer is configured as a P-node, M-node, or H-node, and if its IP address is different from the one in the WINS database, then its address might have changed recently, and the new address has not yet replicated to the local WINS server. To get the latest records, you can start replication at the WINS server that registered the record with the changed address to perform a push replication with propagation to the local WINS server.

Why can't the WINS server pull or push replications to another WINS server?

If the servers are located across routers, confirm that the problem is not a loss of network connectivity or router failure on an intermediate link.

Ensure that each server is correctly configured as either a pull or push partner.

For example, suppose the two WINS servers are named WINS-A and WINS-B. If WINS-A needs to perform pull replications with WINS-B, make sure it is a push partner of WINS-B. Likewise, if WINS-A needs to push replications to WINS-B, it should be a pull partner of WINS-B.

To determine the current configuration of a replication partner, using the WINS console, check the Type column for the list of replication partners at each WINS server. If necessary, you can change the replication partner type. Also, make sure that TCP port 42 is not blocked on an intervening network device, such as a router or firewall.

Why are WINS backups failing consistently?

Make sure the path for the WINS backup directory is on a local disk on the WINS server. WINS cannot back up its database files to a remote drive.

Troubleshooting WINS Clients

The most common WINS client problem is failed name resolution. When name resolution fails at a client, answer the following questions to identify the source of the problem.

Was the name that failed to resolve a NetBIOS or DNS name?

NetBIOS names are 15 characters or less and not structured like DNS names, which are generally longer and use periods to delimit each domain level within a name. For example, the short NetBIOS name "PRINT-SRV1" and the longer DNS name "print-srv1.example.microsoft.com" might both refer to the same Windows 2000 resource computer—a network print server—configured to use either name.

In the previous example, if the short name was used at the client, Windows 2000 would first involve NetBIOS name services, such as WINS or NetBT broadcasts, in its initial attempts to resolve the name. If a longer DNS name (or a name that uses dots) was involved in the failure, DNS is more likely the cause of the failed name resolution.

Is the client using an application or version of Windows that requires WINS to resolve names?

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

In pure Windows 2000 environments, DNS can replace WINS as a naming service. For a pure environment to exist, both the client and the resource server (the computer the client has targeted for locating by name) must both be running Windows 2000; Active Directory must be in use as well. For all other cases involving either the client or resource server running an earlier version of Windows or MS-DOS, a mixed environment exists.

In mixed environments, name resolution could fail when any clients need access to shared resources not published via Active Directory, such as older file and print servers, or 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 .

Is the client computer able to use WINS, and is it correctly configured?

First, check that the client is 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.

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

Also, check that the client computer has valid IP addresses. To check the IP configuration of a client computer, use the ipconfig /all command. (To slow or pause the output, use ipconfig /all | more for screen-by-screen review.)

In the command output, 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.

If the client has an invalid configuration, 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.

Does the client have basic connectivity with its configured WINS servers?

To verify that a client has basic TCP/IP access to the WINS server, first try pinging the IP address of the WINS server.

For example, if the client uses a primary WINS server at IP address 10.0.0.1, type ping 10.0.0.1 at the command prompt on the client computer. If you are not sure of the IP address of the WINS server, you can usually learn it typing ipconfig /all | more at the command prompt.

If the WINS server responds to a direct ping of the IP address, use the nbtstatRR command at both the client and the resource server that the client seeks 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 reregister their names.

If the WINS server does not respond to a direct ping, the source of the problem is likely to be a network connectivity problem between the client and the WINS server. Follow basic TCP/IP network troubleshooting steps to fix the problem. For more information, see "TCP/IP Troubleshooting" in this book.

Is the primary or secondary WINS server able to service the client?

At the primary or secondary WINS server for the client, use Event Viewer 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.

If the name does not appear in the server database, check that replication is configured correctly and is operational between your WINS servers. For more information, see "Troubleshooting WINS Replication" in this chapter.

Troubleshooting WINS Servers

The most common WINS server problem is the inability to resolve names for clients. When a server fails to resolve a name for its clients, the failure most often is discovered by clients in one of two ways:

  • The server sends a negative query response back to the client, such as an error message indicating "Name not found."

  • The server sends a positive response back to the client, but the information contained in the response is incorrect.

Many WINS problems involve incorrect or missing configuration details. To help prevent the most common types of problems, review WINS best practices for deploying and managing your WINS servers.

Success in fixing WINS problems nearly always follows if you use an orderly approach to troubleshooting. Most WINS-related problems start as failed queries at a client, so it is a good practice to start with examination of the client. For more information, see "Troubleshooting WINS Clients" in this section.

If you determine that a WINS-related problem does not originate at the client, answer the following questions to further troubleshoot the source of the problem at the WINS server of the client.

Is the WINS server able to service the client?

At the primary or secondary WINS server for the client that cannot locate a name, use Event Viewer 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.

If the WINS server is failing or registering database corruption errors, you can use WINS database recovery techniques to help restore WINS operations. For more information, see the "Troubleshooting WINS databases" section of this chapter.

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.

Is the name entry affected by a static mapping issue?

In general, static mappings are not recommended for clients that can use WINS to dynamically update their name and address information. If the information returned to a client during name resolution is incorrect or stale, check to see if the name entry in the WINS servers database is a static entry. If it is, you can update WINS by performing the following steps:

  1. In Replication Partners Properties, check the Enable Migrate box (shown in Figure 7.10).This enables WINS to overwrite static records with dynamic records.

  2. Edit the static mapping to update the mapped address information.

  3. Delete the static entry from WINS.

Is replication occurring between all WINS servers?

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. For more information, see "Troubleshooting WINS Replication" in this chapter.

The following error conditions can indicate problems with the WINS server:

  • Administrator cannot connect to a WINS server with the WINS management console and receives an error message when attempting to do so.

  • WINS client service or Windows Internet Name Service is down and cannot be restarted.

Troubleshooting WINS Replication

Many WINS problems can be corrected by troubleshooting WINS replication when a client and servers are involved in a failed name resolution. In some cases, such as for large networks with complex replication designs and a large number of WINS servers in use, problems with the accuracy or availability of names data are related to timely replication of the WINS database throughout the network.

After you have first investigated common problems related to WINS clients and servers, answering the following questions can help to further troubleshoot the source of the problem in a replicated WINS network.

Is the replication pattern of your network correct and appropriate?

In general, deployment of more than 20 WINS servers is strongly discouraged. Also, for best results and simpler administration, follow a hub-and-spoke replication topology when designing a replicated WINS network that uses push/pull partnerships between each WINS hub server and its member spoke servers.

If a single hub-and-spoke design exceeds the recommended maximum of 20 WINS servers, you should consult with Microsoft Consulting Services or Microsoft Product Support Services about how to revise or reduce your current WINS installation. For larger or enterprise installations, multiple hub-and-spoke designs are effective solutions.

In rare cases, you might need to use push-only and pull-only partner relationships. You should, however, carefully review added WINS administration issues where these configurations are deployed. 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.

Is the version ID incrementing for WINS entries when replicating on all servers?

The version ID is incremented in the WINS database by each server that owns and registers a name record. The version ID is a hexadecimal value stored with each name record in the database, and WINS uses it for version tracking when a record is replicated to other servers.

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.

When the version ID is not consistently incrementing for a name record at all servers in the replicated WINS network, you can use either the WINS management console or command-line options to increase the starting version count for the server and correct the problem.

Server Troubleshooting Utilities

Two utilities are useful when troubleshooting server problems: Hotfix.exe and Srvinfo.exe. Hotfix.exe provides specific information on which current hotfixes are installed on a server. This program is on the Microsoft FTP server and is included with posted hotfixes. Srvinfo.exe gives details on a particular server, such as which services or drivers are present; it can also give disk information for a remote server. This utility is found in the Windows   2000Resource Kit . Information on running the utility can be found in online Help.

Other recommendations when preparing for troubleshooting include the following:

  • Ensure server partitions have adequate space for Dumpfile.

  • Configure critical servers for use of symbols for debug and dumpfile troubleshooting procedures.