70-240 in 15 minutes a week: Windows 2000 WINS

Monday Aug 27th 2001 by ServerWatch Staff

Article 21 in Dan DiNicolo's 70-240 in 15 minutes a week series covers the Windows Internet Naming Service (WINS) in Windows 2000. This includes a look at NetBIOS name resolution, node types, WINS replication settings, client configuration, as well as features and functions.

by Dan DiNicolo

Welcome to article number 21 in my 70-240 in 15 minutes a week series. This week's article covers the Windows Internet Naming Service (WINS) in Windows 2000. This includes a look at NetBIOS name resolution, node types, WINS replication settings, client configuration, as well as features and functions. This article again falls into the Networking services portion of the series.

The material to be covered in this article includes:

- NetBIOS name resolution in Windows 2000.
- WINS Registration
- WINS replication
- Configuring WINS clients
- WINS features and functions

NetBIOS Name Resolution in Windows 2000

Many people assume that NetBIOS name resolution is no longer necessary in Windows 2000 due to the heightened importance of DNS as the primary name resolution facility in the OS. Although Microsoft is certainly moving away from a reliance on NetBIOS as a network protocol, you simply cannot ignore the fact that programs exist that rely on NetBIOS. Yes, Windows 2000 does support resolving NetBIOS names in a variety of ways, including the use of DNS and related hostname-resolution techniques, but this is not necessarily efficient. Since so many products still use NetBIOS as their primary protocol, and since so many networks now run TCP/IP, it is still a good idea to run WINS on the network. If nothing else, it is impractical not to have it for the purpose of supporting downlevel clients such as Windows NT and Windows 98, who complete many important processes (such as logon) via NetBIOS.

A NetBIOS name is a 16-byte address that uniquely identifies a host on the network. This address is 15 characters long, with a 16th character that uniquely identifies a service that the system is running, such as the Server or Workstation services. A NetBIOS name is often referred to as a Computer name, although the line is blurring as Windows 2000 moves to a more integrated support of TCP/IP and DNS naming. Don't forget that the purpose of WINS is mainly to resolve NetBIOS names to IP addresses. In the past, NetBIOS was the primary communication protocol used on Microsoft networks. The move to TCP/IP as the primary transport of choice has necessitated the ability to map NetBIOS names to IP addresses, and the ability to 'piggyback' NetBIOS over TCP/IP. However, WINS is not the only way to resolve these names to IP addresses. The official NetBIOS name resolution techniques in Windows 2000 include:

Local Broadcast - In this traditional method, a host will broadcast onto the local subnet trying to find the IP address associated with a given name. Obviously this method is restrictive, since it is limited in terms of reach on the network (as well as being inefficient)

NetBIOS Name Server - In most networks, a NetBIOS name server (such as WINS) is set up to handle name registration and queries directly. Clients systems (and servers) register their NetBIOS name to IP address mapping with WINS. When queried by a client, the NetBIOS name server replies with the requested IP address associated with the requested name. 

NetBIOS Name Cache - Upon resolving a NetBIOS name to an IP address, the client stores this information in its NetBIOS name cache. By default, entries remain in cache for 600 seconds, and the cache holds only 16 names (configurable via the Registry). This makes the network more efficient, in that a client does not need to contact the network for every name resolution request. The reason for the low timeout is the fact that IP addresses may change due to the use of DHCP on the network. To view the NetBIOS name cache, use the nbtstat -c command.

LMHOSTS - This text file products a static way of mappings host names to IP addresses. A deeper look at LMHOSTS files follows later in this section.

The method that a client system will use to resolve NetBIOS names to IP addresses relies on what is referred to as its node type. Microsoft supports 4 main node types, and these control the order in which resolution attempts will take place. By default, a system not configured with a WINS server address will be configured for B-node, and with a WINS server address will be configured for H-node. Most often, node type is configured as a DHCP option, but it can also be configured on individual systems via a Registry change. The 4 main node types are listed below. Note that a client system always checks the NetBIOS name cache first. The Hex values of the node types are listed for the purpose of registry modification. To find out which node type a client is using, run ipconfig /all

B-node (Broadcast) - this method uses a broadcast to resolve names. In Microsoft land, this is actually called 'enhanced B-node', since if the broadcast fails, the client will attempt resolution via the LMHOSTS file. Value is 0x1. 

H-node (Hybrid) - this method first tries resolving the name via a WINS server, and then attempts B-node methods if unsuccessful. Value is 0x8

