NetBIOS alone should not give you many headaches. Unfortunately, when NetBIOS problems occur they can be difficult to detect. Understanding how NetBIOS works is the key.
One of the important steps in trying to resolve IP problems is determining if name resolution is working. It seems simple enough: If you can connect to a computer by IP address and not by NetBIOS name, the problem is with name resolution. That is great, but what happens if NetBIOS name resolution is not functioning? To help you overcome this obstacle, I will explore the components of NetBIOS resolution and help isolate the cause of name resolution problems.
Which name are we talking about?
The first issue is determining the kind of name. In the Windows client world, there are two basic types of names. The first kind is a name for IP addresses. Host name resolution uses a host’s file and DNS for resolution. The second kind of name is the NetBIOS name, which is used for Windows (SMB) type sharing and messaging. These are the names that are used when you are mapping a drive or connecting to a printer. These names are resolved either by using an LMHosts file on the local machine or WINS server, or by broadcasting a request.
Just to muddy the waters, Microsoft allows IP host names to be used as a substitute for NetBIOS names. Although the net effect is making it easier to resolve names, the substitution strategy makes troubleshooting problems more difficult. You not only have to troubleshoot all of the NetBIOS name resolution options, but you must also troubleshoot the IP host name resolution. The best way to determine what is broken in NetBIOS name resolution, however, starts with understanding how NetBIOS name resolution works.
How NetBIOS names work
NetBIOS names are located through a series of steps that begins with checking the local cache. You then check an LMHosts file and, lastly, progress into a broadcast message that looks for the name (that is, unless the default actions have been changed). Before you begin, you need to understand the four kinds of resolution that NetBIOS does natively.
First resolution: The first resolution mechanism is not really a resolution mechanism at all. It is an internal cache that is in each Windows machine. This cache is populated by previous name resolution attempts and by a special option in the LMHosts file (described next). The idea behind the cache is that, if the software needed to resolve the name once, it is quite likely that it will soon need to do so again. If you need to resolve the name again, the name is cached in order to improve responsiveness and limit network traffic. In order to reduce the possibility that the cache will become invalid because too much time has passed since the name was resolved, the cache has a limited lifetime, typically 10 minutes. However, entries put into cache by the LMHosts file option never expire. It is also important to have a limited lifetime for the cache to minimize the amount of memory used for caching. Although in today’s world of 512-MB desktop computers this may seem odd, it was a real concern when the NetBIOS naming strategy was developed and we were still dealing with conventional (640K) memory.
Second resolution: The second resolution method is where the LMHosts file is consulted to see if there are any NetBIOS names that match the NetBIOS name being queried. In its simplest form, the LMHosts file contains an IP address and a host name. In addition to the IP address and NetBIOS name, you have two more options. The first option is #PRE, which causes the entry to be cached into memory. This has little effect in today’s environment. The second option, #DOM (domain), is used to associate the computer with a NetBIOS domain name. This can be helpful if you are trying to find a domain controller to log into. The LMHosts file is located in %SYSTEMROOT%\SYSTEM32\DRIVERS\ETC. Typically, %SYSTEMROOT% is the C:\WINNT directory.
Third resolution: The third resolution mechanism used by the local computer to resolve the NetBIOS name involves consulting one or more naming servers. In most cases, the naming server contacted is a Windows Internet Naming Server (WINS). Technically, you could create a NetBIOS naming server that is not a WINS server, but it is rarely done. The NetBIOS naming server standard is an open standard controlled by RFC 1001 and RFC 1002. Each computer contacts the WINS server upon startup and provides the computer’s IP address, as well as its name. It stores this information into a database that may be replicated with other WINS servers. The WINS server also verifies that the name is not already in use. The database maintained by the WINS server is queried each time a client computer asks it to resolve a NetBIOS name. The WINS server can either resolve a name or not. There is no delegation of authority with a WINS server. Multiple WINS servers can be listed in the client configuration for consultation. In this case, the last WINS server to respond will be consulted. It is assumed to be a copy of all of the other WINS servers listed in the client configuration. The client will cycle through the list of its WINS servers until it locates one that is responsive.
Fourth resolution: The fourth and final resolution method is to broadcast for the NetBIOS name. The computer broadcasts a special packet that is received and processed by all machines on the network. The packet then requests that the computer identify itself. This is effective within a local network but is ineffective across routers, which do not forward broadcast packets. This means that the broadcast NetBIOS name resolution method does not work across routers. It can only be used for computers within the same IP subnet. Another problem with broadcast resolution is that it takes time from every computer. Finally, broadcast resolution requires that the packet be transmitted to every computer on a subnet. This can effectively eliminate the usefulness of a switch, which is designed to prevent computers from seeing traffic that is not destined for them. Since a broadcast is by definition destined for every computer on the subnet, it must be broadcast to every computer. As the amount of broadcast traffic increases, the switches tend to behave more like hubs—passing on every packet to every connected computer. The tendency to broadcast is one of the reasons that NetBIOS is not well liked in networking circles.
While the preceding is the default order, the order itself can be controlled via a node type attribute. The node type controls the order of resolution for the computer and the types of resolution consulted. The node type can never prevent the local cache from being consulted first, nor can it prevent the LMHosts file from being consulted. It only controls the behavior of the resolving computer with regard to when it will broadcast and when it will use a WINS server.
The node type can be set to only three modes. The first mode, B-mode, only uses the cache, LMHosts and broadcast. It will not try to use the WINS server. The second mode, P-mode, never broadcasts. It only uses the cache, LMHosts file, and WINS server. The final mode, H mode, or hybrid mode, behaves as described above by checking the LMHosts file and the WINS server, and then broadcasting. Hybrid mode is the default mode for all Windows workstations that have not had another node type provided via configuration or via DHCP.
Types of NetBIOS names
Although we typically think just of computer names, there are many different kinds of NetBIOS names that you may need to resolve. Obviously, computer names need to be resolved to locate shared folders and printers. However, the names of logged-in users may also need to be resolved. The NetBIOS system allows you to send messages to users in addition to being able to attach to shared drives and printers; this requires that the system be able to resolve user names into IP addresses as well.
In addition, Windows domain names must be resolved. When a user attempts to log into a domain, the computer must contact a domain controller for the domain to verify the user account. The domain name is registered in a special way by all of the domain controllers within a domain so that the client will know which machines it can contact to validate username and password.
The way that these multiple name types are resolved is by recording a value in the 16th position of a registration. NetBIOS names have a fixed 16-byte format; however, Microsoft reserves the last byte for name type identification. This allows for registration of multiple types of names without redefining the standard to include a separate type field. This is important for a standard that was developed a long time ago and that had a substantial amount of deployed code. To give you an idea of the broad range of name types that exist in NetBIOS land, a list of some of the types of names and their codes are shown in Figure A.
Resolving across the network
One of the most frequent problems that organizations have is managing NetBIOS name resolution across networks. Name resolution problems on local networks are often not visible because NetBIOS can resolve names via broadcast. Of course, broadcasting is not an option in networks attached to each other via routers. In local networks, even if other name resolution options fail, they may be masked by broadcast name resolution.
Of course, you can use LMHosts to handle cross-network name resolution; however, the administrative burden of doing this is prohibitive. This means that cross-network name resolution requests are almost always handled by WINS, which is tricky on its own.
If you are having problems resolving host names remotely, but not locally, you may need to review the details of how WINS works. Fortunately, Peter Parsons has full details on WINS and how to troubleshoot it in the article "Troubleshoot WINS on your Windows 2000 server." Before going that route, however, we need to test to see what the actual problem is.
Testing NetBIOS name resolution
The tool to use for testing NetBIOS name resolution is NBTStat, which is short for NetBIOS over TCP/IP Status. This comes from the fact that originally NetBIOS used the NetBEUI protocol for transport. Today, most environments are only running NetBIOS naming across TCP/IP. This is frequently abbreviated NBT.
The first thing to do with NBTStat is to input “NBTStat –a <hostname>,” where <hostname> is the name that you are trying to resolve. NBTStat will display how that name was resolved on each network connection on your computer. This is helpful in several ways. First, the name resolution occurs without any other actions, so it is clear whether the name is resolving or not. Other techniques for determining whether name resolution is working may be testing more than just name resolution. Second, if the problem that you are trying to troubleshoot is one where the wrong address appears to have been received, it is possible to determine which adapter will lead to the wrong answer.
After running the NBTStat command, you may receive one of three results. First, the answer is correct and everything is working—at least for the moment. Second, the answer is incorrect. In other words, the wrong IP address is returned. Third, the answer is that there was no answer. The name did not resolve at all.
If the server returned the correct IP address for the name, then whatever problem that leads you to research the NetBIOS naming services is either broken or the problem you are troubleshooting is intermittent. If you get the wrong answer, you need to investigate the LMHosts file on the local machine in the %SYSTEMROOT%\SYSTEM32\DRIVERS\ETC directory, the WINS server’s registration database, and finally, the settings of the computers on the network.
If there is no answer, you must determine how you expected the name to be resolved. If either LMHosts file should have contained the answer or the WINS server should have contained the appropriate record, then you must review those sources. If, however, you anticipated that the answer would come from the other computer being on the network and responding to the broadcast for the name request, then either the computer is not responding to the broadcast name requests or it is never receiving it. The most likely cause of it not responding to a broadcast name request is because it is not on the same subnet as the computer making the request.
When resolving names with NBTStat, remember you can always try to resolve a name for a given IP address. This strategy can be helpful if you are unsure of the address and are trying to verify that the address returned is correct. The syntax of the command is “NBTStat –A <ip address>” where <ip address> is the IP address to test. The results will be the names registered to that IP address. If you resolve a name, then try to resolve the IP address without getting the same name, you know that your LMHosts file or WINS server contains a bad record for the NetBIOS name you have specified.
All about cache
As we discussed above, in order to reduce the amount of name resolution traffic, each machine keeps a cache of the names that it has resolved previously. This cache is consulted before any other name resolution mechanism. This works well in most cases, but in cases where you have corrected an IP address that was wrong, it could be a problem. However, clearing the cache is easy. Just type “NBTStat –R.” This will clear the cache. If you want to confirm that the cache was cleared, you can type “NBTStat –c” to display the cache. By manually clearing the resolver cache, you can test your fixes.
NetBIOS to DNS
Microsoft muddied the water when it allowed IP host names to be used to resolve NetBIOS names. Although the option has been removed from Windows 2000 and above, it is still a possible consideration when debugging clients. When enabled, the option causes the system to attempt to resolve NetBIOS names via DNS resolution. Therefore, in cases where you are getting incorrect IP addresses back from NetBIOS after having checked both the LMHosts file and WINS servers, you will have to troubleshoot IP host name resolution. For more information on NetBIOS and Windows 2000 see "Speed up Windows 2000 by eliminating NetBIOS."
Name resolution and browsing the network would seem to be closely related. If you can resolve all of the names on a network, then you should be able to browse the network. While this appears on the surface to be true, it is not. The mechanism for browsing is unrelated to the name resolution process.