Network Uptime

The message 'WINS NO RESPONSE" is a common one in switched networks, especially since the WINS request is seen during a network broadcast and the directed response isn't sent through all ports like the broadcast. This causes the network analyzer to report that a WINS response wasn't received; in fact, it may have been received through a separate communications channel. Or, perhaps it never was! On a switched network, there's no way to definitively determine the actual disposition of the WINS request (unless, of course, you happen to be analyzing the connection that contains the station sending the original WINS request).

The issue of stations broadcasting for WINS services when configured WINS servers exist is a common question. To better understand the WINS resolution process, reference RFC 1001 - "Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods."

This RFC defines four node types for NetBIOS (WINS) resolutions; broadcast node (b-node), point-to-point node (p-node), mixed nodes (m-node), and hybrid node (h-node). A station can be configured as any of these node types, although b-node and h-node types are the most common. Each node type uses a different process for resolving NetBIOS names.

B-Nodes
-------
A station that does not have a WINS server configured is a broadcast node (b-node) by default. The b-node resolves NetBIOS names in this order:

1) The station looks in the NetBIOS name cache to determine if the host has been resolved previously.

2) If the name is not in the cache, the station sends a broadcast.

3) If the broadcast isn't answered, the station checks the local LMHOSTS file for name resolution.

4) After checking LMHOSTS, the station will check the local HOSTS file.

5) Finally, the host will perform a name lookup on the configured DNS server.

The default b-node configuration will always create broadcasts on the network, and never queries a WINS server. Obviously, this would not be an efficient node configuration on a large network! Since routers restrict broadcasts, this type of configuration would only be useful on local subnets (although I know many large networks that are a single VLAN!).

P-Nodes
-------
Point-to-point nodes (p-nodes) take care of the broadcast problem, because p-nodes don't broadcast to resolve a NetBIOS name. Here's the p-node process:

1) NetBIOS Name Cache

2) WINS Server

3) LMHOSTS File

4) HOSTS File

5) DNS Server

Look, no broadcasts! Unfortunately, there is a lot of reliance on the WINS and DNS servers. If those are inaccessible, then the station can't communicate to a NetBIOS-named device. Also, notice that a local WINS server becoming unavailable may create network traffic to a remote DNS server!

M-Nodes
-------
Mixed node (m-node) stations will use both broadcasts and WINS servers for name resolution, and the broadcasts are the preferable option:

1) NetBIOS Name Cache

2) Broadcast

3) WINS Server

4) LMHOSTS File

5) HOSTS file

6) DNS Server

Some organizations use m-node configurations in their smaller remote offices in situations where there is mostly local traffic and there is no local WINS server. Since local broadcasts are acceptable verses the use of the slower WAN link, an m-node configuration makes sense for these locations.

H-Nodes
-------
A station configured with a WINS server is a hybrid-node (h-node) by default. A h-node will request name resolutions from local WINS servers initially, and then will broadcast as a last-ditch effort:

1) NetBIOS Name Cache

2) WINS Server

3) Broadcast

4) LMHOSTS

5) HOSTS

6) DNS Server

The node type can be automatically determined based on the WINS server configuration. If a station does not have a WINS server defined, then the station is a b-node by default. If a WINS server is defined, then the station uses the default of a h-node. More information on the default node types can be found here:

>Default Node Type for Microsoft Clients
>http://support.microsoft.com/support/kb/articles/Q160/1/77.asp

The node type can also be determined or changed by a registry entry at

HKLM\System\CurrentControlSet\Services\NetBT\Parameters

The Entry is called 'NodeType' and it's type REG_DWORD. The applicable values are:

0x1 = b-node
0x2 = p-node
0x4 = m-node
0x8 = h-node

In large environments, most node types are configured through DHCP. DHCP Information Options are documented here:

>DHCP Options Supported by Clients
>http://support.microsoft.com/support/kb/articles/Q121/0/05.ASP

Since the h-node configuration is the default for stations with a configured WINS server, why are broadcasts still traversing the network (we're finally answering the original question!)?

* If the station is configured as a h-node, the WINS servers may not be operational or may be inaccessible. Even if the WINS servers are up and running, the network connectivity to those servers may be unavailable.

* The requesting station may have a misconfigured WINS server address. The station cannot resolve names through WINS because the WINS server IP address is incorrect! Since the client station is configured as a h-node by default, it then sends a broadcast to help provide the resolution.

This issue isn't seen in most DHCP environments, since the WINS server is configured automatically (and hopefully the DHCP record has the correct WINS configuration!).

* The DHCP server may be misconfigured to assign stations a node type other than h-node. Check those DHCP configurations, and make sure they correspond to the appropriate node type!

* When a device starts, it registers its name with the primary WINS server. If the device has an incorrect WINS address, this name registration never occurs. Obviously, the requesting h-node station will not find the registered name on the WINS server, and it must send a broadcast to attempt a resolution. This can also occur if the NetBIOS name to resolve has been misspelled!

* The requesting device may have a WINS server configured, but the requestED device may not! Occasionally, devices (especially servers) can be configured with an IP address but no WINS server. With no configured WINS server a station will never register with the WINS database, and workstations requiring name resolution will be forced to send a broadcast to resolve the name (unless the device is permanently registered on the WINS server).

Here's some additional Microsoft articles that discuss WINS, DHCP and name resolution:

>How WINS Lookup Works from Windows NT DNS
>http://support.microsoft.com/support/kb/articles/Q173/1/61.ASP

>DHCP (Dynamic Host Configuration Protocol) Basics
>http://support.microsoft.com/support/kb/articles/Q169/2/89.ASP

>TCP/IP & NBT Configuration Parameters for Windows NT and Windows 2000
>http://support.microsoft.com/support/kb/articles/Q120/6/42.ASP