Windows Internet Name Service (WINS)

Overview

In the early days of personal computing, both IBM and Microsoft used NetBIOS to provide programmers and applications with access to networking functions and features. NetBIOS was originally developed for IBM by Sytek Corporation as an extension to the BIOS, which an application could access by making BIOS calls.

In Microsoft Windows Server 2003, as with earlier versions of Windows, NetBIOS is both a transport-independent network interface and a session management and data transport protocol. NetBIOS can work over any of the Windows network transport protocols,including NWLink (IPX) and TCP/IP. Applications using NetBIOS can run over any of the configured transport protocols. Windows networking clients traditionally have used NetBIOS for a variety of functions, including file and printer sharing and browsing.

RFCs 1001 and 1002 define the functions and features of a NetBIOS service on a TCP/UDP transport, also known as NetBIOS over TCP/IP (NetBT). These RFCs, which were published in 1987, document the following three principal services for NetBIOS applications running over TCP/IP:

• Name serviceProvides computers with the ability to acquire and defend NetBIOS names and locate the holders of those names
• Session serviceProvides reliable message exchange, conducted between a pair of NetBIOS applications typically running on separate computers
• Datagram serviceProvides an unreliable, nonsequenced, connectionless message-passing service for NetBIOS applications

The NetBIOS session and datagram services enable NetBIOS applications to send messages to each other. These services are based on individual computers having NetBIOS names. The NetBIOS name service provides these applications with the ability to acquire and register a name, locate computers holding a specific name, and resolve a given NetBIOS name into an IP address. The datagram and session functions are outside the scope of this chapter.

WINS is a NetBIOS name server that NetBIOS clients can use to register, defend, and resolve NetBIOS names. WINS provides several benefits to an organization:

• Name registration and name resolution facilities for down-level NetBIOS-based computers
• Dynamic database maintenance to support computer name registration and resolution
• Centralized management of a scalable NetBIOS name database

WINS implements the name service features of a NetBIOS name server, as defined in RFCs 1001 and 1002. However, to scale for larger networks, WINS also provides replication facilities, although these are not defined in RFCs 1001 and 1002.

In earlier versions of Microsoft Windows NT, WINS played a critical role in enabling clients to locate servers and services. This included the Windows NT directory services, where clients used NetBIOS to locate Windows NT 4.0 domain controllers. NetBIOS session and datagram services were used as the basis of NT Directory services (Directory operations in Windows Server 2003 do not use NetBIOS). File and print sharing also makes use of NetBIOS.

An organization that uses all Microsoft Windows XP, Windows 2000, and Windows Server 2003 computers or a mixture of these computers and third-party operating systems such as UNIX, and whose applications fully support the use of Domain Name System (DNS), can largely eliminate NetBIOS, having little or no need for WINS. However, doing so would mean any application reliant on NetBIOS, such as the computer browser service, would not function.

Most organizations, however, need to support older computers—down-level clients—as well as other services and applications that require NetBIOS network names. This includes computers that run Microsoft Windows 98, Windows Millennium Edition (Windows Me), and all versions of Windows NT. Organizations supporting computers running these operating systems can continue to find WINS an important service during the deployment of Windows Server 2003.

Overview of WINS in Windows Server 2003

The following sections describe the characteristics of WINS in the Windows Server 2003 family.

What Is WINS?

WINS is a NetBIOS name server that enables a client to register NetBIOS names and IP addresses in a central database and to resolve NetBIOS names into IP addresses. WINS consists of two components: Windows Internet Name Service (WINS), which runs on Windows Server 2003 (as well as earlier versions of Windows Server), and a WINS client service that runs on TCP/IP-based clients. The WINS server manages a database of NetBIOS names, and replicates this database to other WINS servers. The WINS client uses the WINSserver to register names and to provide name resolution facilities (converting NetBIOS names into IP addresses). In functional terms, WINS is much like DNS, with clients registering names and performing name lookups, and servers handling the registration and resolution. The key difference is that WINS is based on NetBIOS names, rather than on DNS domain names.

RFCs 1001 and 1002 define the functions of a NetBIOS name server in some detail. In this respect, the WINS server is an RFC-compliant NetBIOS name server providing name registration and name resolution facilities. The WINS server is scalable, able to function well in networks of all sizes.

More Info

Read about the functions of a NetBIOS name server in RFCs 1001 and 1002, which can be found in the Rfc folder on the companion CD-ROM.

All servers running members of the Windows Server 2003 family (including Standard Edition, Enterprise Edition, Web Edition, and Datacenter Edition) include a WINS service, although this service is not installed by default. All Windows clients include a WINS client, including Windows Server 2003, Windows XP, Windows 2000, Windows NT 4.0, Windows Me, and Windows 98. For Windows 2000, Windows XP, and Windows Server 2003 clients, the WINS client function is automatically installed.

Key WINS Terms

In Windows Server 2003, NetBIOS is a network interface, allowing applications and key system components to communicate across a network, and a protocol for allowing that communication. System processes that make use of NetBIOS include the Workstation, Server, and Computer Browser services. The following is an explanation of key termsrelating to WINS and an overview of WINS operations.

Network Resources and End-Nodes

A network resource is a process running on a specific computer. This could be the Server service running on a file server, for example. The specific computer that runs the network resource process is referred to as an end-node. For applications to interoperate and for users to access key resources, every network resource needs a name.

NetBIOS Names

Each network resource in Windows is identified by a NetBIOS name. In Windows, each NetBIOS name can be up to 15 characters in length. The final, sixteenth character, which is allowed in RFCs 1001 and 1002, is reserved by Windows for the NetBIOS name suffix. The NetBIOS name cannot start with an *, and the NetBIOS name is not case-sensitive.

NetBIOS Name Types

A NetBIOS name can be either a unique name, owned by just one end-node, or part of an Internet group, which can include multiple end-nodes. Each computer runningWindows Server 2003 has a Server service and a Workstation service for the purposes of sharing files. These services each have a unique NetBIOS name that allows clients to find and use these services. The set of domain controllers within a single domain would all share an Internet group NetBIOS name. When resolving a NetBIOS address to anIP address, unique names resolve to a single IP address, whereas Internet group addresses typically resolve to multiple addresses.

The NetBIOS namespace is flat, unlike DNS, which is hierarchical. This means that a unique NetBIOS name can be used only once within a network. Multiple computers can belong to a NetBIOS Internet group. Two computers with a Server service running, for example, cannot have the same NetBIOS computer name. This can pose problems for very large organizations, and the NetBIOS scope identifier (ID) provides one solution to this issue.

NetBIOS Name Suffix

Although RFCs 1001 and 1002 allow NetBIOS names to be 16 characters, as noted earlier, the sixteenth character in the Windows NetBIOS name is reserved for the NetBIOS name suffix. This suffix is used by Windows networking software to identify and locate specific network resources. Thus, an end-node can register multiple names, based on the computer, domain, or user name, and a suffix to indicate the services available on that machine. WINS clients can then construct a NetBIOS name based on computer, user, or domain name, and the appropriate suffix to locate those relevant network resources.

For example, the Messenger service has the suffix 0x03. To send a message toCOMPUTER42, the client would send a message to the Workstation service on Computer42, or COMPUTER42[03]. Note that in the full 16-character NetBIOS name notation, the first 9 characters of the NetBIOS name would be COMPUTER42, the next 6 characters would be " " (blank), and the final character would be 0x03.

Table 18-1 lists common NetBIOS suffixes used with Windows Server 2003. The suffixes are listed in hexadecimal format because many of them are unprintable otherwise.

Table 18-1: Common NetBIOS Suffixes Used with Windows Networking

Name	NetBIOS Suffix (Hex)	Type	Usage
	00	U	Workstation service
	03	U	Messenger service
	20	U	Server service
	03	U	Messenger service
	00	G	Domain name
	1B	U	Domain master browser and primary domain controller emulator
	1C	G	Domain controllers
	1E	G	Browser service elections
<..—__MSBROWSE__>	01	G	Master browser

In addition to these common NetBIOS suffixes used by Windows Server 2003, other applications such as Microsoft Exchange, Lotus Notes, and others also register NetBIOS names. See knowledge base articles Q314104, Q163409, and Q194338 for more details on these names.

