Go back to the Delta Guide Home Page. Download this article as a PDF file.
Windows Internet Naming Service (WINS) is the dynamic service used for maintaining associations between Network Basic Input Output Service (NetBIOS) resources and IP addresses. Windows uses NetBIOS over TCP/IP for connecting to various resources. Although Windows 2000 and later preferentially use DNS hostname resolution, NetBIOS name resolution is still provided because certain applications and machines (such as Windows NT and Windows 9x) need it.
WINS is a service for locating NetBIOS resources, which are services or applications running on a server. These services are defined and located using the NetBIOS name of the server. NetBIOS names can be up to 16 bytes in length; however, only the first 15 characters are used for the computer name. The 16th byte is reserved and is used to designate the NetBIOS resource type. This allows a given server to register multiple records, one for each resource. It also enables clients to locate the resources offered by that server. For example, a file server called LONDON would register a LONDON[00h] record. This record would be the actual computer name and would be registered by the workstation service. It would also register a LONDON[20h] record that designates it as a file server and is registered by the server service. If the machine were a domain controller for the NWTRADERS domain, it would also register the NWTRADERS[1Ch] record. Additionally, it would probably register the NWTRADERS[1Bh] record, which designates it as the domain master browser. All of these records are used by NetBIOS clients for locating the server with the appropriate resource. For example, when a NetBIOS client in the NWTRADERS domain needs to find a domain controller for authentication, it queries for the NWTRADERS[1Ch] record and receives a list of the corresponding IP address(es). Similarly, if a NetBIOS client wants to connect to a file share on the London server, it queries for the LONDON[20h] record and so on.
A number of sources are available that a NetBIOS client can query to obtain these resource records. First, it can simply broadcast on its local network. If the server with the resource is on the local network, it responds and all is well. This is fine for small, single segment networks. If you have more than a few machines, however, all this broadcasting for resources will bog down the network. Additionally, after the network grows to more than one segment, clients on one segment won't be able to find resources on the other segment(s) because broadcasts don't cross routers.
NOTE
Technically, some routers can be configured to forward broadcasts, but this is generally frowned upon because it can create broadcast storms in which the entire network is flooded with broadcast traffic).
The second method for querying NetBIOS resources is by using an LMHOSTS file. An LMHOSTS file is simply a table of NetBIOS names (and resources) and their corresponding IP addresses. This is great because you can eliminate or reduce the broadcast traffic as well as locate resources on other networks. The problem with LMHOSTS files is that you have to maintain them; anytime a new resource is added to the network, the LMHOSTS files on all clients need to be updated. Although you can configure clients to include information from a central LMHOSTS file or files, you still have to update that file and configure all the clients to use it. This is where WINS comes in. WINS is a central database for maintaining NetBIOS name-to-IP addressing information. All you have to do is set up the WINS server and configure your clients to use it. The beauty is that you can use DHCP to configure the clients with the WINS server information, so that can be centrally maintained as well.
The actual resolution process performed by a client depends on how the client is configured. The following process is used when a WINS client attempts to locate a NetBIOS resource:
The first step is to check the NetBIOS name cache.
Next, the client queries WINS or broadcasts for the resource. Whether it queries WINS or broadcasts and the order of each depends on the NetBIOS node type.
The client checks in the local LMHOSTS file, if configured.
If the entire NetBIOS query process fails, it then attempts to resolve the name via the hostname (DNS) resolution process.
FOR MORE INFORMATION
For more information on DNS and the hostname resolution process, visit http://www.samspublishing.com and enter this book's ISBN number (no hyphens or parenthesis) in the Search field; then click the book cover image to access the book details page. Click the Web Resources link in the More Information section, and locate article ID# A010803.
Although the LMHOSTS file is the last resort, it can be configured to preload records into the NetBIOS name cache. By putting a #PRE after a record, that record gets loaded into the NetBIOS name cache (which gets queried first).
NetBIOS Nodes
The NetBIOS node type determines whether the client will query WINS, broadcast for the NetBIOS name, or both, and in what order. The following are the four node types:
b-node—Performs a broadcast and does not query WINS.
p-node—Only queries WINS and does not broadcast.
m-node—Broadcasts first, and then queries WINS.
h-node—Queries WINS first, and then broadcasts. This is the most common implementation (and is usually configured via DHCP).
You can obtain a listing of your client's TCP/IP configuration information, including node type, by simply running ipconfig /all.
To provide efficient name resolution and querying services to clients, you will probably want to have multiple WINS servers across the enterprise. Multiple WINS servers also provide load balancing and redundancy. You can configure the clients with several WINS server addresses. That way, if they can't contact the first one (because it's either overloaded or down), additional WINS servers are available for it to contact. You can use DHCP to configure clients to register with (and query from) their local WINS servers, with additional servers as backups. Having the clients point to different WINS servers improves the performance of the client queries, minimizes network traffic, and provides redundancy, but now you have multiple databases.
Each client registers in and queries from the database of the WINS server to which it is configured. Consequently, each database contains a partial list of the entire network. Clients querying one WINS server will not find records that are registered in another WINS server. To ensure that all clients can locate all resources (not just the ones on their local WINS servers), you can configure WINS replication. WINS servers can be configured to replicate the entries from their local database to other WINS servers. This multimaster replication (it's called multimaster because each server can add and remove records) allows all the WINS servers to resolve client requests from a complete database. WINS replication can get complicated, but basically, WINS servers replicate in push/pull pairs. (Starting with Windows 2000, you could configure the WINS servers to automatically detect other WINS servers on the network and set up their own replication.)
WINS servers provide administrators with a centralized, dynamic method for maintaining NetBIOS name-to-IP address resolution. However, some day when allWindows clients are Windows 2000 or better and no applications require NetBIOS, WINS will no longer be necessary. For most organizations, however, that day is a long way away.
© Copyright Pearson Education. All rights reserved.
Go back to the Delta Guide Home Page. Download this article as a PDF file.