M-node (Mixed) - this method first attempts to resolve names via broadcast, followed by an attempt at querying a WINS server should that fail. This is often used in environments where a WINS server is across a WAN link. Value is 0x4

P-node (Peer-to-peer) - this method uses a WINS server for resolution, and never broadcasts. Value is 0x2


The LMHOSTS file is far from the most efficient solution to NetBIOS name resolution, but is of use in environments without WINS. Created on the same principal as the hostname-resolving HOSTS file, the LMHOSTS file is a plain text file that contains NetBIOS names in one column, followed by IP addresses in the other. A client can consult this file in trying to resolve a name to an address. Because the use of this file is associated with Microsoft B-node, it only makes sense to put mappings for remote hosts in this file - local hosts will always be found by the broadcast that happens prior to LMHOSTS consultation. By default, the LMHOSTS file can be found in the %systemroot%\system32\drivers\etc directory. You should also have an awareness of the optional tags that can be used with the file, as these provide additional functionality, as outlined below. Also note that you should place the most commonly used entries at the top of the LMHOSTS file, since the file is parsed from top to bottom.

Useful LMHOSTS file tags

#PRE - Entries marked with the #PRE tag are pre-loaded into the NetBIOS name cache.
#DOM:<domainname> - these entries designate domain controllers
#INCLUDE <path> - this entry marks the path to a centralized LMHOSTS file on the network. This can be a useful alternative to WINS (though still a great deal of work), but remember that the NetBIOS name-to-address mapping of the host with the centralized file must also be included in this LMHOSTS file.
#MH - this entry designates that multiple entries exist for a name since the system is multihomed (has multiple network interfaces)

Note that Windows 2000 will use the LMHOSTS file by default, but this can be changed via the WINS tab in your Advanced TCP/IP settings. Consult the screen shot of the WINS tab later in the article to see the checkbox.

WINS Registration

Note that WINS is not installed on a Windows 2000 Server by default - you will need to add the service by accessing Windows Components via Add/Remove programs in Control Panel. As was the case in NT 4, systems configured to use WINS will register their NetBIOS name to IP address mapping when they start up. The actual process consists of a name registration, with a client renewing the registration once half the TTL (time to live assigned by the WINS server) for the registration has expired. If the name a client attempts to register is already in the database, the WINS server sends a challenge to the host who has the name registered to see whether the host is active. If not, the name registration will succeed. If the other client is active, the registration will fail since machine must have unique NetBIOS names. In the same way, a client will 'unregister' itself in WINS upon a proper shutdown. Note that when this happens, the entry is not immediately removed from the WINS database - instead, the entry is 'tombstoned' and marked for extinction, a process that allows the name release to be replicated to other WINS servers. Ultimately, the record is removed from WINS once the extinction timeout period has passed.

One of the more welcome features in Windows 2000 is the ability to change your IP address without a reboot. After doing so, you should ensure that you also reregister your name registration in WINS - a process accomplished by issuing the nbtstat -RR command.

WINS Replication