Note

Microsoft produces a series of Knowledge Base articles describing features and functions of the various Windows operating systems. Some of these knowledge base articles can be found on Technet, and the full Microsoft Knowledge Base is available on the Web at http://support.microsoft.com/search. At the Web site, you can search for an article by its ID number, such as Q314104.

NetBIOS Name Service Operations

NetBIOS name service operations involve registering, defending, querying, and releasing NetBIOS names. Additionally, NetBIOS session and datagram services use these name service operations to locate resources. For example, if a Windows Server 2003 computer user wants to access a file share on a remote system, that user enters the remote computer name and share name using Microsoft Explorer. Explorer uses NetBIOS name services to determine the remote server's IP address, and can then issue NetBIOS session-level commands to access the shared resource.

NetBIOS name service operations are carried out on the wire, using either IP broadcasts or a NetBIOS name server. The use of broadcasts might be acceptable for small local area networks (LANs). However, in larger networks, the use of broadcasts, which could result in broadcast storms, is undesirable. Such networks should implement WINS.

NetBIOS Scope

The NetBIOS namespace is flat, meaning that all names must be unique on an internetwork. If you have a computer called KAPOHO and it is properly defending its computer name, no other network computer can call itself KAPOHO. This limitation can cause difficulties for larger organizations.

As RFC 1001 describes, an approach to resolving this flat namespace is the use of an additional qualifier for the NetBIOS name. RFC 1001 defines the NetBIOS scope as "the population of computers across which a registered NetBIOS name is known." To identify the NetBIOS scope, the NetBIOS scope identifier is used. The NetBIOS scope identifier is a character string, similar in format and function to the DNS domain name.

The use of the NetBIOS scope in the Windows Server 2003 family, however, is limited in that a user cannot specify the scope directly by using Control Panel or a command-line tool. The NetBIOS scope of a Windows 2000, Windows XP, or Windows Server 2003 computer can be provided as part of the computer's IP parameters received from a Dynamic Host Configuration Protocol (DHCP) server or using a change to the computer's registry. If configured in this way, the NetBIOS scope is automatically appended to all NetBIOS names when name commands are invoked. The effect is that an end-node with a given NetBIOS scope can communicate only with other end-nodes configured with the same NetBIOS scope.

You can set the NetBIOS scope either by specifying a scope as part of a DHCP scope or by editing the registry. The registry key used to change the NetBIOS scope manually is as follows:

Key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetBTParameters or
Key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetBT
 AdaptersInterfacesInterfaceGUID
Value name: ScopeId
Value type: REG_SZ - Character string
Valid range: Any valid DNS domain name consisting of two dot-separated parts, 
or an
asterisk (*)
Default: None
Present by default: No

Caution

Although the use of the NetBIOS scope identifier might offer some benefits, it also might complicate communication with other systems. In addition, the inadvertent use of a NetBIOS scope identifier can make troubleshooting problems that arise from such use more difficult to resolve. In general, you should avoid using this feature.

NetBIOS Node Types

To allow for the various sizes of NetBIOS networks, RFCs 1001 and 1002 use the concept of node type to determine how a particular computer should perform name service functions. The node type defines how name service operations are to be performed.

An end-node can be one of the following four node types:

• B-Node (Broadcast Node)Name registration and name resolution operations are performed using broadcasts only. This is usually the best option for a very small, single subnet network.
• P-Node (Point-to-Point Node)Name registration and name resolution operations are done using a NetBIOS name server (WINS) only. This node type can be used to eliminate local subnet broadcasts, but might cause network resources on the local subnet to not be resolved unless the computers have updated the WINS server.
• M-Node (Mixed Node)A combination of B-Node and P-Node, where name registration and resolution are done initially using broadcasts. If name resolution is not successful using broadcasts, then a NetBIOS name server is used. This is useful in cases where the WINS server is on a remote network, as the client first attempts to resolve the name locally before using wide area network (WAN) resources for the resolution.
• H-Node (Hybrid Node)A combination of P-Node and B-Node, where name registration and resolution are done initially using a WINS server. If the name resolution is not successful using the WINS server, broadcasts are used. This is the default node type for Windows-based WINS clients.

By default, computers running Windows Server 2003 are B-Node. If you configure your Windows Server 2003 computer to use a WINS server, it becomes H-Node. You can configure your computer to be P-Node or M-Node by manually editing the registry. In addition, the administrator can set DHCP parameters to set the node type for a DHCP client.

The registry key used to manually change node type is as follows:

Key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetbtParameters or
Key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetbt
 AdaptersInterfacesInterfaceGUID
Value name: NodeType
Value type: REG_DWORD - Number
Valid range: 1,2,4,8 (B-Node, P-Node, M-Node, H-Node)
Default: 1 or 8 based on the WINS server configuration
Present by default: No

Microsoft Modified B-Node

Because it is based on broadcasting, NetBIOS B-Node behavior does not generally scale beyond a single subnet. This can be partially overcome by configuring routers to forward NetBIOS broadcasts, but this also does not scale, and is rarely done. To overcome these inherent limitations of RFC-compliant B-Node, Microsoft has extended the B-Node for name service operations. Known as modified B-Node, these extensions add two name-lookup facilities to B-Node:

• The NetBIOS name cacheAn in-memory cache of recently resolved names that can be searched before other name resolution methods are attempted
• The LMHOSTS fileA flat file, contained in %systemroot%System32DriversEtc, that contains a static list of NetBIOS names and their IP addresses

If using LMHOSTS is, for some reason, undesirable, you can disable this from the advanced properties of the TCP/IP protocol.

Name Registration

Whenever a network resource becomes available for use—for example, when a file server starts up—the network resource registers its relevant NetBIOS name to enable clients (for example, file server clients) to locate that network resource. The registration procedure also ensures that the name being registered is not already in use by another computer. For WINS clients configured to use P-Node, M-Node, and H-Node, the client also informs the WINS server of the name and IP address.

Time To Live (TTL)

In general, NetBIOS names are not held or owned permanently. Each name registered successfully in WINS has a limited time to live (TTL). When the TTL for a NetBIOS name expires, it is up to the network resource to reregister that name. If a network resource registers a name with a WINS server and the TTL expires, the name can be removed from the WINS server. Windows client computers attempt to reregister their NetBIOS names at one-half of the TTL, or when the computer is rebooted.

Name Defense

Once registered, all unique NetBIOS names need to be defended to ensure that two different network resources do not claim the same NetBIOS name. If a computer attempts to register a NetBIOS name that is already being used by another computer, the name's owner needs to defend the name. If a network resource finds that the name it is attempting to resister is already in use—for example, a computer booting up is configured with a computer name of one that is already running—the network resource should fail gracefully. Windows Server 2003 processes, such as the Server service, also write an error event to the event log for later analysis and troubleshooting.

If the name's owner is a B-Node client, the owner must accept responsibility for defending the name by listening for a Name Registration Request and broadcasting a negative Name Registration Response.

For P-Node clients, name defense is more complicated. If a P-Node client attempts to register a name with a WINS server that the WINS server believes to be in use, the WINS server first attempts to contact the computer that has previously registered the NetBIOS name. If the WINS server successfully contacts the registered owner, the WINS server sends a negative Name Registration message to the client attempting to register the name. If, on the other hand, the WINS server cannot reach the previously registered owner of the name, it sends a positive Name Registration Response.

NetBIOS Name Resolution

When a computer wishes to communicate with another using NetBIOS, it must determine the remote computer's IP address before communications can be established. Name resolution is the process of determining a computer's IP address based on a NetBIOSname. The general approach a WINS client takes to resolving names using NetBIOS is as follows:

• The client checks to see if the name is in the local NetBIOS name cache. For more information on the NetBIOS name cache, see the section entitiled "NetBIOS Name Cache," later in this chapter.
• The client attemps to resolve the name using a WINS server, a broadcast, or both, depending on the node type.
• If the computer is configured to use LMHOSTS, this file is consulted for the name's IP address.
• If all attempts to resolve the NetBIOS name fail, the NetBIOS name is converted into a host name and all the host name resolution methods areattempted.

Windows WINS clients attempt the following name resolution steps that vary depending on the NetBIOS node type and whether a WINS proxy has been configured, as follows:

• B-Node clients broadcast NetBIOS Name Request messages to the local subnet. If a computer holding the name is on that local subnet, the computer issues a positive Name Query response, containing the required IP address. If there is a WINS proxy agent on the subnet when a NetBIOS Name Request message is broadcast, and there is no reply from other computers on the subnet, the WINS proxy agent attempts to resolve the name on behalf of the client. This is a good approach for very small networks (possibly with no WINS servers) and is the default for a computer with no WINS server configured.
• P-Node clients unicast NetBIOS Name Request messages to the configured WINS server. If the WINS server has the required name, it sends a positive Name Query Response, containing the required IP address; otherwise, the WINS server sends a negative Name Query Response. If the WINS client gets no response from its WINS server, and is configured with the IP addresses of additional WINS servers, the client tries these additional WINS servers. This approach minimizes broadcasts on the local network but can cause WAN resolution traffic, even if the network resource is local to the WINS client.
• M-Node clients first attempt to use B-Node behavior to resolve the name, and if this is not successful, M-Node clients attempt P-Node behavior. This is particularly useful when the client is on the other side of a WAN link to the network resource, but can cause additional broadcast traffic on the local subnet.
• H-Node clients first attempt to use P-Node behavior to resolve the name, and if this is not successful, H-Node clients then attempt to use B-Node behavior. As with P-Node, this approach reduces local broadcast traffic for names held by the WINS server, but uses the local broadcast to attempt to resolve the name.

  Note

  Early WINS clients supported a maximum of only two WINS servers (a primary and a secondary). To provide additional fault tolerance for clients' computers,Windows Server 2003, Windows XP, Windows 2000, Windows Me, and Windows 98 allow you to specify up to 12 WINS servers per interface. These extra WINS server addresses are used only if the primary and secondary WINS servers fail to respond.

If none of these steps is successful in resolving the NetBIOS name, the WINS client computer continues attempting to use host name resolution, first checking the local HOSTS file, and then contacting configured DNS servers. If, after all these steps, the name still cannot be resolved, Windows indicates an error to the application.

This series of steps is intended both to provide the maximum amount of fault tolerance to the client and to accommodate incorrectly configured systems. It is all too easy, for example, for a new administrator to add NetBIOS names to the HOSTS file instead of the LMHOSTS file.

If a computer uses broadcasting to resolve a NetBIOS name, it cannot be sure that a lack of response is significant. Because User Datagram Protocol (UDP) is used as the transport for NetBIOS name operations, the packet could have been dropped. To compensate for the potential unreliability, the client resolving a name, by default, broadcasts the name resolution request three times, with a 750-millisecond interval between each attempt. Use the following registry entry to change the number of broadcasts attempted:

Key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetbtParameters
Or
Key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetbtParameters
 AdaptersInterfacesInterfaceGUID
Value name: BcastNameQueryCount
Value type: REG_DWORD-Number
Valid range: 1-0xFFFF
Default: 3
Present by default: Yes

Use the following registry entry to change the interval between broadcasts:

Key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetbtParameters
 AdaptersInterfacesInterfaceGUID
Value name: BcastQueryTimeout
Value type: REG_DWORD-Time in milliseconds
Valid range: 100–0xFFFFFFFF
Default: 0x2ee (750 decimal)
Present by default: Yes

Note

Although it might seem like a good idea to reduce the number of broadcasts, if you reduce the number to one, or make the time interval between broadcasts too small, you might increase the possibility that a busy WINS server would not be able to respond quickly enough. In that case, the client would fail toresolve a name for a system that otherwise might have been able to respond(using the default values). Test any changes to these parameters carefully.

NetBIOS Name Cache

To minimize the use of NetBIOS Name Resolution Queries, WINS clients use a NetBIOS name cache that holds recently resolved NetBIOS names. If a WINS client needs to resolve a NetBIOS name, it examines this cache before issuing a Name Query Request.

By default, the NetBIOS name cache holds 16 resolved names, each for 10 minutes. This is probably adequate for most client computers although you can modify both the size and time-out values. If a client resolves more NetBIOS names than the cache can hold, the oldest entries are discarded, and the new name (and IP address) is added to the name cache.

By making a registry change, you can configure the name cache to be one of the following three sizes:

• SmallHolds 16 entries (this is the default)
• MediumHolds 128 entries
• LargeHolds 256 entries

Use the following registry entry to modify the NetBIOS name cache size:

Key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetbtParameters
Value name: Size/Small/Medium/Large
Value type: REG_DWORD
Valid range: 1, 2, 3 (Small, Medium, Large)
Default: 1 (Small)
Present by default: Yes

By default, entries in the NetBIOS name cache time out and are deleted after 10 minutes. To adjust this time-out period, use the following registry entry:

Key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetbtParameters
Value name: CacheTimeout
Value type: REG_DWORD
Valid range: 60000–0xFFFFFFFF
Default: 0x927c0 (600000 milliseconds = 10 minutes)
Present by default: Yes

The value holds the length of time, in milliseconds, for which a NetBIOS lookup is cached. You can use the NBTSTAT -c command from the Windows Server 2003 command prompt to view the entries in the local NetBIOS name cache.

Note

By increasing the size of the NetBIOS name cache and increasing the cache time-out value, you can reduce the number of lookups performed against a busy server. For many environments with largely static IP addresses for all key servers, this change might be appropriate. However, by making this change, you also increase the probability that an entry in the cache is no longer accurate (which could occur in a highly dynamic TCP/IP network). This trade-off between accuracy and amount of lookup traffic should be considered carefully and tested thoroughly.

Name Release

If the network resource terminates gracefully, it can no longer defend the name, and the resource performs name release. For B-Node clients, this is done simply by stopping the name defense of the name being released. For P-Node clients, name release is accomplished by sending a Name Release message to the WINS server.

WINS Proxy

A WINS proxy is a WINS client that can perform NetBIOS name operations (register, release) on behalf of other non-WINS clients. Older, or third-party, NetBIOS clients might not be configured or might not be able to be configured to use WINS. Instead, they would rely on B-Node behavior. To provide these clients with use of a WINS server's resources, you can use a WINS proxy to act on behalf of other computers that are unable to use WINS. A WINS proxy can also be used during the migration from a broadcast environment to a WINS environment. You can set up a WINS server and a WINS proxy, then migrate systems over one by one without affecting name resolution for the systems that have not yet been converted. The WINS proxy functions as follows:

• When a B-Node WINS client issues a name registration broadcast for a NetBIOS name, the WINS proxy performs a name lookup, first using its local NetBIOS name cache and, if necessary, sending a Name Query Request to the WINS server. If the name is found, the proxy sends a negative Name RegistrationResponse back to the B-Node client attempting to register the name.
• When a B-Node client broadcasts a name resolution, the proxy attempts to resolve the name, first by using information locally contained in its cache of remote names and then by sending a Name Query Request to the WINS server. If the name lookup is successful, the proxy sends a Name Query Response. If it is not successful, the proxy sends a negative Name Query Response.

You can configure a system to act as a WINS proxy for B-Node clients on the local subnet by editing the following registry key:

Key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetbtParameters Or
Key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetbtParameters
 AdaptersInterfacesInterfaceGUID
Value name: EnableProxy
Value type: REG_DWORD - Boolean
Valid range: 0, 1 (False, True)
Default: 0 (False)
Present by default: No

Setting this value entry to 1 enables the system to act as a proxy NetBIOS name server for the networks to which NetBT is bound (or to the chosen interface). A WINS proxy listens for broadcast Name Query Requests, resolves them using WINS (or the proxy's NetBIOS name cache), and broadcasts the result back to the client. The WINS proxy provides B-Node WINS clients with the ability to interoperate with WINS servers.

WINS Database Entries

When a name is registered, or released, the WINS server updates its internal database. A WINS database entry holds the name of the network resource, its associated IP address, TTL, and version number. The version number is the basis for WINS server replication.

WINS Server Replication

In large enterprise networks, having a single WINS server is not generally advisable. A single server providing a service to a large number of clients would represent a single point of failure. Also, it could require clients to use WAN links to resolve names of network resources that might turn out to be local.

To provide redundancy, load balancing, and scalability, and to reduce the WAN traffic involved with Name Registration and Name Query options, WINS servers can be configured for replication, which replicates WINS database entries from one server to another. WINS server replication enables a WINS client computer to register NetBIOS names on one WINS server, and to have that WINS server replicate the name so that it is available to all WINS servers, and to all WINS clients, in an organization. This can expedite client name resolution because the use of WAN links for WINS queries is avoided.

For a WINS server to replicate its information, the server must be configured with at least one other WINS server as a replication partner. WINS replication partners replicate names known on one server to the other partner servers. There are two replication roles for a WINS server: pull partner and push partner. A pull partner is a WINS server that pulls WINS entries from its configured partner(s). A push partner is a WINS server that pushes updated WINS entries to its configured partner(s).

All replication traffic is pulled, with one partner requesting updates from a configured partner. The main difference between push and pull partners is who and what triggers the replication event. Pull partners pull name-to-IP-address mapping updates from their replication partners, either when the WINS service starts or at intervals configured by the administrator. On the other hand, push partners inform configured partners that updates exist, either when the WINS service starts or after a certain number of updates have accumulated. After the partner has received the notification that updates exist, the partner can pull these changes down to update its local WINS database.

Note

The WINS replication topology for an organization is determined by anadministrator based on the business needs for NetBIOS name resolution. Replication involves pairs of servers replicating from one to the other, which can involve WAN traffic. Microsoft recommends making all replication push/pull, which is a good default, especially for LAN-connected WINS servers. When replicating across WAN links, pull replication (where each partner pulls at a predefined interval) might be a better alternative.

Adapter Status

NetBIOS end-nodes can query the status of another system. This status is known asthe adapter status. The NBTSTAT.EXE command, which is provided on Windows 2000, Windows XP, and Windows Server 2003, can be used to issue a node status query against another computer. In Windows Server 2003, this returns only the NetBIOS names owned by the remote computer. RFC 1002 defines a number of statistics that are returned in an Adapter Status message, but in Windows Server 2003 these are not returned or displayed by NBTSTAT.EXE.

How WINS Works

To understand how WINS itself works, you also must understand how WINS clients operate and how NetBT, in general, works. This section describes key functions and features of both NetBIOS name services and WINS clients and servers.

Registering NetBIOS Names

The process of registering and renewing NetBIOS names by an end-node varies depending on the NetBIOS node type configured for the end-node. In general, an end-node that wants to register the NetBIOS name issues a NetBIOS Name Registration Request to register the name. Once a NETBIOS name is registered, other computers can then resolve that name and use the resulting IP address to communicate with the end-node. When the network resource terminates, it releases the name, although in the case of a nongraceful termination, a name release might not be performed.

Name Registration Request

When a network resource starts up, it attempts to register the related NetBIOS names by issuing a NetBIOS Name Registration Request. This depends on the node type as follows:

• B-NodeWhen a B-Node client registers a name, it broadcasts a name registration packet to the local network. If the name is currently in use by another node, the name's owner sends a negative Name Registration Reply. A B-Node client that does not receive a negative Name Registration Reply then considers itself the owner of the name and carries out name defense of that name.
• P-NodeWhen a P-Node client registers a name, it sends the name to the configured WINS server as a unicast packet. If the name being registered has previously been registered, the WINS server attempts to contact the registered owner to check whether the name is actively being used. If the name is still in use, the WINS server sends a negative Name Registration Reply to the client. If the name is not in use, the WINS server sends a positive Name Registration Reply. The WINS server might also send a Wait Acknowledgment (WACK) message to the client attempting to register the name. This message indicates that the WINS serveris still attempting to determine whether the name can, in fact, be registered.
• M-NodeAn M-Node client attempts to register the name using broadcasts, as for a B-Node client. In the absence of an objection, the client attempts to register the name with the configured WINS server. Although the broadcast approach might yield an owner of the name, and therefore would terminate the name registration process, it is insufficient to confirm name ownership for an M-Node client.
• H-NodeA Windows .NET Server H-Node client registers the name using WINS. If this is successful, the registering client assumes ownership of the name.

The Network Monitor trace in Capture 18-01 (included in the Captures folder on the companion CD-ROM) shows a name registration by an H-Node client for the name KAPOHO10[00]. The Network Monitor trace in Capture 18-02 (in the Captures folder on the companion CD-ROM) shows a name registration by a B-Node client for the name KAPOHO10[00].

Positive Name Registration Reply

Positive Name Registration Replies are sent from a WINS server to a WINS client on successfully registering a NetBIOS name. If a WINS client sends a WINS server a request to register a unique NetBIOS name, and that name is not presently registered, the WINS server registers the name and sends a positive Name Registration message to the computer that registered the name. Computers that send NetBIOS Name Registration Requests using broadcasts, such as a B-Node client, do not receive a positive Name Registration Reply.

If a WINS client sends a WINS server a request to register an Internet group name, the WINS server always sends a positive Name Registration Reply. B-Node clients send NetBIOS Name Registration messages. A B-Node client broadcasts multiple NameRegistration messages, and if no negative Name Registration Replies are received, itassumes ownership of the NetBIOS name. The Network Monitor trace in Capture 18-1 shows a successful name registration by an H-Node client, including a positive NameRegistration message.

Negative Name Registration Reply

A WINS server that receives a request to register a unique NetBIOS name that is already registered should reject the request by issuing a negative Name Registration Reply message, provided that the end-node owning that name is able to defend the name. Before sending the negative Name Registration Response, the WINS server checks with the current owner of the NetBIOS name to determine whether that computer is still active. This situation could occur, for example, if a laptop is moved to a different subnet, or for some reason is reconfigured to have a new IP address.

A computer sending NetBIOS Name Registration Requests using broadcasts (for example, a B-Node client) also receives a negative Name Registration Reply if another computer active on that subnet currently owns the name. A computer registering NetBIOS names using WINS sends its Registration Request messages using unicast. The WINS server sends a negative Name Response message if the name being registered has previously been registered by some other end-node, and if that other end-node can defend the name.

The Network Monitor trace in Capture 18-03 (included in the Captures folder on the companion CD-ROM) shows a computer attempting to register the NetBIOS name KAPOHO10 with a WINS server. This name is in use on another computer and the second packet in this trace shows the negative Name Response message.

Wait Acknowledgment

If a WINS server receives a request to register a unique NetBIOS name that is already registered, it checks with the registered owner of that name. In this case, it might issue a WACK message to the computer attempting to register the name. The purpose of this is to inform the client that the WINS server might not yet be able to provide a name reply. To enable the client to be aware that the server has not failed (and is not performing name service operations), a WINS server sends a WACK message if it cannot answer the query immediately.

The Network Monitor trace in Capture 18-04 (included in the Captures folder on the companion CD-ROM) shows a WACK message. The WINS server has to contact another system, and issues the WACK while that contact is accomplished. This message is part of a name resolution failure, which is discussed in the section entitled "Resolving NetBIOS Name Registration Conflicts," later in this chapter.

Name Renewal Request

Like DHCP leases, NetBIOS names registered with a WINS server have a limited life, or TTL, and must be refreshed before that life expires. In Windows Server 2003, the default TTL for NetBIOS name entries held in WINS is 6 days. The WINS administrator can change this to any time between one minute and 365 days. When an end-node registers a NetBIOS name with a WINS server, the end-node receives a positive Name Query Response, which contains a TTL for the name.

Much like DHCP clients, a WINS client attempts to renew any NetBIOS names it holds at half the TTL, for instance, every three days. Additionally, each time the computer is restarted, or the Windows service that registers a NetBIOS name restarts, a new Name Registration message is sent to the WINS server, renewing the name (assuming, of course, that the WINS server successfully registers the name).

The Network Monitor trace in Capture 18-05 (included in the Captures folder on the companion CD-ROM) shows a name refresh for the name KAPOHO10[00]. In this trace, the TTL for the record, as returned from the WINS server, is 2400 milliseconds.

Resolving NetBIOS Name Registration Conflicts

A name conflict occurs when two (or more) end-nodes want to register the same unique NetBIOS name. In most cases, this is caused by a configuration error, such as giving two computers the same name. When two computers attempt to register a unique NetBIOS name, the second end-node attempting to register the NetBIOS name fails, and an error is logged.

The Network Monitor trace in Capture 18-04 (included in the Captures folder on the companion CD-ROM) shows a computer (IP address 10.10.1.52) attempting to register the name JASMINE[00]. However, the WINS server already has a registration for that name. The WINS server first issues a WACK to the computer at 10.10.1.52, and then queries theregistered owner of the NetBIOS name JASMINE[00]. The query is a simple Name Query Request sent to the registered owner at IP address 10.10.1.102. This computer is active and responds to the request with a Name Query Response. Because WINS has ascertained that the registered owner still owns the name, WINS sends a registration response back to 10.10.1.52 with an error code set, indicating that the name is active.

Releasing NetBIOS Names

A name can be released either actively or silently. A Windows Server 2003 P-node client releases a held NetBIOS name by sending the WINS server a Name Release message containing the NetBIOS name to release. Alternatively, if an end-node fails to renew the name, after the name's TTL has expired, the name becomes available for use by another end-node. B-Node clients can effectively release a name by no longer defending it.

With Windows Server 2003, the NBTSTAT.EXE command, used with the -RR switch, releases all currently registered NetBIOS names and then reregisters them. This can be useful for diagnostic purposes.

Name Release Request and Name Release Response

When an end-node that is configured to use a WINS server wants to release a registered NetBIOS name, the end-node sends a Name Release Request message to the WINS server. The WINS server responds with a Name Release Response. Usually, the release response has a result code of 0, indicating that the name was successfully released. The WINS server could send a negative Name Release message, although it would be ignored by the end-node sending the Name Release message.

The Network Monitor trace in Capture 18-06 (included in the Captures folder on the companion CD-ROM) shows the computer at IP address 10.10.1.52 releasing the NetBIOS names it owns. It does this by sending the WINS server, at 10.10.1.200, a Name Release message. For each name released, the WINS server sends a Release Response.

Resolving NetBIOS Names

When a Windows Server 2003 computer needs to resolve a NetBIOS name, it issues a NetBIOS Name Query Request, either using a broadcast or sending the request directly to a WINS server, depending on node type. If the Name Query Request is sent to a WINS server and is one that can be resolved, the WINS server sends a Name Query Response to the computer issuing the query. If the WINS server cannot resolve the name, it issues a negative Name Query Response. If the computer performing the name resolution is using B-Node behavior, it issues a Name Query Request; and if the end-node owning the name is on the local subnet, it responds. However, if there is no end-node owning that name on the local subnet, the host that is querying the name times out, although this can take longer than getting a negative Name Query Response from a WINS server.

Name Query Request

A Name Query message contains the NetBIOS name to be resolved and is sent either to the local network or to the WINS server, or both, depending on the NetBIOS node type. If the end-node uses broadcast to find the name, it issues three broadcasts, by default, before failing.

When a user performs some operation using names on a Windows Server 2003 computer—such as typing NET VIEW \XXX at the Windows Server 2003 command prompt, or typing \XXX in Windows Explorer's Address box—it is not always clear to Windows just what type of name is being resolved: host name or NetBIOS name; nor is it clear which name resolution method gives the fastest results.

In Windows NT 4.0, the operating system first attempts one name resolution (such as NetBIOS resolution or host name resolution), and if that does not succeed, the operating system tries the other method. This results in delays if the wrong method is chosen. To reduce the delay, Windows Server 2003 attempts to resolve the names using both methods simultaneously.

The Network Monitor trace in Capture 18-07 (included in the Captures folder on the companion CD-ROM) shows an M-Node client attempting to resolve the name XXX. The Network Monitor trace in Capture 18-08 (included in the Captures folder on the companion CD-ROM) shows the same attempted resolution by an H-Node client. The same computer generated both traces when the user typed NET VIEW \XXX at the Windows Server 2003 command prompt.

Notice that, in both of these traces, a DNS Query is attempted before any NetBIOS name resolution is performed. Also note that in Capture 18-07, the M-Node client first attempts to resolve the name by broadcasting on the local network. When this fails, the client contacts the WINS server. In Capture 18-08, the H-Node client first attempts to contact WINS. When this fails to resolve the name, the H-Node client then broadcasts the Name Query Request message.

Positive Name Query Response

When a NetBIOS host or a WINS server receives a Name Query Request for a NetBIOS name that can be resolved, the receiving system returns a Name Query Response. The Name Query Response has the return code set to 0 (indicating successful resolution) and includes a resource record (RR) giving the IP address of the system owning the name. If the name being queried is a unique name, only one IP address is returned. If the name being queried is a group name, one or more IP addresses can be returned.

The Network Monitor trace in Capture 18-09 (included in the Captures folder on the companion CD-ROM) shows WINS successfully resolving the NetBIOS name KONA[00]. The response contains an RR, with the IP address of the end-node holding the NetBIOS name 10.10.2.200.

Negative Name Query Response

When a WINS server receives a Name Query Request for a NetBIOS name that cannot be resolved, the WINS server returns a negative Name Query Response. The negative Name Query Response has the return code set to indicate that the requested name does not exist. The Answer count in the returned Name Query Response is also set to 0.

The Network Monitor trace in Capture 18-10 shows a negative Name Query Response.

Refreshing NetBIOS Names

Each registered NetBIOS name has a TTL. If the owning end-node wants to continue using the NetBIOS name, it must refresh the name before that TTL expires. For names registered with WINS, the administrator configures the TTL value. Windows 2000, Windows XP, and Windows Server 2003 computers attempt to reregister each NetBIOS name at half the TTL.

The Network Monitor trace in Capture 18-05 (included in the Captures folder on the companion CD-ROM) shows an end-node reregistering the NetBIOS name KAPOHO10[00] using a Name Refresh message. In this trace, the refresh is successful, therefore the WINS server responds with a Registration Response message.

Determining Adapter Status

RFCs 1001 and 1002 provide for a mechanism so that an end-node can determine the status of a local or remote adapter of another end-node. The adapter status information includes the NetBIOS names registered at that end-node and counts of various statistics.

In Windows Server 2003, you can use the NBTSTAT.EXE command, with the –A or –a switch to obtain a remote computer's NetBIOS adapter status. If the local or remote host has NetBT disabled, however, this command does not succeed.

The Network Monitor trace in Capture 18-11 (included in the Captures folder on the companion CD-ROM) shows a trace of an adapter status Request and Response message. The command used to generate this trace, along with its output, is as follows:

C:>nbtstat -a 10.10.1.66
 
Local Area Connection:
Node IpAddress: [10.10.1.68] Scope Id: []
 
 NetBIOS Remote Machine Name Table
 
 Name Type Status
 ——————————————————————————————————————————
 KAPOHO11 <00> UNIQUE Registered
 KAPORG <00> GROUP Registered
 KAPOHO11 <20> UNIQUE Registered
 KAPORG <1E> GROUP Registered
 
 MAC Address = 00-50-56-40-50-C1
 

NetBIOS Name Service Messages

Most interactions between a WINS client and a WINS server consist of a request (such as a Name Registration Request) sent from a client to a server, and a subsequent response sent in the opposite direction. For example, when a WINS client needs to resolve a NetBIOS name, it sends a Name Request message to the WINS server and receives either a negative Name Query Response or a positive Name Query Response message in return.

NetBIOS Name Service messages are sent using UDP, with UDP port 137 on both the client and the server. Because all Name Service messages use UDP, which is an inherently unreliable transport protocol, there might not be a strict one-to-one relationship between requests and responses. However, there is never more than one response generated for any given request. This means, for example, that a WINS client might send more than one Name Resolution Request before it receives a response. If the WINS server cannot answer the question promptly, it might send one or more WACK messages back to the client.

As Figure 18-1 illustrates, the general format of a Name Service message is similar to DNS messages, described in Chapter 17, "Domain Name System (DNS)."

Figure 18-1: NetBIOS Name Service message format.

A NetBIOS Name Service message consists of the following five sections:

• Name Service headerFixed length (12 octets long), holding information about the type of NetBIOS Name Service message, plus counts of the other records in the message.
• Question entriesVariable length (length defined in Name Service header) for NetBIOS Name Registration, Refresh, or Release messages; this field holds the NetBIOS name being acted on by the message.
• Answer resource recordsVariable length (length defined in Name Service header) holding RRs returned in response to a question.
• Authority resource recordsVariable length (length defined in Name Service header) holding RRs used to indicate the authority for the question being asked. These are not used in Windows Server 2003.
• Additional resource recordsVariable length (length defined in Name Service header) holding other RRs, not provided in direct answer to a question.

NetBIOS Name Service messages contain a header and one or more additional entries, depending on the Name Service messages. The specific entries that are included in each NetBIOS Name Service record are given in the description of each NetBIOS NameService message.

Name Service Header

Figure 18-2 displays the format of the Name Service header.

Figure 18-2: NetBIOS Name Service message header layout.

The Name Service header is a fixed-length set of fields that identifies the type of name service packet and the number of question entries, answer records, authority RRs, and additional records existing in the message. The other sections of a Name Query message carry either the NetBIOS names to be used in the name operation or RRs (such as theIP address) returned by a Name Service Query.

The Name Service header section consists of the following fields:

• Transaction IDA 16-bit field used to identify a specific name service transaction. The originator creates the transaction ID when it sends the request to the responder, and the responder copies the transaction ID into the reply message. If a WINS client is, for example, registering multiple names, each Name Registration Request has a different transaction ID.
• FlagsA 16-bit field containing various Name Service flags.
• Question CountA 16-bit field indicating the number of entries in the question section of a name service packet. The sender of a NetBIOS Name Service Request (for example, a WINS client attempting to register a name) always sets this value to 0-01 or more, although typically it is set at 0-01. The responder fora Name Service Request always sets this field to 0.
• Answer CountA 16-bit field indicating the number of entries in the answer RRs section of a name service packet. The sender of a Name Service Request sets this count to 0. The responder for a Name Service Request sets this to indicate the number of answers returned. This is generally 1 for unique NetBIOS name lookups, and a larger number for Internet group name lookups.
• RR CountA 16-bit field indicating the number of entries in the authority RR section of a name service packet. This number is used for recursive NetBIOS name queries, which are not implemented in Windows Server 2003. This field is set to 0 in NetBIOS Name Service messages to indicate that there are noauthority records present.
• Additional RR CountA 16-bit field indicating the number of entries in the additional RRs section of a name service packet. These records are used when an RR needs to be included in any name service operation that is not a response to a Name Query Request, such as a name release (the additional RR includes the name being released).

Name Service Header Flags Field

The Flags field, contained in the NetBIOS Name Service header, contains details about the purpose of each Name Service message. Figure 18-3 displays this field's format.

Figure 18-3: NetBIOS Name Service Flags field layout.

The Flags field holds the following fields:

• Request/ResponseA 1-bit field set to 0 to indicate a Name ServiceRequest, and set to 1 to indicate a Name Service Response.
• Operation CodeA 4-bit field that indicates the specific name service operation of the name service packet, as shown in Table 18-2.

  Table 18-2: Name Service Operation Codes and Meanings

  Operation Code	Operation
  0	Name Query Request
  0x5	Name Registration Request
  0x6	Name Release
  0x7	Wait Acknowledgment
  0x8	Name Refresh

• Authoritative AnswerIndicates whether the responder is authoritative. For Name Service requests, this is always set to 0. For responses, the computer responding to the request sets it to 1 if it is authoritative for a NetBIOS name.
• TruncationSet to 1 if the total number of responses cannot fit into the UDP datagram (for instance, the total number exceeds 576 bytes). RFC 1001 offers the possibility of using TCP to obtain the full answers, but Windows Server 2003 does not support the use of TCP in conjunction with NetBIOS name operations.
• Recursion DesiredSet to 1 by the sender of a Name Query, Name Registration, or Name Release if the sender wishes the receiver to iterate on the query. Windows Server 2003 WINS clients set this flag to 1 for all name queries. If the flag was set in a Name Service message sent to a Windows Server 2003 WINS server, the WINS server sets it in the corresponding reply. However, Windows Server 2003 does not support recursion.
• Recursion AvailableSet to 0 on all Name Request messages. TheWindows Server 2003 WINS server sets this field to 1 in Name ServiceReplies to indicate that it can perform recursive Name Query, Name Registration, and Name Release messages. If set to 0 in a Name Service Response, the client must iterate for Name Service Queries and perform challenges for any name registrations.
• ReservedTwo reserved bits set to 0.
• BroadcastSet to 0 if the Name Service message is being sent using a unicast packet (for instance, to a WINS server), or 1 if it is being broadcast.
• Return CodeA 4-bit field holding the return code. All Name Service Requests set the value to 0, which indicates a successful response. For Name Query Requests, this means the answer is in the Reply message; for Name Registrations, it means the registration was successful.

NetBIOS Name Representation

NetBIOS names sent in name service packets are encoded using a scheme that was originally designed to make NetBIOS names contained in Name Service message packets, similar to DNS names. This was considered important because the DNS specifications, at the time that RFCs 1001 and 1002 were written, were more restrictive in terms of the range of characters that could be used in the name. The full name of the network resource is the concatenation of the encoded 16-character NetBIOS name, the period (.) character, and the NetBIOS scope identifier if one is configured.

Creating the full NetBIOS resource name involves the following three steps:

1. The 16-character NetBIOS name is converted into a 32-bit unicode representation.
2. The period (.) character and the NetBIOS scope identifier are appended to the encoded 16-character NetBIOS name.
3. The resulting name is then encoded according to the rules for DNS Name Query.

The first step involves converting the original 16-byte NetBIOS name into a 32-byte string by mapping each 4-bit (half-byte) nibble to an ASCII character, as shown in Table 18-3.

Table 18-3: Converting an Original 16-Byte NetBIOS Name into a 32-Byte String

Nibble Value (in Hex)	Encoded ASCII Character
0	A
1	B
2	C
3	D
4	E
5	F
6	G
7	H
8	I
9	J
A	K
B	L
C	M
D	N
E	O
F	P

This conversion results in a name string that contains only the characters A through P, thus providing compatibility with DNS names, which were more restrictive about the content of names than NetBIOS.

As an example, consider the name of the Workstation service on the server KAPOHO (KAPOHO[03]). The full 16-character name would be "KAPOHO [03]"; that is, the name KAPOHO followed by nine spaces (or 0x20), and terminated by the hexadecimal value 0x03. Expressed in hex format, this name becomes:

4B-41-50-4F-48-4F-20-20-20-20-20-20-20-20-20-03

Converting this name into nibbles, the string would then become:

4-B-4-1-5-0-4-F-4-8-4-F-2-0-2-0-2-0-2-0-2-0-2-0-2-0-2-0-2-0-0-3

Using Table 18-3, this nibble string is then encoded into a 32-byte ASCII string, which is

ELEBFAEPEIEPCACACACACACACACACAAA

The third step involves converting the name into the DNS name format. In DNS, domain names are expressed as a sequence of labels. If the DNS name is kapoho.com, for example, this DNS name would consist of two labels (kapoho and com). Each label in a DNS message is formatted with a 1-byte length field followed by the label. The domain kapoho.com, therefore, would be expressed as 0x06kapoho0x03com0x00, where the hexadecimal digits represent the length of each label, the ASCII characters represent the individual labels, and the final hex 0 indicates the end of the name.

To complete the NetBIOS name encoding, the first label is the encoded 16-character NetBIOS name, with additional labels for the NetBIOS scope identifier, if this is used. In the example, if there is no NetBIOS scope identifier, the name would be:

0x20ELEBFAEPEIEPCACACACACACACACACAAA0x00

If a NetBIOS scope identifier, for example KAPOHO.COM, were to be used, the name would become:

0x20ELEBFAEPEIEPCACACACACACACACACAAA0x06kapoho0x03com0x00

Note

This encoding scheme seems quite complicated at first sight. It was originally designed to be compatible with the emerging DNS standards and to make it easier for computers to parse. Fortunately, Microsoft Network Monitor decodes the NetBIOS name, thus simplifying viewing NetBIOS names in Network Monitor traces.

Question Entries

In a NetBIOS name packet, a question entry represents the NetBIOS name being registered, refreshed, released, or queried. The format of a NetBIOS Name Service Question entry is based on DNS question entries. Figure 18-4 displays the Question field layout.

Figure 18-4: Name Service Question entry field layout.

The Question entry is made up of the following three fields:

• Question NameThe NetBIOS name being registered, refreshed, and so forth. The name is encoded using the NetBIOS name representation scheme described earlier in the NetBIOS Name Representation section.
• Question TypeThe type of question. Set to either 0-20, indicating that the question name is a NetBIOS name, or 0-21.
• Question ClassThe question class. Set to 0-01. This represents the IN (Internet) question class. No other question classes are supported.

RRs

RRs are used to send resource information between a client and server. Figure 18-5 displays the layout of an RR.

Figure 18-5: Name Service RR field layout.

The fields in an RR are as follows:

• Resource Record NameThe NetBIOS name, represented in the compressed name format described later in this chapter.
• Record TypeThe RR type code.
• Record ClassThe RR class code; there is only one record class, 0-01, the Internet Class.
• Time To LiveThe RR's TTL, expressed in seconds.
• Resource Data LengthA 2-byte field holding the resource data's length.
• Resource DataVariable-length data corresponding to the RR type. RFC 1002 defines values for Record Type fields as shown in Table 18-4.

  Table 18-4: Values for Record Type Fields

  Value	Description
  0-00	IP Address RR
  0-02	Name Server RR
  0-0A	Null RR
  0-20	NetBIOS General Name Service RR
  0-21	NetBIOS Node Status RR

Most Name Service records are either NetBIOS General Name Service RRs (record type 0-20) or NetBIOS Node Status RRs (record type 0-21).

Figure 18-6 displays the layout for the RR data used in General Name Service RRs (record type 0-20).

Figure 18-6: RR data layout for record type 0-20.

As Figure 18-6 shows, the RR contains a length of 6 bytes, an RDATA flags field, andthe IP address relating to this name. For instance, in a Name Registration message, this is the IP address of the owner registering the name.

Figure 18-7 displays the layout of the RDATA flags field.

Figure 18-7: RDATA flags field layout.

The RDATA contains the following three fields:

• Group FlagSet to 1 if the name is a group name; otherwise set to 0
• Owner Node TypeA 2-bit field, formatted as follows: 0 – B-Node;1 – P-Node; 0x2 – M-Node; 0x3 – H-Node
• Reserved13 bits set to binary 0

With respect to the owner node type, RFC 1002 defines the value of 11 as "Reserved for future use." In Windows Server 2003, this indicates H-Node.

Figure 18-8 displays the RDATA field for node status response RRs (Name Service record type 0x21).

Figure 18-8: RDATA layout for node status response.

As Figure 18-8 shows, the RDATA field for node status responses contains the following fields:

• Length16 bits holding the total length of the RDATA section
• Number Of Names8 bits holding the number of names in the node name array
• Node Name ArrayA variable-length array of the NetBIOS names owned by the node responding to the node status request
• Node StatisticsA set of statistics about the node's NetBIOS service

The Network Monitor trace in Capture 18-11 (included in the Captures folder on the companion CD-ROM) illustrates the Statistics field. The values for this field, however, are not displayed by the NBTSTAT command. Windows Server 2003 returns all zeros in the statistics field.

Resource Record Name Compression

To help ensure that Name Service Request and Response messages fit into a single UDP packet, NetBT uses a compression mechanism for NetBIOS Name Service messages in which a given NetBIOS name appears more than once. For example, in Name RegistrationRequest messages, the NetBIOS name being registered is held both in the Question fields (the Question Name field) and in the Additional RR field (which contains both the NetBIOS name and IP address of the end-node that is registering the NetBIOS name).

In these cases, the name registration information contained in the Additional Resource Name field of the NetBIOS Name Service records uses the compressed label pointer technique that DNS uses, as defined in RFC 883.

Name Registration Message

A Name Registration message contains a header, a question record, and an additional RR holding the IP address of the node registering the name.

The fields are set as follows:

• Transaction IDSet to a random number.
• Response FlagSet to 0 (indicating a request).
• Op CodeSet to 0x5 (indicating registration).
• Recursion DesiredSet to 1.
• Broadcast FlagSet if name registration packet is being broadcast.
• Question CountSet to 1.
• Answer ResourceSet to 0.
• Name Service Resource Record CountSet to 0.
• Additional Resource Record CountSet to 1.
• Question Record SectionContains the NetBIOS name being registered.
• Additional Resource RecordThe format is described in the following list.

The additional RR field in a Name Registration Request message contains details regarding this RR, and includes the following fields:

• Resource RecordName in compressed pointer format
• Resource Record TypeSet to 0-20
• Requested TTLBy default, set to 300,000 milliseconds
• RDATA FlagsIndicates the name type (group, unique) and the node type of the node registering the name
• IP AddressBelongs to the end-node registering this name

A Name Registration message can be seen in the Network Monitor trace in Capture 18-01 (included in the Captures folder on the companion CD-ROM).

Positive Name Registration Response

A positive Name Registration Response contains a header and an answer record. In a positive Name Registration Response message returned by a Windows Server 2003 WINS server, the header fields are set as follows:

• Transaction IDSet to the Transaction ID in the Name Registration Request message
• Response FlagSet to 1 to indicate a response
• Op CodeSet to 0x5 (registration)
• Authoritative Answer FlagSet to 1
• Recursion DesiredSet to 1
• Recursion AvailableSet to 1
• Broadcast FlagSet to 0
• Question CountSet to 0
• Return CodeSet to 0 to indicate the name was successfully registered
• Question CountSet to 0
• Answer Resource Record CountSet to 1
• Name Service Resource Record CountSet to 0
• Additional Resource Record CountSet to 0
• Answer Resource RecordThe answer RR confirms the details of the NetBIOS name that were registered with the WINS server, and contains the following fields:
  • Resource Record NameSuch as the registered NetBIOS name (in codedformat)
  • Resource Record TypeSet to 0-20
  • Actual TTL For The Record RegisteredSet based on the TTL configured at the WINS server
  • IP AddressSet to the IP address that belongs to the end-node that registered this name

A positive Name Registration Response message can be seen in the Network Monitor trace in Capture 18-01 (included in the Captures folder on the companion CD-ROM).

Negative Name Registration Response

A negative Name Registration Response is returned when the WINS server is unable to register the requested NetBIOS name. This usually occurs when an end-node attempts to register a unique NetBIOS name that is owned by another end-node.

The negative Name Registration record is formatted as follows:

• Transaction IDSet to the Transaction ID in the Name Registration Request message
• ResponseSet to 1 to indicate a response
• Op CodeSet to 0x5
• Authoritative Answer FlagSet to 1
• Recursion DesiredSet to 1
• Recursion AvailableSet to 1
• Result CodeIndicates why the NetBIOS name could not be registered
• Broadcast FlagSet to 0
• Question CountSet to 0
• Answer Resource Record CountSet to 1
• Name Service Resource Record CountSet to 0
• Additional Resource Record CountSet to 0
• Answer Resource RecordConfirms the details of the name that failed to be registered

RFC 1001 defines the following values for the return code field, as Table 18-5 displays.

Table 18-5: Values for the Return Code Field

Return Code Value	Reason for the Error
1	Format error: The request was improperly formatted.
0x2	Server failure: There is a problem with the name server, such that it cannot process the Name Registration Request.
0x4	Unsupported: The request is not supported by the NetBIOS name server (not used by WINS).
0x5	Registration Request refused: For policy reasons, the NetBIOS name service cannot register this name from this host (not used by WINS in Windows Server 2003).
0x6	Name active: Another node owns the name.
0x7	Name conflict: More than one end-node owns a unique NetBIOS name.

The most common return code is 0x6, name active. This occurs whenever the name that the end-node is requesting WINS to register has already been registered by another end-node. This can be seen in the Network Monitor trace in Capture 18-03 (included in the Captures folder on the companion CD-ROM).

Name Refresh Message

As noted earlier, the end-node owning a NetBIOS name attempts to refresh the name (essentially re-leasing the NetBIOS name) at half the TTL by issuing a Name Refresh message to the WINS server. The Name Refresh message is similar to a Name Registration Request message and is formatted as follows:

• Transaction IDSet to a random number.
• ResponseSet to 0x0 to indicate a request.
• Op CodeSet to 0x4, indicating a name refresh. RFC 1002 defines the name refresh op code as 0x09, but Windows Server 2003 clients set this to 0x04.
• Authoritative Answer FlagSet to 0.
• Recursion DesiredSet to 1.
• Recursion AvailableSet to 0.
• Result CodeSet to 0.
• Broadcast FlagSet to 0.
• Question Record CountSet to 1.
• Answer Resource Record CountSet to 0.
• Name Service Resource Record CountSet to 0.
• Additional Resource Record CountSet to 1.
• Question RecordContains the NetBIOS name being refreshed. The format is the same as for the question record in a Name Registration Request.
• Additional Resource RecordConfirms the details of the name to berefreshed. The format is the same as for the additional RR in a NameRegistration Request.

WINS usually responds to a Name Refresh message with a positive Name Registration Response record, as seen in the Network Monitor trace in Capture 18-05 (included in the Captures folder on the companion CD-ROM).

Name Release Request Message

A Name Release Request message is sent when an end-node releases a NetBIOS name. This usually happens when a Windows Server 2003 service that used NetBIOS names is stopped or is being shut down. A Name Release Request message is formatted as follows:

• Transaction IDSet to a random number.
• ResponseSet to 0 to indicate a request.
• Op CodeSet to 0x6, meaning name release.
• Authoritative Answer FlagSet to 0.
• Recursion DesiredSet to 0.
• Recursion AvailableSet to 0.
• Broadcast FlagSet to 0.
• Result CodeSet to 0.
• Question Record CountSet to 1.
• Answer Resource Record CountSet to 0.
• Name Service Resource Record CountSet to 0.
• Additional Resource Record CountSet to 1.
• Question RecordContains the NetBIOS name being released. The format is the same as for the question record in a Name Registration Request.
• Additional Resource RecordConfirms the details of the name that is to be released. The format is the same (such as the DNS pointer format) as for the additional RR in a Name Registration Request.

The Network Monitor trace in Capture 18-06 (included in the Captures folder on the companion CD-ROM) illustrates the Name Release Request message. When an end-node sends a Name Release Request message to a WINS server, the WINS server usuallyresponds with a positive Name Release Response message, although an error can occur at the WINS server and result in the WINS server sending a negative Name ReleaseResponse message. The end-node sending the original name release message does not take any action on a negative Name Release Response message.

Name Release Response Message

A WINS server sends a Name Release Response message in response to a Name Release Request message. A positive Name Release Response is indicated by the result code 0. A negative Name Release Response has the same format as a positive Name Release Response, except that the result code contains details of the error.

A Name Release Response message is formatted as follows:

• Transaction IDSet to the same transaction ID contained in the NameRelease Request message.
• ResponseSet to 1 to indicate a response.
• Op CodeSet to 0x6, meaning name release.
• Authoritative Answer FlagSet to 0.
• Recursion DesiredSet to 0.
• Recursion AvailableSet to 0.
• Broadcast FlagSet to 0.
• Result CodeSet to 0 (success) or to indicate reason for the failure.
• Question Record CountSet to 0.
• Answer Resource Record CountSet to 1.
• Name Service Resource Record CountSet to 0.
• Additional Resource Record CountSet to 0.
• Answer Resource RecordContains the NetBIOS name that has been released. The format is the same as for the question record in a Name Registration Request.

If the WINS server successfully releases the NetBIOS name, the return code is 0.Table 18-6 indicates what the return codes are if the WINS server cannot release the name.

Table 18-6: Explanation of Return Code Value and Error

Return Code Value	Reason for the Error
1	Format error: The request was improperly formatted.
0x2	Server failure: There is a problem with the name server, such that it cannot process the Name Release Request.
0x5	Registration Request refused: For policy reasons, the NetBIOS name server could not release this name from this host (not used by WINS in Windows Server 2003).
0x6	Name active: Another node owns the name; only the node owning the name can release it.

A Name Release Response message can be seen in the Network Monitor trace inCapture 18-06 (included in the Captures folder on the companion CD-ROM).

Name Query Request Message

A computer that wants to resolve a NetBIOS name sends a Name Query Request message. This message, which can be sent using broadcast or direct to a WINS server, is formatted as follows:

• Transaction IDSet to a random 16-bit value
• ResponseSet to 0 to indicate a request
• Op CodeSet to 0, meaning Name Query
• Authoritative Answer FlagSet to 0
• Recursion DesiredSet to 1
• Recursion AvailableSet to 0
• Broadcast FlagSet to 1 if broadcast, and 0 if sent to a WINS server
• Result CodeSet to 0
• Question Record CountSet to 1
• Answer Resource Record CountSet to 0
• Name-Service Resource Record CountSet to 0
• Additional Resource Record CountSet to 0
• Question RecordContains the NetBIOS name that the sender wishes to resolve

The Network Monitor trace in Capture 18-09 (included in the Captures folder on the companion CD-ROM) illustrates a Name Query Request, and shows a query being sent to a WINS server.

Positive Name Query Response Message

If the node that has received a Name Query can resolve the name, it formats and sends a positive Name Query Response to the node that issued the original Name Query message. The positive Name Query message contains the IP address of the system owning the NetBIOS node and is formatted as follows:

• Transaction IDSet to the transaction ID specified in the Name Query Request message
• ResponseSet to 1 to indicate a response
• Op CodeSet to 0, meaning Name Query
• Authoritative Answer FlagSet to 1
• Recursion DesiredSet to 1
• Recursion AvailableSet to 1
• Broadcast FlagSet to 1 if broadcast, and to 0 if sent from a WINS server
• Result CodeSet to 0
• Question Record CountSet to 0
• Answer Resource Record CountSet to 1
• Name Service Resource Record CountSet to 0
• Additional Resource Record CountSet to 0
• Answer Resource RecordContains details of the name including the name type (unique, group) and the name TTL; also contains details of the node that owns the name (the IP address and the node type)

A positive Name Query Response message can be seen in the Network Monitor trace in Capture 18-09 (included in the Captures folder on the companion CD-ROM).

Negative Name Response Message

When a WINS server gets a Name Query Response that it cannot resolve, it sends a negative Name Response message to the node that sent the original Name Query message. The negative Name Response message is formatted as follows:

• Transaction IDSet to the transaction ID specified in the Name Query message
• ResponseSet to 1 to indicate a response
• Op CodeSet to 0, meaning Name Query
• Authoritative Answer FlagSet to 1
• Recursion DesiredSet to 1
• Recursion AvailableSet to 1
• Broadcast FlagSet to 1 if broadcast, and to 0 if sent from a WINS server
• Result CodeSet to 0
• Question Record CountSet to 0
• Answer Resource Record CountSet to 1
• Name Service Resource Record CountSet to 0
• Additional Resource Record CountSet to 0
• Answer Resource RecordContains details of the name including the name type (unique, group) and the name TTL; also contains details of the node that owns the name (the IP address and the node type).

A negative Name Query Response message can be seen in the Network Monitor trace in Capture 18-10 (included in the Captures folder on the companion CD-ROM).

Wait Acknowledgment Message

A WINS server sends a WACK message to a client asking it to wait for the completion of a name service operation. The format of a WACK message is as follows:

• Transaction IDSet to the transaction ID specified in the name message previously sent to the WINS server
• ResponseSet to 1 to indicate a response
• Op CodeSet to 0x7, meaning WACK message
• Authoritative Answer FlagSet to 1
• Recursion DesiredSet to 0
• Recursion AvailableSet to 0
• Broadcast FlagSet to 0
• Result CodeSet to 0
• Question Record CountSet to 0
• Answer Resource Record CountSet to 1
• Name Service Resource Record CountSet to 0
• Additional Resource Record CountSet to 0
• Answer Resource RecordContains details of the name service operation that the WINS server is asking the receiver of this message to wait for

The Network Monitor trace in Capture 18-04 (included in the Captures folder on the companion CD-ROM) illustrates a WACK message.

Summary

WINS provides NetBIOS name resolution for networks of any size, although it is most likely to be used in networks that span multiple subnets. Windows Server 2003, Windows XP, and Windows 2000 make heavier use of DNS than Windows NT 4.0, but the need for WINS continues until all down-level clients and applications that rely on NetBIOS are replaced.