Understanding WINS and NetBIOS

The Network Basic Input/Output System (NetBIOS) was developed in 1983 and used by IBM as a way for computer applications to communicate over a network. NetBIOS is also firmly ingrained into all Microsoft operating systems that have come before the Windows 2000 series. Legacy software applications may also rely on NetBIOS for locating resources on the network.

NetBIOS provides a way for identifying resources on a network (such as a printer, file server, and so on). All devices running on the network are assigned a unique 16-byte name that defines the particular computer or printer to the network (or a service on a computer—this means that a single computer may provide services identified by different NetBIOS names). NetBIOS names are typically assigned when you install a particular operating system on a computer. Down-level operating systems such as Windows NT all request that a unique, 15-character NetBIOS name be entered for the computer during the installation process of the OS. When you install Windows on a computer, a computer name is created for that computer. If you change the hostname and the name is fewer than 15 characters, it also becomes the NetBIOS name for the computer (otherwise, the hostname is truncated to a 15-character NetBIOS name).

In fact, NetBIOS names are 16 characters long. The last character is used by the computer's operating system to specify the special functions of certain computers such as domain controllers and browsers.

Even though the default networking protocol for Windows Server 2008 is TCP/IP and the primary name-resolution strategy is DNS, an important issue related to NetBIOS names rears its head on your Windows Server 2008 domain. Applications that still use NetBIOS for identifying other computers and resources on the network must have a way of resolving these NetBIOS names to IP addresses. This process is cleverly called NetBIOS name resolution. NetBIOS is also required in the networking environment for NetBIOS dependent applications.


NetBIOS Broadcasts
When a computer seeks to resolve a NetBIOS name to an IP address, it sends a NetBIOS broadcast. Because the name-resolution request takes the form of a broadcast message, it is sent to all nodes on the local subnet (the subnet being a particular segment on a routed network).

For example, imagine a computer named Kirk wants to send data to a computer named Spock. Kirk broadcasts that it would like to send data to Spock but does not know Spock's IP address. When Spock hears this broadcast (as do all nodes on the subnet), Spock sends a response providing Kirk with the IP address. Kirk can now proceed with establishing a network session with Spock and transferring data as needed.

Two obvious problems plague the use of broadcasts for NetBIOS name resolution. First, the broadcast messages clog your network with broadcast traffic, which sucks up your bandwidth. Another problem is that broadcast messages are not typically forwarded by routers on the network (unless the router has also been configured as a bridge). So, if a computer on one subnet uses a broadcast message to resolve a NetBIOS name for a computer that is on another subnet, the broadcast message is never forwarded to the intended target.

One strategy that has been worked out to cut down on the number of broadcast messages is as follows: After a computer has discovered the IP addresses of other computers on the segment through the use of broadcasts, these IP addresses are kept in a NetBIOS name cache on that computer. This cuts down on broadcasts in the case of "repeat" business with a particular computer or computers on the network. You can view the NetBIOS name cache on a computer running Windows Server 2008 by using the NBTSTAT command. We discuss this command-line tool later in the hour.


Working with LMHOSTS Files
Another alternative for NetBIOS name resolution is to use an LMHOSTS file. The LMHOSTS file is a text file that lists the IP addresses of computers on the network followed by their NetBIOS name. LMHOSTS files are static and must be updated by the network administrator (that means you). And although they provide the computer with a quick way to look up an IP address based on a NetBIOS name, you must place them on each computer on the network (and whenever you add computers to the network, you also have to update all the LMHOSTS files on all the computers).

Some network administrators still use LMHOSTS files to resolve NetBIOS names to IP addresses on their networks. On a server running Windows Server 2008, the LMHOSTS file is kept in the \Windows\system32\drivers\etc folder. The basic structure of an LMHOSTS file is a two-column text file:

IP address NetBIOS name


Windows 2008 actually provides a sample LMHOSTS file in the \windows\system32\drivers\etc folder. You can open it using Windows Notepad or another text editor.

Included in the Windows 2008 LMHOSTS file are explicit directions for building your own LMHOSTS lists. Pay special attention to the fact that descriptive entries in the file are always followed by the number sign (#). All other entries are read as mapping records.

The major problem with LMHOSTS files is that they represent a fairly labor-intensive way to manage NetBIOS name resolution. If LMHOSTS files have been used on the network in the past, however, they can be integrated into the WINS database on your WINS server. An Import LMHOSTS File command is available on the WINS snap-in Action menu. We discuss the WINS snap-in later in the hour.

NetBIOS Node Types
Before concentrating on the Windows Server 2008 WINS service and its installation and configuration, it is important to discuss the different node types that can exist in the NetBIOS environment. A node type simply refers to the way that a computer on the network registers with a NetBIOS name server (such as WINS) and seeks to resolve NetBIOS names to IP addresses. There are four node types:

B The client uses broadcast messages for name registration and name resolution.

P The client uses unicast (directly to the server's IP address) messages to a NetBIOS name server for both name registration and NetBIOS name resolution.

H A hybrid node type, these clients use unicast messages to the NetBIOS name server for registration and resolution. If they cannot find a NetBIOS name server (a WINS server), the client resorts to broadcast messages for registration and resolution.

M Clients use broadcasts for name registration and for name resolution. However, if the name cannot be resolved by broadcast, the client attempts to contact a NetBIOS name server.


Windows 2008 WINS clients (those configured for WINS) act as H nodes. They attempts to resolve names by using the WINS server first, and then they resort to broadcasts if a WINS server is not available. As a last resort, these clients consult their LMHOSTS file if one is available locally.



Deploying a WINS Server
The most foolproof method for dealing with NetBIOS naming issues is to deploy a WINS server (or servers) on your network. WINS provides the greatest amount of efficiency in terms of your network bandwidth. The series of steps that allows a WINS client to take advantage of the WINS server for NetBIOS name resolution is very straightforward:

1. When a WINS client computer boots up, it registers its NetBIOS name and IP address with the WINS server.


2. When a WINS client on the network wants to communicate with a network resource designated by a particular NetBIOS name, it communicates with the WINS server to handle the NetBIOS name resolution of its intended target, rather than sending out a broadcast to all nodes on the segment.

3. The WINS server finds the appropriate mapping of NetBIOS-name-to-IP-address in its database and returns the IP address to the WINS client.

4. If the WINS client cannot contact the primary WINS server, the client makes two more attempts to contact the primary WINS server. Then it attempts to contact the secondary WINS server if one has been designated in the TCP/IP properties for the client (or if the client is a DHCP client with multiple WINS servers configured).

5. If the secondary WINS server (or other WINS server because the client attempts to contact WINS servers in the order designated in the TCP/IP properties) can handle the request, no problem. However, if the client cannot contact any designated WINS server, the client resorts to a network broadcast. If a number of WINS servers are available on the network, the chances of the client having to resort to a broadcast message are slim.

The great thing about WINS is that the database compiled by the server is dynamic. The WINS clients actually register with the server, supplying the entries in the WINS database. This is similar to the way that Dynamic DNS (DDNS) works, however WINS does not provide a mechanism for secure updates as DDNS does. Any computer configured to use a WINS server can register itself in the WINS database.

Source of Information : Sams Teach Yourself Windows Server 2008

No comments:

Cloud storage is for blocks too, not just files

One of the misconceptions about cloud storage is that it is only useful for storing files. This assumption comes from the popularity of file...