Recently in 70-215 Category
Learn what to look for on the client and the server side when fixing WINS problems.
Update: See also Steps to take to recover a crashed WINS server
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 article, we'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.0 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 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 console. 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.
Whether your systems are powered by Windows or Linux, network configuration problems inevitably arise. Often the problem can be traced to an improperly configured TCP/IP setting, but finding the culprit can be difficult. You can use the following checklist to help you identify and eliminate network TCP/IP errors.
1. What stopped working? The client or the server? Ask around before attacking coworkers� PCs; learn if the outage is affecting others or just a single desktop.
2. If the server stopped working, you should notice many office mates banging their heads against their desks simultaneously. If this is the case, focus on fixing the server.
3. If a single client PC has stopped responding to the network, ask the user whether new software was just loaded or any recent changes have been made to the system, including the installation of service packs, new Internet software, Elf Bowling games, and so on.
4. Check the physical network. The physical topology of your network is most prone to failure. In fact, most network problems are often due to Physical Layer failures.
5. Is it plugged in? Check all network cable connections. Start at the NIC; is there a green light? Check the wiring closet to see if someone "borrowed" the patch cable. Check the hub to see if the system is getting a link across the cable.
6. If you don�t have a cable tester, get one. Cabling is very susceptible to electricians, cleaning people, HVAC personnel, and so on.
7. Start PINGing. Both Windows and
Linux have the ping command. In a typical network you have this order
(client->gateway->server) or (client->gateway->internet). First, attempt
to PING yourself from the Windows command prompt or use the Linux shell.
Your local "loopback" address for such testing is 127.0.0.1. Windows
users should see the response shown in Listing A, while Linux operators
should see the results shown in Listing B.
Listing A: Windows
| C:\WINDOWS>ping
127.0.0.1 pinging 127.0.0.1 with 32 bytes of data: Reply from 127.0.0.1: bytes=32 time<10ms TTL=32 Reply from 127.0.0.1: bytes=32 time<10ms TTL=32 Reply from 127.0.0.1: bytes=32 time<10ms TTL=32 Reply from 127.0.0.1: bytes=32 time=1ms TTL=32 ping statistics for 127.0.0.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 1ms, Average = 0ms |
Listing B: Linux
| [root@gateway /root]# ping -c 4 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=1.2 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.9 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.9 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=255 time=0.9 ms --- 127.0.0.1 PING statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.9/0.9/1.2 ms |
Note that in Linux you must add -c 4 to the command, which requests four PINGs. Otherwise, you must stop the test using [CTRL]C.
8. If you do not receive a successful PING from yourself, in Windows, try re-installing the TCP/IP protocol from the Network Control Panel. In Linux, see if your Ethernet card is loading properly by using ipconfig. It should provide the information shown in Listing C.
Listing C
[root@gateway /root]# ifconfig
|
By issuing the interface configuration (ifconfig) program, you will receive a list of your interfaces. If the loopback (lo) is not listed, you may have an incorrectly configured kernel or possible problems with the loopback module. Try recompiling/reinstalling to see if that resolves the problem.
9. If PINGing your loopback worked fine, then try PINGing someone who is on the same subnet as you. In the ifconfig example above, the IP address is set to 192.168.1.100. Thus, in this scenario you should attempt to ping 192.168.1.1. Be sure the target IP address being PINGed is a valid IP address assigned to a system; otherwise, you�ll receive errors.
Use the Start | Run | ipconfig command to learn your NT machine's IP configuration (use WINIPCFG with Windows 98). ipconfig provides valuable information about what network you are on, as well as your gateway address. In Linux, use ifconfig to learn your network settings.
10. If you can PING someone on your local subnet, move on to the next step. If you can't, you're probably experiencing a Physical Layer failure. The usual suspects are bad cables or a NIC gone bad (they do that sometimes). With loopback, you were just testing the inner workings of the TCP/IP protocol stack; with PINGing on your local subnet you tested for failure on the failing machine. Try replacing the network card and using a new patch cable.
11. The next problem area is in the gateway. Find the IP address of your gateway. You can find this in the ipconfig screen with NT systems (WINIPCFG for Windows 98) or in Linux by running the netstat -rn command, providing these results:
| [root@gateway /root]# netstat -rn Kernel IP routing table
|
The -rn prints the routing table and puts everything in numeric format. In this example, the default gateway (0.0.0.0) is 192.168.1.254. If you don't have a gateway configured, then one will not show up in WINIPCFG or when using netstat. This is a problem.
In Windows, locate Start | Settings | ControlPanel | Network | TCP/IP | Gateway and add your gateway. This is your local interface on your router. In Linux, use linuxconf or set up a temporary route using the route add command.
PING this address; this will prove a solid connection from your PC to the gateway. If you have made it this far, the PC is working, the cabling is working, and the router (gateway) interface is working. You can skip to the next section.
However, if you receive no response from the gateway, and you have one configured, it's time to call in the big guns. Your router is improperly configured. It must have a local interface (IP address) on your subnet to listen to the traffic on your network. If there is no interface, have the router administrator add one. If it has one but has stopped working, it could mean you�re experiencing a router failure, and others will be affected as well. Conversely, the router administrator may have loaded an old config; check with the administrator to make sure this isn't the case.
12. The final step is through the gateway. PING something that is on the other side of the gateway. In an intranet, PING a printer on a remote subnet. On the Internet, PING www.jrksoftware.com (for example). If you do so successfully, you should not have a problem. If you can't get to a particular system in your network or on the Internet, that resource may not be available. You may want to tell the administrators of those systems about this checklist! Certainly, you can expect they�re working through the same difficulties as you.
Remember, always look for the most obvious problems first, and if in doubt, reboot your system.
