If you've been following the past few columns, you know that all the basic Windows NT client tools--Network Neighborhood, NET USE, NET VIEW, and the like--use name resolution to convert a server name, such as SNOOPY, to an IP address, such as 126.96.36.199. You also know that NT (and, for that matter, Windows 95 and Windows for Workgroups--WFW) does NetBIOS name resolution in one of several ways: It can broadcast, use an LMHOSTS file, or look up a name in Windows Internet Name Service (WINS).
But is that the whole story? If information between, say, LMHOSTS and WINS conflicts, who wins (no pun intended)? This month, I'll discuss the sequence of events in a NetBIOS name resolution.
You can approach NetBIOS name resolution in one of four ways: Client software can be B (broadcast) node, P (point-to-point) node, M (mixed) node, or H (hybrid) node. A computer doing B-node name resolution relies on broadcasts to convert names into IP addresses. A computer doing P-node name resolution uses a NetBIOS name server to look up NetBIOS names and get IP addresses. An M-node computer first tries a broadcast to resolve a name; if that attempt fails, the computer looks up the name in a NetBIOS name server. In other words, an M-node computer first acts as a B-node, and if that fails, tries to act as a P node. Finally, an H-node computer first does a P-node lookup, if that fails, the computer does broadcasts.
Are your PCs in B, P, M, or H node? You control how your PC does NetBIOS name resolution with three settings: First, specify a WINS server; second, enable or disable Enable DNS for Windows Resolution; and finally, enable or disable Enable LMHOSTS Lookup. If you use WINS on your network (if you don't, start using WINS today), your client computers are probably set up as H-node computers. If you do not specify a WINS server in TCP/IP setup, your computer acts as a simple B-node computer. You can force a PC to be B, P, M, or H via Dynamic Host Configuration Protocol (DHCP), if the computer gets its IP address from a DHCP server. One of the TCP/IP settings that you can control via DHCP is WINS/NetBT node type, which can have values 1, 2, 4, or 8. To set the computer to be a B-node machine, set the value to 1. Values 2 and 4 set the computer to P and M node, respectively, and 8 (the correct value for most of us) sets the node to H.
Suppose, however, that you've specified a WINS server and told TCP/IP to use LMHOSTS and DNS for name resolutions. To resolve a name, your PC will follow this sequence: NetBIOS name cache, WINS, broadcast, LMHOSTS, HOSTS, and Domain Name System (DNS).
The first place your PC looks to resolve a name is the preloaded NetBIOS name cache. These names come from entries in your LMHOSTS file (assuming you've enabled LMHOSTS) that include the metacommand #PRE. For example, if
188.8.131.52 snoopy #PRE
is in LMHOSTS, the PC will identify SNOOPY as 184.108.40.206, without looking at any other source of information. That'll drive you crazy if you're not careful, believe me. One day, you put an entry into LMHOSTS just to patch a problem, and then you forget that you've done it. Months later, you can't get to server SNOOPY from one computer, but all the other computers can access it without trouble. They all point to the same WINS server, so what could be wrong? After an hour or two of banging your head against the wall, you remember the LMHOSTS file.
If you specify WINS, your PC will try that next. You can specify a primary and a secondary WINS server, so your PC tries the primary first, and if it doesn't respond or can't satisfy the request, the PC tries the secondary WINS server. If either one of those name resolution attempts succeeds, the name resolution process stops--the next steps never occur.
If WINS fails, the PC will broadcast, "Does anyone within shouting distance have NetBIOS name SNOOPY?" which is standard B-node behavior. Interestingly, though the PC does three broadcasts, each about 0.7 seconds apart.
Next, the PC looks at the setting for Enable LMHOSTS Lookup. If the setting is selected, the PC looks in the LMHOSTS file. The PC already knows about the #PRE entries, but this file is where the PC uses standard entries. If LMHOSTS has the answer, the PC stops trying to resolve the name. By the way, LMHOSTS appears to be enabled for Win95; I haven't found a setting to disable LMHOSTS. On WFW or Win95, the LMHOSTS file goes in the c:\windows directory; on an NT Workstation or NT Server, it goes in the improbable location of \winnt\system32\drivers\etc. And to make LMHOSTS work more quickly, do not put any comments in the file because doing so slows the resolution down significantly.
Of course, the name resolution system for most of the Internet is DNS. DNS's job is to resolve names for Winsock-based applications; for example, if you point your Web browser to http://www.mmco.com, the browser, which is a Winsock-based application, will rely on DNS to convert the name www.mmco.com to the IP address 220.127.116.11. To also use DNS as a NetBIOS name resolver, select the check box, Use DNS for Windows Resolution.
The Microsoft TCP/IP code that activates DNS apparently also activates the old-style HOSTS files. I say apparently because the HOSTS file is the next place your PC will search to resolve a NetBIOS name. The HOSTS file must be in the same place as the LMHOSTS file, and it, too, is a source of occasional confusion. Include "Check for HOSTS and LMHOSTS" on your troubleshooting checklist.
If you've made it this far (the NetBIOS name cache, WINS, three broadcasts, the LMHOSTS file, and the HOSTS file have not been able to resolve the name) your computer will do a DNS lookup (again, only if you've selected the check box in the TCP/IP settings). Actually, your PC will do two DNS lookups. First, it looks up the name--SNOOPY, but in general, DNS stores names in fully-qualified names, like snoopy.mmco.com. So DNS first looks for an entry SNOOPY and, if that fails, tacks the domain name onto the end of the NetBIOS name and does a DNS lookup on that name--snoopy.mmco.com, in this example.
What if all these procedures fail to resolve the NetBIOS name? Then, oddly enough, the machine goes back and does the whole routine all over again. Your system compensates for temporary failures. Maybe the WINS server was down for a few minutes or a network connection was unavailable at the time. Have you ever wondered why Microsoft networking software takes so long to timeout? Assuming you don't have a server named SNOOPY on your system, try typing
net view \\snoopy
and see how long it takes to timeout and give you "The network name was not found," error message. And for even longer waiting times, try that command on a system with TCP/IP, IPX, NetBEUI, and Data Link Control (DLC) loaded.
In November, I said that you can use DNS names in the same places you use NetBIOS names, meaning that with NT 4.0, you can type netview\\orion01.mmco.com a NetBIOS command, but a DNS name. I also said that you can do that with NT 4.0 and Win95, if you have Win95 Service Pack 2 (SP2). Some of you wrote asking where to find SP2. I didn't mean to imply that Win95 SP2 exists, only that Microsoft has said they'll include this feature with SP2 when they ship it.
The MCSE review project I mentioned in February is perking along nicely. Check my Web site http://www.mmco.com for new databases, and add a question of your own!