You should recall from NT 4 that you could configure WINS servers to replicate information to one another, giving multiple WINS servers a more complete view of the network. This functionality still exists, with the ability to configure replication manually, as well as automatically. The automatic partner configuration can be set on a WINS server and uses multicast traffic (address to find and communicate with other WINS servers. By default, these servers will become push/pull partners of one another, and will replicate via 'pull' every 2 hours. The upside of using automatic configuration is that it is simple, but the downside is that you may want a higher degree of control. Also understand that all of your routers must support forwarding multicasts in order for this to work. Turned off by default, you can configure the WINS server to use multicasts via the Replication Partners properties Advanced tab, as shown below.

The more traditional way of configuring WINS replication is manually, by making systems push/pull partners. These relationships can be one-way, or two-way, whichever best meets your needs. I describe both after the screen shots below:

Push partner - a push partner is configured notify its pull partner of changes to the WINS database after a certain number of changes. The push partner is simply a messenger - it tells the pull partner 'I have changes', and the pull partner grabs the changes. Push partner parameters are generally set in LAN environments where bandwidth is not a big issue.

Pull partner - a pull partner is configured to obtain changes from configured push partners as a function of time. That is, the pull partner can be configured to obtain changes at a certain time interval that is convenient for our network. For example, you might configure pull parameters in a WAN environment with limited bandwidth to replicate at midnight.

Remember the key - push partners get configured according to number of database changes; pull partners as a function of time. Configure for push in LAN environments and pull in WAN environments as a general rule. To have WINS servers replicate fully with one another, they must be push/pull partners of each other (since replication is set up one-way - pull obtaining changes from push - by default).

Configuring WINS Clients

WINS client settings can be configured manually, or dynamically using the proper DHCP options (044 to assign server addresses, 046 to set the node type). WINS settings are set up by access the WINS tab in the advanced TCP/IP properties. The WINS tab is shown below.

Note that unlike in NT 4 where you could only enter addresses for a primary and secondary server, in Windows 2000 you can configure the client with a list of up to 12 WINS servers to use in order of preference. Note that the client can be enabled or disabled from using an LMHOSTS file for lookup, and can also be enabled/disabled for NetBIOS over TCP/IP. As a best practice, you should ensure that all client applications run properly before disabling NetBIOS over TCP/IP. 

Other WINS Features and Functions

WINS in Windows 2000 still behaves very much like WINS in Windows NT. The section provides an overview of some old functionality you may have forgotten about, as well as some of the new functions that you should be aware of. 

WINS Proxy - Just like in NT 4, you can configure a Windows 2000 system as a WINS proxy. A WINS proxy is a system that listens for NetBIOS broadcasts on the network and forwards those broadcasts to a WINS server for resolution. WINS proxies are used when a subnet contains systems that use NetBIOS but do not support WINS, allowing these systems to use NetBIOS naming and communicate across a TCP/IP internetwork. Like in NT 4, a WINS proxy is configured via a registry setting, so youll need to add the setting EnableProxy with a value of 1 to the path HKLM\System\CurrentControlSet\Services\NetBT\Parameters

Burst Handling - At certain times during the day, WINS servers may take on a heavy load of registrations, such as when people boot up their PCs when they get into the office at around 9am, or after a network failure. WINS in Windows 2000 has the ability to handle these high-impact times using burst handling (this also existed in NT versions with SP 3 and above). Turned on by default, the WINS server handles requests normally until the burst-queue reaches 500 requests (the medium setting). After it reaches 500 queued registration requests (which can be changed via the WINS console as shown below), the server begins responding positively to clients immediately with a TTL of 5 minutes for the first 100 clients above 500, increasing the TTL by an additional 5 minutes for every 100 clients thereafter. This basically forces the clients to fully reregister with the WINS server once the load had decreased on the server. 

Manual Tombstoning - The manual tombstoning feature in Windows 2000 exists to help ensure the consistency of WINS databases in environments where WINS replication is used. In effect, it allows you to manually tombstone records that you wish to have invalidated (not deleted) in WINS, such that the information will be replicated to all other WINS servers. This feature exists because a deleted record (one removed from the WINS database entirely) could be re-replicated to a server, since other servers would think that the record was still valid. The tombstoned record would then replicate and cause that record to be tombstoned on other WINS servers, and so on. The record would eventually be deleted from the WINS database once the tombstone lifetime expires.

Verify Database Consistency - Be careful with this one. WINS in Windows 2000 has a feature available called Verify Database Consistency which allows you to verify that the information found in a given WINS database is correct and up-to-date. In effect, the feature forces the local WINS server to check all records replicated from other WINS servers and compare them with the current local versions found on the WINS server that owns the record. The local WINS server will then update the information as necessary. The problem with this command is that it is very resource intensive in large environments - it is suggested that it only be down in periods of low activity, such as after working hours.

Database Backup - In order to have the WINS database backed up automatically, you need to specify a backup path on the servers General property tab. Once provided, the database will be backed up to this location every 3 hours. You can also specify that the database be backed up automatically when the WINS service stops (as it would on shutdown, for example). The General tab is shown below

Persistent Connections - Another new feature in Windows 2000, WINS replication partners can now maintain (and do by default) persistent connections with one another. That means that less time and resources are used on the WINS server, since the necessary connection is always established between partners. This can be turned off via the Replication Partners properties (see the screen shot in the WINS replication section)

WINS Users Group - This group is created after WINS is installed, and membership allows a user read-only access to information stored in the WINS console, a useful feature for first-line network support.

That does it for yet for yet another article. Thanks again for sticking with the series, and thanks for all the wonderful feedback. Many people have asked how many articles are left, so as an educated guess, I'm going to say approximately 5. I still need to cover this many major topics, including a little more on DNS, and then Routing, Remote Access, Certificate Services, and Network Security. This list is random - how I get to them order-wise will largely depend on my schedule over the coming weeks. I hope you'll consider posting your study-related questions to my message board. Until next week, best of luck with your studies. 


Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved