Windows Internet Name Service
Windows Internet Name Service |
|
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:
First, make sure the appropriate services are running. To do so, complete the following steps at both the WINS server and WINS client:
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).
Following are common WINS problems and steps to solve them.
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).
Check the WINS database for the name. If the name is not present in the database, check whether the computer
If the computer is configured as
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.
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.
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.
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.
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
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
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.
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.
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 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 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.
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.
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:
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.
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.
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:
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:
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.
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.
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.
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 2000 Resource Kit. Information on running the utility can be found in online Help.
Other recommendations when preparing for troubleshooting include the following: