Windows IT Pro is the leading independent community for IT professionals deploying Microsoft Windows server and client applications and technologies.
  
  
  Advanced Search 


March 1997

Inside a NetBIOS Name Resolution


RSS
Subscribe to Windows IT Pro | See More NetBIOS Articles Here | Reprints | Or get the Monthly Online Pass—only $5.95 a month!

A step-by-step look at the process

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 201.33.19.31. 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

201.33.19.31 snoopy #PRE

is in LMHOSTS, the PC will identify SNOOPY as 201.33.19.31, 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 199.34.57.50. 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.

Clarification Note
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!

End of Article



Reader Comments
I'm a new MCSE and I had learned about each the different types of name resolution. It wasn't until I had to specify a Node type on a Server install that I relized that I had no clue as where to specify the node type. After reading this artical I easily went to the server and set the correct node type.
Thank-you


shane June 15, 2000


I couldn't find any better source of information about host name Resolution. The way this topic is explained by the author makes very easy understand the whole configuration process even if the reader is a spanish speaker like me.

Javier H. Eraso November 08, 2000


great article!! Explained everything in question!
thanks

Blaine April 13, 2001


what do netbios in wins and dns . different between netbios name & lmhosts file name please give me detail answer .
for this kind of act

khalid malik November 01, 2003


My question is: when you want to resolve NetBios names into IP addresses can you use the Lmhosts files, broadcast transmissions, and DNS?

tom d. December 07, 2003


Please help me, what are the five name resolution methods.
and dns servers process client queries in two, what two ways, please help me email me thank you.

Peter Guy March 03, 2004


Thanks for the article. I have been trying to resolve a problem accessing a website with lmhosts. The trouble is that the domain name for the site was longer than 15 spaces even without the .com extension. Can you address this circumstance? What goes in lmhosts for trusted domain name in such a situation? Should I have used the IP address?

Jane Fairfax April 30, 2004


Great article, although i still have to learn a lot. Hint/tip requiered: i'm building a netsend app using Visual Basic and NetMessageBufferSend api. The app is deployed on a MS Server2003 network using XP pc's. On some pc's the api call takes about 10-15 secs to complete. Your article points me in the direction of enabling WINS, or refreshing the LMHOSTS table. Do you have any tips how to tackle this problem?

JayPho July 29, 2004 (Article Rating: )


You must be a registered user or online subscriber to comment on this article. Please log on before posting a comment. Are you a new visitor? Register now




Top Viewed ArticlesView all articles
Battery Life Issues Almost Certainly Not Windows 7's Fault

While Microsoft is still investigating a notebook battery life issue that was supposedly caused by Windows 7, some interesting trends have emerged. ...

Getting your iPhone to Sync with Exchange 2003

Follow these steps to use an iPhone with Exchange. ...

Confirmed: Battery Life Issues Not Windows 7's Fault

Microsoft on Monday issued a lengthy statement about the recent Windows 7 battery controversy, echoing my assessment from earlier in the day, but backing it up with hard, cold evidence. Put simply, Windows 7 is not responsible for any battery life issues ...


Related Articles WINS Proxy Agents

Advanced WINS Features

Knowing the Angles of NetBIOS Suffixes

NetBIOS Names and WINS

Windows OSs Whitepapers Protecting Microsoft SharePoint

Related Events Deep Dive into Windows Server 2008 R2 presented by John Savill

Managing IT Across Multiple Locations

Check out our list of Free Email Newsletters!

Windows OSs eBooks Understanding and Leveraging Code Signing Technologies

A Guide to Windows Certification and Public Keys

SQL Server Administration for Oracle DBAs

Related Windows OSs Resources Introducing Left-Brain.com, the online IT bookstore
Looking for books, CDs, toolkits, eBooks? Prime your mind at Left-Brain.com

Discover Windows IT Pro eLearning Series!
Clear & detailed technical information and helpful how-to's, all in our trademark no-nonsense format


Windows IT Pro Home Register FAQ for Windows WinInfo News
Europe Edition About Us Contact Us/Customer Service Media Kit Affiliates / Licensing  
SQL Server Magazine Office & SharePoint Pro DevProConnections IT Job Hound
Left-Brain.com Technology Resource Directory asp.netPRO ITTV Windows SuperSite 
 
 Windows IT Pro is a Division of Penton Media Inc.
 © 2010 Penton Media, Inc. Terms of Use | Privacy Statement