NetBIOS Names and WINS

My past few columns have dealt with the resolution of NetBIOS names on an IP network. If you want to type net view \orange, your computer must be able to convert the name "orange" into an IP address such as 204.53.22.82. For a long time, people on a Microsoft TCP/IP network had an unpleasant pair of options for NetBIOS over TCP/IP name resolution: They could either rely on broadcasts or construct a static name resolution table, lmhosts.

With Windows NT 3.5 came a better answer: the Windows Internet Name Service (WINS), a NetBIOS Name Server containing a database that matches NetBIOS names and IP addresses. WINS is a database program that keeps track of which NetBIOS names map to which IP addresses.

If you've ever set up TCP/IP on a Windows for Workgroups (WFW), Windows 95, or NT machine, you've heard of WINS. Every time you set up an IP address for a network card, you get to attach a primary WINS server and a secondary WINS server to that IP address. Clearly, Microsoft thinks WINS is important: If you try to set up an IP address without WINS, you get one of those "Are you sure?" message boxes.

Connecting with WINS

Here's how WINS works from your PC's point of view. First, the PC starts up the IP stack. Part of that stack involves a WINS server. Second, the PC sends a message to the WINS server saying, in effect, "Hey, I understand you're my WINS server; pleased to meet you. I know that whenever I need to match up an IP address with a name, you'll help me out." Then the WINS server says back, "Why, I'm delighted to be of service, PC...PC...What did you say your name and IP address are? Ah yes, let me note that name."

WINS can tell you the name and IP address of any computer on the network that has introduced itself to the WINS server. And because every system wants to be able to do name resolution with WINS, every system registers itself with WINS, so WINS knows about the machines on the network.

This initial contact (or name registration) happens, like so many things in the NT world, because of NT's NetBIOS origins. Microsoft networking began on single-segment networks with a dozen or so computers. The person sitting at a computer could assign any unique name to that computer. Problems arose if the name wasn't unique.

Microsoft networking computers handled this problem with a name registration packet, essentially a broadcast to all other computers on the network saying, "Hey! I want to call my computer BEANIE; is anyone out there already named BEANIE?" As long as no computer complained, the PC took the name BEANIE.

Better than Broadcasting

Broadcasting isn't a good idea for two reasons. First, it forces every computer on the segment to stop and ask itself, "Am I BEANIE?" If the computer isn't named BEANIE, it won't send a message. But the asking wastes some CPU time. Second, all this broadcasting doesn't work over routed networks.

WINS remedies this situation in two ways. First, instead of broadcasting, a WINS client sends a name registration packet straight to the WINS server, in a point-to-point directed IP message. The other computers don't have to look up from what they're doing, so no CPU time is wasted. Second, the communications between WINS client and WINS server are also point-to-point, so routers are no problem. If a second BEANIE tries to start up, it soon finds out that it's not unique. When it tries the name resolution with WINS, the WINS server rejects its request, citing a duplicate name.

Faster and Faster

WINS servers are, according to Microsoft, fast. With NT 3.51, Microsoft claimed that a 486 acting as a WINS server could process 1500 name resolution requests per minute. To make your WINS server even faster, tell it to stop logging the changes to its database. Open the WINS Manager, highlight a server, and click Server/Configuration. Click Advanced>>, and clear Logging enabled. This procedure tells WINS to stop creating a transaction log.

I know that step sounds drastic, but it isn't. You're better off filling in the text field Database backup path in Server/Configuration/Advanced>> to tell WINS to back up its database every three hours. If you don't fill in that field, your WINS server won't back up its entire database, so logging changes to the database would be kind of silly.

Speed vs. Inconvenience

Not having a transaction log will make rebuilding your WINS system's names database harder if a server crashes, but preventing logging also will roughly double the number of resolutions the WINS system can handle per minute. WINS gets its information from computers doing name registrations whenever they boot, probably once a day for most machines. Rebooting the PCs in a network would let WINS restore its database in minutes. Yes, I know, rebooting every machine is not something you'd want to do because it is a great inconvenience to your users, but what about the inconvenience of a consistently slow name resolution system? Further, how many of your computers change their name in a three-hour period? Probably not many. If they don't change their name, they have entries in the backed-up WINS database.

Another way to juice up the WINS server a bit is to modify its runtime priority. Just go to the Registry at hkey_local_machinesystemcurrentcontrolsetserviceswinsparameters and create an entry called PriorityClassHigh. Its type is reg_dword, and its value is either 1 or 0. Zero, the default, says to keep the priority at normal. Set it to 1, and you increase the WINS server priority to high. Before you set the priority, look at the Performance Monitor to see whether the machine is usually busy. If it isn't, changing the priority of the WINS server isn't going to matter much. A high priority setting won't make a WINS server running alone on a slow machine run more quickly; rather, the priority will help the WINS server grab more CPU cycles from the file-and-print services.

Another way to get faster name resolution is to add a CPU to a WINS server. A second CPU improves performance about 25 percent; however, a third, a fourth, or additional CPUs don't improve performance further.

Still another way is to install more WINS servers and distribute the load. But don't install too many because the database replication traffic can be monstrous. For example, when last I heard, Microsoft had only 15 in its entire enterprise!

A reasonable approach is to place WINS servers centrally in the organization, where they have access to all parts of the network. However, look out for multi-homed machines. Since NT 3.5, WINS hasn't worked too well on servers with more than one network card. Microsoft says that it fixed that problem in Service Pack 4 of NT 3.51, but I see messages on the network that say the problem is not really fixed.

What About lmhosts?

One more thing: Does WINS make lmhosts unnecessary? Not entirely, according to Microsoft. Apparently, domain controllers often can't find one another across a large number of routers. The result is problems with trust relationships and domain account database replications. Microsoft says the solution is to put an lmhosts file on each domain controller with references to the other domain controllers. I guess Microsoft will fix that problem in NT 5.0; every day I work with NT 4.0, I see more bugs in it. Maybe the 4.0 version number is jinxed. Remember DOS 4.0? Makes you wonder....