How WINS Technology Works

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

In this section

• NetBIOS Overview

• WINS Architecture

• WINS Protocol

• WINS Processes and Interactions

• Related Information

Windows Internet Name Service (WINS) is a name resolution service that maps NetBIOS names to IP addresses in networks that use NetBIOS over TCP/IP (NetBT). As such, the primary purpose of WINS is to support clients that run older versions of Windows and applications that use NetBIOS.

In earlier versions of Microsoft operating systems, NetBIOS names were required for locating network resources. In Microsoft Windows NT 4.0, for example, clients used NetBIOS to locate Windows NT 4.0 domain controllers, as well as for file and print sharing. Therefore, WINS is required for name resolution in network environments that include computers running Windows versions earlier than Windows 2000.

WINS is not required in a network that consists entirely of computers running Windows 2000, Windows XP, Windows Server 2003, or other TCP/IP-based systems, such as most versions of UNIX, that fully support the use of Domain Name System (DNS) names. If NetBIOS and, consequently, WINS are eliminated from such an environment, however, any applications and services that depend on NetBIOS, such as the Computer Browser service, will not function. Organizations that need to continue to support older versions of Windows still rely on NetBIOS and WINS.

WINS can be used in conjunction with DNS, which resolves domain names, to connect to any network resource by referencing the resource’s user-friendly name. Used in conjunction with Dynamic Host Configuration Protocol (DHCP), WINS supports dynamic IP address assignments, thus eliminating the administrative burden of maintaining static IP addresses.

This section describes how WINS works in a properly configured environment, which includes the following:

• NetBT is enabled.

• DNS is configured correctly.

• DHCP is configured correctly.

• The network, including routers, is configured to handle name resolution traffic.

• WINS-configured servers are designed with sufficient CPU, memory, and hard disk space to handle WINS activity.

The following sections describe WINS components, how they fit in a network environment, and how NetBIOS name resolution processes work.

NetBIOS Overview

An understanding of NetBIOS is essential to understanding WINS. In the OSI reference model, NetBIOS is a session-layer protocol. Applications use this protocol to communicate over NetBIOS-compatible transports. NetBIOS and applications that use NetBIOS can run over both TCP/IP and Internetwork Packet Exchange (IPX). When it runs over TCP/IP, NetBIOS is commonly referred to as NetBT.

RFCs 1001 and 1002 define the functions and features of three NetBIOS services in a TCP/IP environment: name service, session service, and datagram service. The name service encompasses registering NetBIOS names, renewing and releasing names, and resolving NetBIOS names to IP addresses. WINS is the Microsoft implementation of a NetBIOS name server (NBNS), as defined by the RFCs. The other two services are beyond the scope of this section.

NetBIOS Names

RFCs 1001 and 1002 provide for 16-byte NetBIOS names. The first 15 characters of a NetBIOS name are user-definable. Windows reserves the sixteenth character for a name suffix.

The user-definable portion of a NetBIOS name cannot begin with an asterisk (*). Use of extended characters, the underscore (_) and period (.) in particular, can result in name resolution errors in environments that also use DNS name resolution. NetBIOS names are not case-sensitive.

The name suffix, the final byte of a NetBIOS name reserved by Windows, specifies the resource type. A WINS client can use the suffix to identify the specific service it needs to access. That is, a WINS client can construct the NetBIOS name based on a computer, user, or domain name and append the suffix to locate a specific resource on that computer. For example, the Messenger service has a suffix of 0x03. To send a message to COMPUTER42, the client sends a message to the Messenger service on COMPUTER42 by specifying the following NetBIOS name:

COMPUTER42     [03]

In the full 16-character name notation, the first 15 characters are padded with spaces, if necessary. A NetBIOS name can be a unique name, which means it maps to a single IP address, or a group name, which means it maps to multiple IP addresses. For example, each computer that runs Windows Server 2003 has a Server service for sharing files and a Workstation service for accessing the files shared by the Server service. These services each have a unique NetBIOS name, so client computers can locate the appropriate server and use the file-sharing service. On the other hand, the domain controllers within a single domain share a group name.

The following table describes some of the NetBIOS name suffixes used by Windows Server 2003. The suffixes are listed in hexadecimal format. Other applications, such as Microsoft Exchange and Microsoft Systems Management Server (SMS), register NetBIOS names with different suffixes.

Common Windows NetBIOS Name Suffixes

15-Character Name	Suffix (Hexadecimal)	Type	Usage
ComputerName	00	Unique	Registered by the Workstation service on a WINS client. Typically, this name is called the NetBIOS computer name.
DomainName	00	Group	Registered by the Workstation service for receiving browser broadcasts from LAN Manager-based computers.
MSBROWSE	01	Group	Registered by the master browse server for each subnet.
ComputerName	03	Unique	Registered by the Messenger service on a WINS client. This name is usually appended to the NetBIOS computer name and to the name of the logged-on user. (The Messenger service is not related to Windows Messenger.)
UserName	03	Unique	Identifies the Messenger service for the logged-on user. User names are registered in the WINS database by the Messenger service.
ComputerName	1B	Unique	Registered by each Windows Server 2003 domain controller running as the domain master browse server. This name record is used to allow remote browsing of domains. When a WINS server is queried for this name, a WINS server returns the IP address of the computer that registered this name.
DomainName	1B	Unique	Registered by each Primary Domain Controller (PDC) that is running as the domain master browser. This name is used to support remote browsing of domains. When a WINS server is queried for this name, it returns the IP address of the computer that registered the name.
DomainName	1C	Group	Registered for use by domain controllers within the domain. This NetBIOS name can include up to 25 IP addresses: one for the PDC and 24 for backup domain controllers (BDCs).
DomainName	1D	Unique	Registered only by a master browse server. There is only one master browse server per subnet. Backup browse servers use this name to communicate with the master browse server to retrieve the list of available servers from the master browse server. WINS servers always return a positive registration response for DomainNname[1D], even though they do not add this name to the WINS database. Therefore, when a WINS server is queried for DomainName[1D], the server always responds with a broadcast address, which forces the client to broadcast to resolve the name.
DomainName	1E	Group	Registered for any computers configured to be network browse servers. This is a normal group name. Any computers configured to be network browse servers can broadcast to this name and listen for broadcasts to this name to elect a master browse server. A statically-mapped group name uses this name to register itself on the network. When a WINS server receives a name query for a name ending with [1E], the WINS server always returns the network broadcast address for the local network of the requesting client. The client can then use this address to broadcast to the group members.
ComputerName	1F	Unique	Registered by the Network Dynamic Data Exchange (NetDDE) services; appears only if the NetDDE services are started on the computer.
ComputerName	20	Unique	Registered by the Server service on the WINS client. The WINS client uses this service to share folders and printers on the network.
GroupName	20	Group	A special group (also called Internet group) name is registered with WINS servers to identify groups of computers for administrative purposes. For example, “printers” could be a registered group name used to identify an administrative group of print servers.
ComputerName	BE	Unique	Registered by the Network Monitoring Agent service and appears only if the service is started on the WINS client computer. If the computer name has fewer than 15 characters, plus symbols (+) are added to expand the name to 15 characters.
ComputerName	BF	Unique	Registered by the Network Monitoring Utility (included with Microsoft Systems Management Server). If the computer name has fewer than 15 characters, plus symbols (+) are added to expand the name to 15 characters.

The NetBIOS namespace is flat, which means that names can be used only once within a network. By contrast, DNS uses fully qualified domain names (FQDNs), which combine a host name with the hierarchical name of its domain. For example, a NetBIOS name of WINSserver01 might be an FQDN of WINSserver01.reskit.com.

Being able to use a NetBIOS name only once within a network can be a restriction with imposing implications for large networks. Using a NetBIOS scope, as described in RFC 1001, is one solution to this situation. A character string, known as the scope identifier, works something like a domain name in DNS and defines the population of computers across which a registered NetBIOS name is known. The scope identifier is appended to NetBIOS names during name services processes. However, the meaning of scope varies based on the NetBIOS node. For example, the scope for B-node includes all the NetBIOS nodes in the local subnet, the scope for P-node includes all the NetBIOS nodes in the routed network that use the same NetBIOS name service, and the scope for M-node and H-node is an intersection of the B-node and P-node scopes. (NetBIOS nodes are defined later in this section.) This situation causes name resolution problems in environments that use more than one type of NetBIOS node. Because only NetBIOS nodes that use the same scope ID can resolve each other’s names, the use of different scope IDs can create communication problems. Therefore, use of the scope identifier is discouraged in Windows Server 2003.

NetBIOS Nodes

Client computers use NetBIOS name services to register, renew, and release names and to query and resolve IP addresses for network resources. NetBIOS session and datagram services use these name services to locate resources. For example, if a user wants to map a network drive to a file share on a remote computer by using Windows Explorer, the user types the remote computer name and share name in the Map Network Drive window. Windows Explorer uses NetBIOS name services to obtain the remote computer's IP address and then establishes a NetBIOS session over which a file-sharing session is established to access the shared resource.

NetBIOS name services are carried out either by using IP broadcasts or by using a NetBIOS name server. Broadcasts are appropriate in single-subnet local area networks (LANs), but rapidly cause administrative problems in multiple-subnet networks. A NetBIOS name server is the desirable alternative for larger networks. To allow for various sizes of networks, RFCs 1001 and 1002 use the concept of node type to determine the specific method a computer uses to perform name services. The following table describes the four NetBIOS node types.

NetBIOS Node Types

Name Resolution Node	Description
B-node	Broadcast node. The client computer sends IP broadcast messages to all the computers on the subnet. The computer that has the requested name sends back a confirmation with its IP address. This is the default mode for non-WINS clients.
P-node	Point-to-point node. The client computer only communicates with a NetBIOS name server (in Windows Server 2003-based networks, this is the WINS server) to register names and resolve names to IP addresses.
M-node	Mixed node. The client computer uses a mix of B-node and P-node communications to register and resolve NetBIOS names: it first attempts to resolve a name by using broadcasts, and if that is unsuccessful it queries a WINS server.
H-node	Hybrid node. The client computer uses a hybrid of B-node and P-node: it first queries a WINS server, and if that is unsuccessful it sends broadcasts.

The default node type for Windows-based WINS clients is B-node. When a computer is configured to use a WINS server, whether manually or through DHCP, it becomes H-node. The other NetBIOS node types are configured through DHCP by configuring the WINS/NBT Node Type option for a DHCP client.

Because B-node is based on broadcasts, it does not scale beyond a single subnet. Configuring routers to forward NetBIOS broadcasts also does not scale well and is not recommended. To address these limitations of RFC-compliant B-node, Microsoft extended B-node for name service operations. Microsoft’s extension, known as modified B-node, adds the following two name lookup facilities:

NetBIOS name cache

An in-memory cache of recently resolved NetBIOS names that can be searched before attempting other name resolution methods.

LMHosts file

A flat file, located in systemroot\System32\Drivers\Etc, that contains a static list of NetBIOS names and their IP addresses. This file does not exist by default.

WINS Architecture

The WINS service is Microsoft’s implementation of a NetBIOS name server. WINS consists of two primary components: WINS servers and WINS clients. Each WINS server includes a dynamic database of NetBIOS name-to-IP address mappings. WINS clients communicate with a WINS server to register their NetBIOS names in the WINS database and to query the WINS database to resolve the IP addresses associated with other NetBIOS names. A special kind of WINS client is the WINS proxy. WINS proxies support NetBIOS name services in a limited way for client computers that are not WINS-enabled. The following figure illustrates how WINS components fit in a network environment.

WINS Component Configuration

This example shows two subnets (Subnet 1 and Subnet 2) that include WINS clients. The third subnet (Subnet 3) includes B-node clients and a WINS proxy to act on the behalf of the B-node clients during name service requests. There are two WINS servers, each of which contains a WINS database. The WINS components illustrated in the figure are described in the following table.

WINS Components

Component	Description
WINS server	A computer that provides the WINS name registration and resolution service. A WINS server replicates the WINS database to other WINS servers so that complete name-to-address resolution information is available, regardless of which WINS server a WINS client uses.
WINS client	Any WINS-enabled computer that communicates with a WINS server to register, refresh, or release its NetBIOS name or to resolve the NetBIOS name of another computer.
WINS proxy	A WINS client computer that is configured to act on the behalf of other, non-WINS-enabled computers, allowing these computers limited participation in name registration, release, and resolution processes.
WINS database	A dynamically updated list of NetBIOS names and their associated IP addresses, including IP addresses assigned by DHCP. In networks that have multiple WINS servers, the servers exchange database updates through replication.

WINS Servers

A WINS server handles name registration requests from WINS clients by registering their names and IP addresses, provided the requested unique name is not in active use. It also responds to NetBIOS name queries submitted by clients by returning the IP address of a queried name if it is listed in the WINS database. Either local clients (on the same subnet as the WINS server) or remote clients (across a router from the server) can register with a WINS server.

When a WINS-enabled client starts on the network, it sends its name and IP address in a registration request directly to its configured primary WINS server. The WINS server that registers the NetBIOS name of the client in its database is said to be the owner of the WINS name entry.

WINS servers can replicate the contents of their databases to other WINS servers.

Primary and Secondary WINS Servers

WINS servers can act as either a primary WINS server or a secondary WINS server to a client. The difference between primary and secondary WINS servers is simply the priority in which clients contact them. A primary WINS server is the first server a client contacts to perform its NetBIOS name service operations. A client contacts a secondary WINS server only when a primary WINS server is unable to fulfill the request, for example if it is unavailable when the client makes the request or unable to resolve a name for the client.

If a primary WINS server fails to fulfill a request, the client makes the same request of its secondary WINS server. If more than two WINS servers are configured for the client, the client tries the additional secondary WINS servers until the list is exhausted or one of the WINS servers successfully responds to the request. After a client uses a secondary WINS server, it periodically tries to switch back to its primary WINS server for future name service requests.

WINS Clients

WINS clients are computers that are configured to make direct use of a WINS server. WINS clients attempt to register their names with a WINS server when they start or join the network. Thereafter, they query the WINS server to resolve NetBIOS names as needed. WINS clients communicate with WINS servers to:

• Register client names in the WINS database.

• Refresh client names in the WINS database.

• Release client names from the WINS database.

• Resolve names by obtaining name-to-IP address mappings from the WINS database.

Most WINS clients typically have more than one NetBIOS name that they must register for use with the network. These names are used to publish various types of network services, such as the Messenger or Workstation services, that each computer can use to communicate with other computers on the network.

WINS client computers are configured with either static or dynamic IP addresses. Clients that use static IP addresses are manually configured with a set of specific WINS servers. Clients that use dynamic IP addresses use the WINS/NBNS Servers option in DHCP to specify the WINS servers.

For Windows 2000, Windows XP, and Windows Server 2003, WINS clients can be configured with up to 12 secondary WINS servers. This feature is useful in an environment in which there are many mobile clients, many NetBIOS-based resources, and services are used often. In such an environment, updates to the WINS database might not be replicated throughout the network of WINS servers at the time of a request, and it can be helpful for clients to be able to query more than two WINS servers. Clients use the additional server addresses only if the primary and secondary servers fail to respond.

WINS clients running any of the following versions of Windows can communicate with a WINS server running Windows Server 2003:

• 32-bit versions of the Windows Server 2003 family

• 64-bit versions of Windows Server 2003, Datacenter Edition and Windows Server 2003, Enterprise Edition

• 32-bit versions of Windows XP Professional and Windows XP Home Edition

• 64-bit version of Windows XP Professional

• Windows Millennium Edition

• Windows 2000 Professional; Windows 2000 Server; Windows 2000 Advanced Server; and Windows 2000 Datacenter Server

• Windows NT Workstation 4.0 and Windows NT Server 4.0

• Windows 98

• Linux and UNIX clients (with Samba installed)

Clients that are not WINS-enabled can participate in name registration and resolution processes in a limited way by using WINS proxies.

WINS Proxies

A WINS proxy is a WINS client that can perform limited NetBIOS name services, such as registration, release, and resolution, on behalf of other non-WINS clients that are on a routed TCP/IP network.

Typically, older NetBIOS clients that are not, or cannot be, configured to use WINS are B-node clients. These computers use broadcasts to register their NetBIOS names on the network and to resolve NetBIOS name queries. Computers configured for B-node cannot use WINS directly because WINS servers do not respond to broadcasts. A WINS proxy can listen on the local subnet for B-node name query broadcasts and respond for the names that are not on the local subnet. WINS proxies communicate with a WINS server by using unicast datagrams.

RCF 1001 recommends against using B-node name resolution in a routed network, but in practice, the B-node NetBIOS node type is sometimes useful and sometimes cannot be removed or updated. Microsoft designed WINS proxies to support B-node clients in a routed network.

WINS Database

The WINS database resides on the WINS server. It stores NetBIOS name-to-IP address mappings for the network. WINS clients use this mapping information to connect with other network resources. NetBIOS names are registered in the WINS database whenever a network resource becomes available for use, for example when a computer starts up. Therefore, the contents of the WINS database change over time as computers join and leave the network.

The size of the WINS database depends on the number of WINS clients in the network and the number of NetBIOS names each uses. Unique name entries typically are 42 bytes. Internet group entries can include up to 25 addresses and, therefore, are longer entries. The databases on all WINS servers in a network are about equal in size. All the databases have the same number of NetBIOS name entries, except for those pending replication.

The actual size of the database, however, can be much larger than the number of entries, because space is not automatically reclaimed when unused records are deleted. WINS database compaction recovers the unused space. Windows Server 2003 provides both dynamic and manual database compaction. The manual database compaction is most efficient, but requires the database to be offline. The dynamic database compaction runs during idle time after a database update and allows the database to remain online.

The use of multiple WINS servers in a NetBIOS environment provides redundancy and load balancing. When multiple WINS servers are used, updates to a WINS database replicate among the WINS servers designated as replication partners until the updates are in all the WINS databases in the network. Although each name entry is eventually replicated to all other WINS databases, a name entry is said to be owned by the WINS server that originated the entry.

WINS servers running Windows Server 2003 can replicate with WINS servers running earlier versions of Windows.

WINS Database Files

The Windows Server 2003 WINS database uses the Extensible Storage Engine (ESE). This database imposes no limit on the number of records that a WINS server can store or replicate.

WINS uses the Jet database format for storing its data. Jet produces the Jn.log and other files by default in the systemroot\System32\Wins folder. The files that are created and used by the database on each WINS server are described in the following table.

WINS Server Database Files

File	Description
J50.log and J50xxxxx.log	A log of all WINS database transactions. This file is used by WINS to recover data if necessary. Log files maintain a specific size of 1024 KB. When WINS tries to write more transactions to the log than the file size can accommodate, it renames the current log file and creates a new one. The new log file has a file name in the format Jn.log, where n is a decimal number, such as J50.log. The format of the renamed log file is Jetxxxxx.log, where each x denotes a hexadecimal number from 0 to F. Renamed log files are maintained in the same folder as the current log file. All entries in the log file are written to the database and the log is deleted every three hours, when the WINS database is successfully backed up, and when the WINS Server service is shut down properly.
J50.chk	A checkpoint file that indicates the location of the last information successfully written from the transaction logs to the database. During data recovery, the checkpoint file indicates where recovery begins. The checkpoint file is updated every time data is written to the database file (Wins.mdb).
Wins.mdb	The WINS database, which contains two tables: the IP address-to-owner ID mapping table and the name-to-IP address mapping table. The name-to-IP address mapping table stores NetBIOS names and the IP addresses assigned to them. These entries are created during name registration requests and during replication. This table includes a clustered index (logical order of the key values is the same as the physical order of the rows in the table) on the name field for quick record retrieval during name queries. The primary index is built by concatenating owner ID and version ID in ascending order for quick retrieval of records that fall within a range of version IDs. The IP address-to-owner ID mapping table contains a row for each WINS server that has entries in the name-to-IP address mapping table. A row contains the IP address of the WINS server and its identifier, which is the owner ID field for the name entries it owns. This table is used to build the owner-to-version table that determines which replication partners have the latest updates.
Winstmp.mdb	A temporary file that is created by the WINS service. This file functions as a swap file during index maintenance operations and can remain in the systemroot\System32\Wins folder after a system failure.
Res#.log	These are reserved log files, which function in emergencies when the server runs out of disk space. If a server attempts to create another transaction log file and there is insufficient disk space, the server flushes any outstanding transactions into these reserved log files. The service then shuts down and logs an event to Event Viewer.

To increase speed and efficiency of data storage, current transactions are written to log files rather than directly to the database. Therefore, the most current view of the data includes both the database and any transactions in the log files. Both the database and the log files are used for recovery if the WINS service abruptly or unexpectedly stops. If the service stops in an unexpected manner, the log files are automatically used to re-create the correct state of the WINS database.

Name Data

Name entries in the name-to-IP address mapping table include data used during name query requests, as well as data used to age and replicate the entries. Data used for name service requests or for aging and replicating entries is described in the following table.

Name Data

Data	Description
Name	The NetBIOS name.
Address	The IP address associated with the name. A unique name has a single IP address. A special group entry can have multiple IP addresses.
Name type	The type of name. A name is classified by how it is added to the WINS database: Static (the name is manually added to the WINS database) Dynamic (the name is automatically added to the WINS database during NetBIOS name registration) A name is also classified as one of the following: Unique name Normal group Special group, also known as an Internet group Multihomed (a computer that uses multiple IP addresses)
State	The status of the NetBIOS name entry, which can be one of the following: Active (name is in active use) Released (network node has shut down, name is not in use) Extinct, also known as tombstone (name was not reregistered, is ready for deletion)
Owner ID	The ID of the WINS server that owns the entry. The owner is the WINS server that first added the entry to the WINS database. WINS automatically assigns and increments an integer value to represent owner IDs at the local server. These owner IDs are mapped to the WINS server IP addresses. Owner IDs are used internally at the local server, and their values differ from WINS server to WINS server.
Version ID	A counter that indicates which name entry updates need to be replicated.
Time stamp	A date and time stamp that is updated when a NetBIOS name entry is updated. WINS uses specific time intervals to determine when to renew or delete name entries from the database. WINS calculates the time stamp from the current date and time plus a time interval.

WINS Time Intervals

Name entries in the WINS database have time stamps that determine when specific aging activities are to take place. WINS uses four configurable time intervals to calculate the time stamps. The following table describes the four time intervals.

WINS Time Intervals

Time Interval	Description
Renew interval (also known as the Time-to-Live [TTL])	Specifies when a client must refresh its name. The default is six days. During a name registration request, the entry is time-stamped with the sum of the current time and this interval value. If a name entry is not refreshed before this time stamp expires, WINS releases the name entry.
Extinction interval (also known as tombstone interval)	Specifies the interval between when an entry is marked as released and when it is marked as extinct. The default depends on the renew interval and, if the WINS server has replication partners, on the maximum replication time interval, which is the configurable amount of time between pull replications. The maximum allowable value is six days. When an entry is marked as extinct, the entry is time-stamped with the sum of the current time and the extinction time-out on the WINS server that is configured as the pulling replication partner (the partner that requests replication).
Extinction time-out (also known as tombstone time-out)	Specifies the interval between when an entry is marked extinct and when the entry is finally deleted (scavenged) from the database. The default depends on the renew interval and, if the WINS server has replication partners, on the maximum replication time interval. The default is six days.
Verification interval	Specifies the interval after which a WINS server must verify that old names it does not own are still active. The default value is 24 days. When an active entry is replicated, it is time-stamped with the sum of the current time and the verification interval on the WINS server requesting replication (pull partner).

The Windows Server 2003 defaults provided for these values take the following into consideration:

• Minimized level of network traffic

• Minimized load on WINS servers

• Various configurations in which WINS servers might be deployed

• Minimized window between replications

• Exceptional conditions, such as long weekends and large volumes in worst-case scenarios

Server Clocks

Replication and scavenging (database cleanup) algorithms rely on a reasonably consistent system clock. Setting the system clock forward or backward affects these algorithms. However, because time stamps are always entered locally, the WINS servers do not need to be time-synchronized.

WINS Protocol

The WINS protocol is based on, and is compatible with, the protocols defined for NetBIOS name services specified in RFCs 1001 and 1002. Therefore, WINS is compatible with any other implementation of these RFCs. That is, another RFC-compliant implementation of the client can communicate with a WINS server. Similarly, a Microsoft TCP/IP client can communicate with other implementations of an NBNS. To provide scalability for larger networks, however, the WINS implementation of NBNS supports replication of the WINS database between WINS servers. WINS replication is Microsoft proprietary technology, so WINS replication is not compatible with other NBNS implementations. This section briefly describes the format of NetBIOS packets and the ports used by NetBIOS.

NetBIOS name services packets

NetBIOS name service packets consist of messages sent between a WINS client and a WINS server. These message packets are similar in structure to DNS packets, but with additional types and codes for NetBIOS. The high-level format of name services packets is described in the following table.

Name Services Packet Format

Message Section	Description
Name service header	Fixed length, 12 octets. This section contains information about the type of message and counts for the other records included in the message.
Question entries or Answer resource records	Variable length, optional. Length is defined in the header. This section contains the NetBIOS name for name registration, refresh, and release messages. Variable length, optional. Length is defined in the header. This section contains the resource records returned in response to a request.
Authority resource records	This section is not used in Windows Server 2003.
Additional resource records	Variable length, optional. Length is defined in the header. This section contains other resource records that are not provided as a direct reply to a request.

Each name service packet contains a header and one or more additional entries. The sections included for a packet depend on the message. The format of name service packets used by Windows Server 2003 is compatible with the specification provided in RFC 1002. For a detailed description of packet fields, see RFC 1002.

WINS ports

The ports listed in the following table are used by specific WINS services.

WINS Port Assignments

Service Name	UDP	TCP
NetBIOS name service	137 (client and server)
WINS replication		42
WINS replication partner automatic discovery	42

The WINS client and WINS Server services listen on User Datagram Protocol (UDP) port 137. UDP is an unreliable transport protocol in that it does not establish a session or connection between the sender and the receiver. Because of this, it is possible for more requests than responses to be sent. That is, a client might need to send a request multiple times before it receives a response. However, a client never receives more than one response to a request.

WINS Processes and Interactions

WINS clients communicate with WINS servers for NetBIOS name services. WINS servers communicate with other WINS servers for WINS database replication. WINS servers also periodically run a process to identify and clean up extinct names in the WINS database.

NetBIOS name services include four types of processes between a WINS client and a WINS server. The following table briefly describes these processes, which are discussed in more detail in the following sections.

NetBIOS Name Service Processes

Name Service Process	Description
Name registration	Name registration is a WINS client requesting the use of a NetBIOS name on the network. WINS validates that the NetBIOS name is not in active use and then adds it to the WINS database. When a NetBIOS name is registered in the WINS database, other computers can resolve that name and use the resulting IP address to communicate with the network resource. Names typically are registered when a NetBIOS application starts, such as when a computer or service starts up, or when a user logs on to the network.
Name renewal	Each NetBIOS name registered in the WINS database has a specified TTL. Before this time expires, the name is refreshed.
Name release	When a NetBIOS application shuts down, such as when a computer or service is stopped or a user logs off the network, the name is released by the WINS client and is marked as released in the WINS database.
Name resolution	When an application needs to communicate with a NetBIOS application on another NetBIOS node, the NetBIOS name for the other node is resolved to its IP address.

Clients that are not configured to use WINS can also participate in these processes to a limited extent by using a WINS proxy. The remainder of this section describes what happens during typical and WINS proxy name service processes, the scavenge process, and the replication process.

Name Registration

Before a NetBIOS name can be resolved in a WINS environment, it must be registered with a WINS server. For example, when a WINS client starts up, it sends a name registration request to the WINS server for each NetBIOS name it uses. A name registration request can be for a unique name (maps to a single IP address) or for a group name (maps to multiple IP addresses).

As illustrated in the following figure, a WINS client (ClientC) sends a name registration request directly to its configured WINS server, WINSA.

Name Registration

In this example, ClientC sends a name registration request to its configured primary WINS server, WINSA. WINSA adds an entry for ClientC, with its IP address, in the WINS database and sends a positive reply back to ClientC.

Registering a unique NetBIOS name by using a WINS server works as follows:

1. When a network resource starts up, the WINS client sends a name registration request, which includes the NetBIOS name and IP address, to its configured WINS server.

2. The WINS server checks to see if the name has already been registered, and if so, whether it is in active use. The WINS server sends a Wait for Acknowledgment (WACK) message to the WINS client while it attempts to determine whether the name can be registered.

3. If the name is not in use, the server adds the NetBIOS name and IP address to the WINS database and sends the client a positive name registration reply, which includes a TTL value that determines when the name will expire.

4. If the name is in active use, the WINS server does not add the name and address to the WINS database and sends the WINS client a negative name registration reply.

The precise process for registering NetBIOS names depends on the client's node type. B-node clients use broadcasts instead of WINS servers to register names. M-node and H-node clients combine the use of broadcasts and WINS P-node clients use only WINS.

Because WINS servers do not respond to broadcasts, the actions described in this section do not apply to broadcast registration. The following table describes the results of WINS server replies.

WINS Server Replies

Server Reply	Result
No reply	If the WINS client has one or more secondary servers configured, it tries each server. If the WINS client does not receive an immediate response from a WINS server, it can try the server up to three times. If the WINS client does not receive a reply from any of its configured WINS servers, name registration fails and the application can display an error to the user.
Positive reply	The name can be resolved by other computers for communication and no other network resource can use the same name (if the name is unique).
Negative reply	The name registration fails. Windows Server 2003 processes, such as the Server service, write an error event to the system event log.

Name Conflicts

During a NetBIOS name registration request, a WINS server verifies that the requested name is not a duplicate of a NetBIOS name already in use in the network. The WINS server first determines whether the name exists in the WINS database. If the name is already registered, the WINS server determines whether the name is in active use or whether it is available. A variety of factors determine whether the name is available.

In some cases, a WINS server can determine from the database entry whether a NetBIOS name is active. If the WINS server cannot determine in this way whether the name is active, it might need to challenge the name. To challenge a name, the WINS server sends a name query request to the WINS client that registered the name. If the name is active, the WINS client that registered the name sends a name query response and is said to defend the name.

The following factors influence the action taken by a WINS server when resolving a name conflict:

• Whether the name is a unique name or a group name.

• The state of the registered name. A registered name can be active, released, or extinct.

• Whether the name is owned by the WINS server handling the registration request or another WINS server.

• Whether the IP address is the same or different from the IP address specified in the name registration request.

• Whether the name is statically or dynamically added to the WINS database.

Names with different IP addresses

If a WINS client sends a name registration request for a unique name that already exists in the WINS database, but with a different IP address, the WINS server first checks the status of the existing name. If the name is in a released or extinct state, the WINS server treats the request as a new registration and sends a positive name registration reply to the WINS client requesting the name.

If the database status of the existing name is active, the WINS server determines whether the unique name is still in use by sending a challenge to the WINS client that registered the name, as illustrated in the following figure.

Name Challenge

In this example, the following steps take place:

1. A WINS client (ClientA at IP address 192.168.0.17) sends a name registration request to its configured primary WINS server (WINSA).

2. WINSA finds the unique name “ClientA” with a different IP address in the WINS database. WINSA sends a Wait for Acknowledgement (WACK) message to the requesting WINS client. The WACK message includes the estimated time of the wait in the TTL field.

   WINSA then sends a name query request to the WINS client at IP address 192.168.0.20. WINSA waits 500 milliseconds between challenges, and if ClientA is multihomed, WINSA tries each IP address. If WINSA receives no response from the first challenge, it makes two additional attempts.

3. The name ClientA is still in active use, so the WINS client sends a name query response back to WINSA.

4. WINSA then sends a negative name registration response back to the requesting WINS client. If the registered name “ClientA” was no longer in active use, no name query response would be sent, and WINSA could send a positive name registration response to the requesting WINS client.

Names with the same IP address

If a WINS client sends a name registration request for a unique name with the same IP address as one that already exists in the WINS database, the action a WINS server takes depends on the status and ownership of the existing name, as follows:

• If the registered name has a status of active and is owned by the WINS server handling the new registration request, the WINS server sends a positive name registration reply to the WINS client making the request.

• If the registered name has a released or extinct status, or if it is owned by a different WINS server, the WINS server treats it as a new registration: it sends a positive name registration reply to the WINS client making the request and takes ownership of the name.

Group names

Group names are handled differently than unique names. A group name can be a normal group name or a special (also known as Internet) group name. Normal group names can have many associated IP addresses, but the member addresses are not stored in the WINS database. WINS responds to a name query for a normal group name with the limited broadcast address 255.255.255.255. Routers do not forward packets addressed to the limited broadcast address, so special groups were developed to support communications between subnets.

Special groups are used for special, user-defined administrative groups. For example, a special group can be used to group resources such as file servers or printers. Special groups are associated with multiple IP addresses.

A WINS server handles name conflicts for a group name as follows:

• If a WINS client sends a unique name registration request that conflicts with a registered normal group name, a WINS server always sends a negative name registration reply.

• If a WINS client sends a name registration request for a special group name, a WINS server always sends a positive name registration reply, adding the requested name as an additional member of the group. In this situation, if the existing name has a state of released or extinct, the name registration request is treated as a new registration.

• If a WINS client sends a name registration request for a DomainName[1D] name, a WINS server always returns a positive registration response, even though the WINS server does not add this name to the WINS database. When a WINS client queries a WINS server for this type of name, the server responds with a broadcast address, which forces the WINS client to broadcast to resolve the name.

Static names

In addition to supporting dynamic name registration, WINS supports static name registration for computers that do not directly communicate with WINS. Static names are added manually to the WINS database with the WINS Microsoft Management Console (MMC) snap-in or with the netsh wins server add name command. Static names do not automatically age and drop from the WINS database like dynamically-added names do. Static names remain in the database indefinitely unless there is manual intervention.

If a WINS client sends a name registration request for an existing static name, a WINS server by default always sends a negative name registration reply. This behavior can be overridden to always send a positive name registration reply.

Positive Name Registration Replies

When a WINS server sends a WINS client a positive name registration reply for a name that does not yet exist, it adds the name entry to the WINS database as follows:

• Calculates time stamp by adding current time to the renew interval

• Takes ownership

• Sets state to active

• Assigns a new version ID

When a WINS server sends a WINS client a positive name registration reply for a name and IP address that already exist in the WINS database, it updates the name entry in the WINS database. The following table describes the database updates for unique, dynamic name registrations.

Note

• A WINS server does not update existing database records for normal group entries or static entries because the server returns negative name registration replies for these types of name conflicts (unless the default behavior for group entries is overridden).

Name Registration Database Updates

State of Name	Server Action
Owned and active	Updates time stamp
Replica and active	Updates time stamp, takes ownership, increments version ID
Released	Updates time stamp, makes active, increments version ID
Owned and extinct	Updates time stamp, makes active, increments version ID
Replica and extinct	Updates time stamp, takes ownership, makes active, increments version ID

The time stamp is calculated as the sum of the current time and the renew interval. Changes that increment the version ID are replicated to all other WINS servers.

Burst Handling

High-volume (burst) server loads occur when a large number of WINS clients simultaneously attempt to register their names with a WINS server, such as when power is restored after an outage. A WINS server can use burst mode to respond positively to client requests before it processes and updates the WINS database.

Burst mode uses a configurable burst-queue size as a threshold value. This value specifies how many name registration and name renewal (also known as refresh) requests a WINS server processes normally before it starts burst-mode handling. By default, the value is 500. When the number of name registration and refresh requests exceeds the threshold value, a WINS server initiates burst mode.

During burst mode, a WINS server immediately responds to registration and refresh requests with a positive response that includes a very small TTL. The TTL value included in the response varies for different clients to distribute the actual registration load over time. This process slows the refresh and retry rate for new WINS clients and regulates the amount of WINS client network traffic.

For example, if the burst queue size is 500 entries and more than 500 requests are active, the WINS server replies immediately to the next 100 WINS registration and refresh requests by sending immediate positive responses, with a starting TTL value of 5 minutes. For each additional round of 100 client requests, the WINS server adds 5 minutes to the TTL, up to a maximum of 50 minutes. If WINS client traffic still arrives at burst levels, the WINS server responds to the next round of 100 client requests starting again with a TTL value of 5 minutes. The WINS server continues to increment the TTL until it reaches its maximum intake of 25,000 requests. At 25,000 requests, the WINS server begins dropping requests.

During burst handling, name release requests are queued along with name registration and refresh requests. When the queue becomes full, however, release requests are silently dropped. In this case, the names are released when their TTL expires.

Name query requests are queued indefinitely during burst handling.

Name Renewal

Dynamic NetBIOS names are not owned permanently. When a WINS server successfully registers a name, it sends the WINS client a positive name registration reply with a TTL value that specifies the life span of the name. The default TTL value in Windows Server 2003 is six days. It is the responsibility of the WINS client to renew the name before the TTL expires.

If the WINS client does not renew the NetBIOS name before the TTL expires, the state of the name is changed to released, and the WINS server eventually deletes the name from the WINS database, as described later. Static names do not expire, so they do not need to be renewed.

To renew a name, a WINS client sends a name refresh request to the WINS server. The WINS server treats name refresh requests similarly to name registration requests, by sending a name refresh reply that includes a new TTL. The following figure illustrates a renewal request.

Name Renewal

In this example, the WINS client, ClientC, sends a name refresh request to its configured primary server, WINSA. WINSA updates the database entry for ClientC to reflect an active state and sends a positive name refresh reply to ClientC with a new TTL.

WINS clients attempt to renew their NetBIOS names when one-half of the TTL value is reached or when the computer or the service restarts.

If the WINS server does not respond to the name refresh request, the WINS client continues to try the primary WINS server every 10 minutes for one hour, and then tries the secondary WINS server every 10 minutes for one hour. The process of trying first the primary server for an hour and then the secondary server for an hour continues until the name expires or the WINS server responds and renews the name.

Name Release

A NetBIOS name is released when it is no longer in active use by the WINS client that registered it. The owning WINS server does not respond to or resolve name queries for these names, unless the WINS client again registers the name.

Names can be released actively or passively. Expired names that are not renewed are released passively. WINS clients actively release their NetBIOS names when NetBIOS applications terminate properly, such as when a computer is shut down or a service is stopped, as shown in the following illustration.

Name Release

In this illustration, the following occurs:

1. When the computer, ClientC, shuts down properly, it sends a name release request to the WINS server, WINSA.

2. WINSA changes the state of ClientC's name entry in the WINS database to released, time-stamps the entry with the sum of the current time and the extinction interval, and takes ownership of the of name entry.

   Note

   • For active releases in Windows 98, the WINS server makes itself the owner of the name entry, if it is not already. In Windows NT 4.0 and later, if the WINS client sends a name release request to a different WINS server than it registered with, the WINS server changes the name entry to extinct instead of released, as described later in this section.

3. WINSA sends a positive name release response back to ClientC.

When a name entry is changed to the released state, the version ID is not updated and the change is not replicated to other WINS servers.

Released name entries are handled differently if the WINS server releasing the name is not the owner of the name entry, as described in the following table.

Released Name Handling

Server Is Owner of Name Entry	Server Is Not Owner of Name Entry
State set to release	State set to extinct
Time stamp calculated from current time plus extinction interval	Time stamp calculated from current time plus extinction interval plus extinction time-out
Release status information is not replicated to other WINS servers	Extinct status information is replicated to other WINS servers

The different approach for non-owners prevents inconsistencies between primary and secondary WINS servers, because released name entries are not replicated to other servers while extinct name entries are replicated.

If a network resource does not shut down properly, or the WINS client is unable to contact the WINS server during shutdown, the name might not be automatically released.

The released state simplifies WINS name registration for WINS clients that shut down and then restart. If a name is released, the WINS server does not challenge the name when the network resource restarts. If a proper shut down did not occur and the name is not released, the WINS server challenges the name on the next registration request if the IP address is different, as can happen when a DHCP-enabled laptop changes subnets. In such a case, the challenge fails (because the client cannot defend the old IP address) and the registration succeeds, but the registration requires extra processing.

Name Extinction and Deletion

When a name entry in the WINS database is marked released and the name is not reregistered, its state progresses to extinct. The name entry is marked with a series of time intervals that determine when the entry changes from released to extinct, and when it can be deleted from the database. The scavenge process checks the time intervals and makes these changes. This process runs automatically, based on the relationship between the configurable renewal and extinction intervals.

Name extinction

In general, name entries pass through the states described in the following table.

Progression of Inactive States

Current State of Name Entry	Resulting Status of Name Entry
Active state, TTL interval elapsed, WINS server is the owner of the name entry	Released
Active state, TTL interval elapsed, WINS server is not the owner of the name entry	Extinct
Released state, extinction interval is not elapsed	Released
Released state, extinction interval is elapsed	Extinct
Extinct state, extinction time-out is not elapsed	Extinct, not ready for deletion
Extinct state, extinction time-out is elapsed	Extinct, deleted during scavenging

Because changing a name entry to the extinct state results in replication, rapid synchronization of WINS databases occurs. The extinct state prevents inconsistencies from lingering. For example, if the primary WINS server of a WINS client is unavailable when the client shuts down, the name release request is directed to the secondary WINS server. If the primary WINS server is available again when the client restarts, the client registers and continues to renew with the primary WINS server, which has not recorded any change in the status of the client, while the secondary WINS server still reflects the released state of the name entry.

Name deletion

Extinct name entries that have expired extinction time-out intervals are automatically deleted from the WINS database by the scavenge process. Because changing the status to extinct causes name entries to be replicated, replication typically ensures that the name entries are extinct in all copies of the WINS database before any of the entries are deleted, thus ensuring that the name entries are deleted from all copies of the database.

Under certain abnormal conditions, however, names no longer in use can remain in the database. For example, if an extinct entry is deleted before it is replicated, the active state of the record in the replica databases never changes. This might happen if a replication copy of the database is not reachable during the extinction time-out period.

When an active entry is replicated, it is time-stamped on the pulling server (the WINS server requesting the replication) with the sum of the current time and the verification interval. The default verification interval is 24 days. If the scavenge process determines that there are entries with an expired verification interval, the WINS server sends a name query to the WINS server that owns the name entry to determine whether the version ID is still valid. The following table describes the possible courses of action based on the owning WINS servers response.

Verification Interval Evaluation

Owning WINS Server Response	Action Taken
Negative response (name entry is invalid)	Name entry is deleted
Positive response (name entry is valid)	Time stamp is updated
No response	Name entry left intact until next verification interval or until an administrator manually scavenges it

The scavenge process determines which name entries need to be updated or deleted based on ownership, state, and time stamp. This process releases name entries when appropriate, deletes extinct name entries, and verifies whether names are still in use after the verification interval expires. The scavenge process runs periodically based on a scavenging time interval. The scavenging time interval starts at WINS server startup and is half the renew interval (by default, 72 hours). If a WINS server is stopped and restarted before 72 hours have elapsed, the scavenging time interval is reset. If a WINS server is stopped on a daily basis, scavenging does not occur. Scavenging can also be initiated manually.

The following table summarizes the changes the scavenge process makes to name entries in the WINS database.

Changes to Name Entries During Scavenging

Pre-Scavenge State	Post-Scavenge State
Owned, active state, renew interval not expired	Unchanged
Owned, active state, renew interval expired	Marked released
Owned, released state, extinction interval not expired	Unchanged
Owned, released state, extinction interval expired	Marked extinct
Owned, extinct state, extinction time-out not expired	Unchanged
Owned, extinct state, extinction time-out expired	Deleted
Replica, extinct state, extinction time-out expired	Deleted
Replica, active state, verification interval not expired	Unchanged
Replica, active state, verification interval expired, owner challenged, positive response (name entry exists in owner’s database)	Time stamp updated (current time plus verification interval)
Replica, active state, verification interval expired, owner challenged, negative response (name does not exist in owner’s database)	Deleted
Replica, active state, verification interval expired, owner challenged, no response received	Unchanged

During the first scavenging run, all the actions described in the previous table are performed except for deleting name entries. Name entries are not deleted until at least three days after WINS server startup. This delay allows sufficient time for replicating the entries that are ready to be deleted.

In addition to the database cleanup that occurs during the scavenge process, database consistency checks verify name entries in the local database and update name entries as necessary to match the owner entry. Version ID consistency checks verify that owner version IDs are higher than replica version IDs at other WINS servers.

Name Resolution

When a computer needs to communicate with another network resource that uses a NetBIOS name, the computer must first acquire the network resource’s IP address before communications can be established. Name resolution is the process of obtaining the IP address for a NetBIOS name.

As the following figure illustrates, the WINS client sends the NetBIOS name to a WINS server, the WINS server sends the IP address back to the client, and then the client uses the IP address to connect to the remote computer.

Name Resolution

In this figure, ClientA, a WINS client, needs to connect to ClientB. ClientA sends a name query request for the NetBIOS name ClientB to its primary WINS server, WINSA. WINSA finds ClientB in the WINS database and returns the IP address 192.168.1.17 to ClientA, and ClientA then connects to ClientB.

The precise steps for resolving a NetBIOS name depend on the client's NetBIOS node type. B-node clients broadcast the name request to the local subnet. P-node clients use a WINS server only. M-node clients first try broadcasting, and if that is unsuccessful, they use a WINS server. H-node clients first try a WINS server, and if that is unsuccessful, they try broadcasting. This section focuses on the WINS server part of the process.

WINS clients running Windows 2000, Windows XP, or Windows Server 2003 are configured by default to use DNS first to resolve names that are longer than 15 characters or that have periods (.) within the name. If the client is configured to use a DNS server, DNS is used again as a final option if a WINS query is unsuccessful for names that are less than 15 characters and that do not have periods.

For NetBIOS name resolution, a WINS client typically performs the following progression of steps until either the name is resolved or all methods have failed to return an IP address:

1. Client checks its local NetBIOS name cache of remote names. Recently resolved NetBIOS names (up to 16, by default) are held in this cache for 10 minutes.

2. Client sends the NetBIOS name query request to its configured primary WINS server. If the primary WINS server fails to respond, either because it is not available or because it does not have an entry for the name, the client tries to contact all other configured WINS servers in the order they are listed in its configuration.

3. If the client uses H-node, it broadcasts the NetBIOS name query to the local subnet up to three times. (If the client uses M-node, it performs this step before contacting the WINS server (step 2). If the client uses P-node, it does not perform this step.)

4. Client checks the Lmhosts file, if Lmhosts is enabled in the WINS tab of the advanced TCP/IP properties.

5. Client converts the NetBIOS name to a host name by removing the last byte and any spaces at the end of the NetBIOS name.

6. Client checks to see if the host name corresponding to the converted NetBIOS name matches the local host name.

7. Client checks the DNS client resolver cache.

8. Client tries a DNS server, if it is configured for one.

If the WINS server resolves the name query request, the WINS server sends a positive name query reply that includes the requested IP address to the client. When the client receives the reply, it uses the address to establish a connection to the desired network resource.

If the WINS server cannot resolve the name query request or if the request is for a unique name that is in a released or extinct state, it sends a negative name query reply to the client. If none of these steps can resolve the name, Windows returns an error.

Name Queries for Normal Groups

A normal group name does not have an IP address associated with it, so when a WINS server receives a name query request for a registered normal group name, it cannot return a specific address. Instead, the WINS server returns the limited broadcast address (255.255.255.255). The WINS client then issues a broadcast to its local subnet to resolve the name.

If the request is for a normal group name that is in a released or extinct state, a WINS server sends a positive name query reply and also sends the limited broadcast address (255.255.255.255).

Name Queries for Special Groups

A special group can have multiple IP addresses (up to 25) associated with it. When a WINS server receives a name query request for a special group, it returns all the IP addresses for which the TTL has not expired.

Note

• The WINS server sends as many addresses as it can fit into a UDP message. Because special groups are limited to 25 addresses, all the addresses fit into the UDP message.

WINS Proxy Name Services

When a WINS proxy is located on a subnet that includes B-node clients, the WINS proxy can mediate B-node name services requests for registration, release, and resolution by taking the following actions:

• Perform a name lookup during name registration and send a negative name registration reply if it finds the name in its local cache of remote names or in the WINS database.

• Delete the B-node client name from its cache of remote names, when a client releases its name.

• Attempt to resolve a B-node name query request by using information from either its local cache of remote names or from the WINS server.

Proxy Support for Name Registration Requests

When a B-node client broadcasts a name registration request, the WINS proxy receives the broadcast and then does a name lookup for names that do not exist on the local subnet. First it uses its local cache of remote NetBIOS names, and if the name is not in the cache, the WINS proxy sends a name query request to the WINS server. If the unique name is found in the WINS database, the proxy sends a negative name registration reply to the B-node client.

Proxy Support for Name Release

When a B-node network resource shuts down, WINS proxies simply delete the name from the local name cache in response to the name release request.

Proxy Support for Name Resolution

WINS proxies support NetBIOS name resolution for B-node clients. They receive B-node name query broadcasts and respond for names that are not found on the local subnet.

The following figure illustrates how a WINS proxy resolves names for non-WINS clients.

WINS Proxy Name Resolution

In this example, the WINS proxy (ClientB) performs the following steps to resolve names for the B-node client (ClientA):

1. ClientA broadcasts a NetBIOS name query request to the local subnet (Subnet 1).

2. ClientB receives the broadcast and checks its cache of remote names for the requested NetBIOS name. The WINS proxy always differentiates name queries for local names from remote names. It compares the address of names it resolves to its own address by using the subnet mask, and if the two match, the WINS proxy does not respond to the name query.

3. If ClientB locates the NetBIOS name in its cache, ClientB sends a positive name query reply to ClientA with the IP address.

4. In this example, ClientB cannot locate the NetBIOS name in its cache, so ClientB sends a name query request to the WINS server, WINSA, and enters the requested name in its cache of remote names in a “resolving” state. If ClientB receives another query for the same name before the WINSA responds, ClientB does not query WINSA again.

5. If WINSA cannot resolve the name, it sends a negative name query reply to ClientB, which in turn sends a negative name query reply to ClientA.

6. In this example, WINSA can resolve the name, so it sends a positive name query reply with the IP address to ClientB. ClientB updates the cache entry with the IP address and changes the state to resolved.

   By default, WINS proxies cache remote name mappings resolved by the WINS server for 6 minutes.

7. ClientB sends a positive name query response to ClientA and uses the name mapping in its cache to respond to subsequent NetBIOS name queries broadcast from any B-node clients on the subnet. A WINS proxy sends reply messages only if the response is already in its cache.

Note

• When a WINS proxy responds to a query for a multihomed client or for a group record that contains a list of IP addresses, it returns only the first address to the B-node client.

Replication

Typically, large environments include multiple WINS servers. When multiple WINS servers are used, they can be configured to replicate, or copy, records from one WINS database to other WINS databases. Replication keeps all the WINS databases synchronized and ensures that the names registered on one WINS server are available on all WINS servers. Replication supports the following:

• Reduced name services traffic over WANs

• Redundancy

• Load balancing

• Scalability

For a WINS server to replicate data, it must be configured with at least one other WINS server as its replication partner. Replication partners are WINS servers that are configured to have a replication relationship with each other.

There are three types of replication partners, as described in the following table.

Types of Replication Partners

Type of Partner	Description
Push	A WINS server that is configured to notify its pull partner when there are updated entries in the WINS database that are available for replication. Push partners initiate replication.
Pull	A WINS server that is configured to request the updated WINS database entries that are ready for replication.
Push/pull	A WINS server that is configured to act both as a push partner and a pull partner. This is the default configuration.

A WINS server can be configured to discover its replication partners automatically (known as autodiscovery) or it can be manually configured for specific replication partners. WINS servers periodically announce their presence on the network. The WINS announcements are sent on a multicast address that is reserved for WINS (224.0.1.24). WINS servers that are configured for automatic discovery listen for the announcements and find other WINS servers on the network. Any WINS server discovered this way is automatically added to the replication partners list as a push/pull partner.

Regardless of whether servers are configured for one-way replication (push only or pull only) or for two-way replication (push/pull), the primary and secondary WINS servers for a client must have a push and pull relationship to each other to ensure that WINS functions properly if the primary server fails.

The following figure illustrates how replication works. Two WINS servers, WINSA and WINSB, are configured to be replication partners.

WINS Database Replication

In this figure, a WINS client (ClientA) on Subnet 1 registers its name with its primary WINS server, WINSA, and its name is updated in the WINSA database. Another WINS client (ClientB) on Subnet 3 registers its name with its primary WINS server, WINSB, and its name is updated in the WINSB database. If, after replication, ClientA sends a name query request to WINSA to find an IP address for ClientB, ClientB will be in the WINSA database.

WINS replication is always incremental, which means that only changed records, rather than all records, are replicated.

Persistent Connections

By default WINS uses persistent connections between replication partners. When they use persistent connections, WINS servers do not disconnect from their replication partners each time replication is completed and, therefore, avoid the overhead and delays of establishing a new connection each time replication begins. Typically when WINS servers are interconnected through high-speed LAN links, it is preferable to keep connections open.

Persistent connections increase the speed of replication because a server can immediately send updates to its partners, making replication more consistent. The bandwidth used by persistent connections is minimal because the connection is usually idle.

Persistent connections can be used with push partners and pull partners, either with a specific partner or with all the replication partners of a WINS server.

Version ID

Every name entry in a WINS database has a version ID field. This field is incremented whenever a change that is to be replicated takes place. That is, the version ID for a name is incremented whenever that name is registered, changed from a released to an active state, or changed to an extinct state.

The value in version ID reflects the total number of replicable changes that occurred to owned entries for that particular WINS server. The value is incremented by hexadecimal 1 every time a replicable change occurs. For example, if WINSA is the owner for ClientA, which has a version ID of 4B3, and for ClientB, which has a version ID of 4C2, ClientB was the fifteenth replicated change in the WINSA database after the ClientA change.

The number of changes in version ID is one way that WINS determines when to trigger replication between two servers.

Push Partners

A push partner is a WINS server that is configured to push or notify other WINS servers when it has database updates that are ready to be replicated. Push partners initiate replication. They notify replication partners when it is time for the partners to pull updates, but they do not send any updates.

A push partner can be configured to use any of the following events to trigger the push notification:

• WINS server startup.

• An IP address change in a name-to-address mapping in the database.

• A specified number of version ID changes occur. This number is the number of local changes and does not include changes pulled from other partners. WINS can use this number as a threshold for determining how many changes must be made to the database before it starts push replication to its partners. This number can apply globally to all partners to which it pushes or individually to specific partners.

When persistent connections are used for push replication and the number of version ID changes for triggering replication is set to 0 (the default), the push partner sends a push trigger notifying its replication partners every time an update occurs. In this situation, push replication is not dependent on the number of times version ID changes but occurs at every update. (An update is defined here as a change that increments the highest version ID in the local WINS database for records the server owns.) If the number of version ID changes is greater than 0, the frequency of push notifications is reduced.

If persistent connections are not used for push replication, push replication is dependent on the number of times the version ID changes. If this number is set to zero, push replication never occurs, except if it is set to occur at service startup or when IP addresses change. If the number of version ID changes is greater than 0 when persistent connections are not used, the frequency of push notifications is increased.

For example, suppose that the highest version ID for server WINSA is 1C4. WINSA is also set to push to its replication partners when there have been two updates in its database. Suppose also that the following four sets of database changes are then made to the WINS database at WINSA:

1. ClientA refreshes its previously registered name but keeps the same IP address.

2. ClientB registers its name, creating a new dynamic name-to-address mapping in the database.

3. ClientC reregisters a previously released name and changes its IP address.

4. A pull replication occurs at a specified interval with another WINS server.

When these changes are entered into the database, the highest version ID for WINSA is 1C6 because two of the changes — update 2 (registering a new name) and update 3 (changing an IP address) — cause the version ID for that server to be incremented.

After these changes occur, WINSA then sends a push notification to its replication partners.

Pull Partners

A pull partner is a WINS server that is configured to pull, or request replication of, updated WINS database entries from other WINS servers (those configured as its push partners) at a configured interval. Push replication can occur in response to a specified event, in response to a manual request by an administrator, or in response to a push trigger.

A pull partner pulls or requests entries that have a higher version ID than the last entry it received from its configured replication partner.

A pull partner can be configured to use either of the following events to trigger the request for replication:

• WINS server startup

• A user-specified amount of elapsed time, which can apply globally to all the partners from which it pulls or individually to specific partners

When the specified time has elapsed, the pull partner sends a replication request to its configured partners. The partners respond with incremental updates, if any have occurred since the last replication.

Database updates are not physically replicated until a pull partner sends a replication request in response to the notification sent by a push partner. Therefore, pull replication can be viewed as the single process used to replicate data between WINS databases.

The IP address-to-owner ID table in the WINS database is used during the replication process. In addition, all WINS servers maintain an internal push partner owner-to-version mapping table. During WINS initialization, a WINS server scans the name-to-IP address mapping table to find the highest version ID for each owner in the IP address-to-owner ID table. The WINS server uses the information to build the push partner owner-to-version table, which maps the owner IDs to their highest version IDs. The WINS server maintains this table in memory and never commits it to the database. WINS uses the push partner owner-to-version table to determine the state of the database at any point before or after replication.

During replication, the WINS server updates the push partner owner-to-version table with the highest version IDs sent by its push partners. The WINS server then scans the version ID field in the name-to-IP address table to find the highest version ID for each owner and compares the results with the numbers in the push partner owner-to-version table to determine which push partner has the latest data for each owner. The WINS server also updates its IP address-to-owner ID table with additional owners obtained from its push partners.

The following figure illustrates how WINS manages replication. In this example, four WINS servers (WINSA, WINSB, WINSC, and WINSD) are all configured as push/pull partners for a central server, WINSH.

Example of Pull Replication

Before replication begins in this example, the owner-to-version table at WINSA contains the highest version IDs for all the owners in its database. Assume that these values are the values shown in the following table.

WINSA Owner-to-Version Table

Owner	Name	Highest Version ID
192.168.1.5	WINSA	1F
192.168.2.5	WINSH	125
192.168.3.5	WINSB	31
192.168.4.5	WINSC	100
192.168.5.5	WINSD	200

In reality, pull replication can occur dynamically between WINSH and WINSA, WINSB, WINSC, and WINSD at various times, so the table might not remain static for long. To simplify the details of an individual pull replication cycle, however, the example below focuses on what might happen when WINSA replicates its database with WINSH.

In this example, the following changes occur in the replicated WINS network:

1. Assume that first WINSB, WINSC, and WINSD each replicate with WINSH, based on the highest version ID.

   1. WINSB has added or updated one new record since its last replication cycle, which is replicated at WINSH.

   2. WINSC has the same version ID and does not have any records to be replicated at WINSH.

   3. WINSD has updated 20 records since its last replication cycle, which are replicated at WINSH.

2. Assume that after WINSB, WINSC, and WINSD replicate with WINSH, WINSH sends a push trigger to WINSA, initiating replication. WINSA then pulls the updated owner-to-version information from WINSH.

3. WINSA responds by pulling entries from WINSH.

   WINSA determines which updates it needs to pull based on the difference between its locally-held highest version ID for each owner and the corresponding highest version IDs provided by WINSH. WINSA specifies the range of records to be pulled and replicated by comparing version IDs. In this example, WINSA pulls updates that occurred on WINSH with a version ID greater than 125, updates that occurred on WINSB with a version ID greater than 31, and updates that occurred on WINSD with a version ID greater than 200.

If another pull replication to the same partner is already queued, WINS treats the later request as further down in the queue and discards it in favor of keeping the one that is higher in the queue.

Accepting and Blocking Replication Partners

WINS servers can be configured to accept updates only from specific replication partners (known as persona grata) or to block updates from specific replication partners (known as persona non grata) during replication. A WINS server can be configured for only one of these options. These options apply either during push-pull replication or during pull replication.

Accepting replication partners

When a WINS server is configured to accept specific replication partners, only updates from WINS servers that are included in the list are replicated. For example, accepting replication from specific partners might be useful when WINS servers are configured in a hub-and-spokes pattern, where a central server is the hub and other distributed servers are the spokes. By including only the IP addresses for the hubs in the list, you can replicate updates only between the hubs, without including the spokes.

If a WINS server is configured to accept updates from specific partners and no list of accepted WINS servers is provided, no updates are replicated. Accepting updates only from specific partners is a new WINS feature in Windows Server 2003.

Blocking replication partners

When a WINS server is configured to block specific replication partners, only updates from WINS servers that are not in the list are replicated. For example, blocking replication partners is useful when a WINS server is removed from service. After a WINS server is removed from service, name entries it owns can continue to be replicated to other servers. Replication of these records can occur for one of the following reasons:

• Static entries that were originally added to the now inactive WINS server replicate indefinitely to the other active WINS servers in the network until the entries are deleted manually.

• Dynamic entries that were originally added to the now inactive WINS server are not immediately deleted from the WINS database. WINS must check with the owner server before it deletes dynamic entries. If a database entry cannot be verified as expired because the owner server is no longer in use, other WINS server's retain the entry until it can be verified.

The blocking replication partners option can prevent replication of name entries from inactive WINS servers.

If a WINS server is configured to block updates and no list of blocked WINS servers is provided, updates are replicated for all WINS servers.

Owner ID and Time Stamp During Replication

WINS replicates only name entries in the active and extinct states. During replication, the fields for these database entries are copied, with the exception of owner ID and time stamp.

The owner ID is obtained from the local owner ID-to-version ID mapping table because the value that is used locally to represent a specific WINS server differs from server to server. For example, WINSD might be represented as owner ID 2 on WINSB and as owner ID 3 on WINSA.

When a name entry is replicated, it is given a new time stamp. Active name entries are time-stamped with the sum of the local current time and the verification interval. Extinct name entries are time-stamped with the sum of the local current time and the extinction time-out.

Name Conflicts During Replication

Although name conflicts are usually handled at the time of name registration, it is possible for the same name to be registered at two different WINS servers. This situation might happen if a WINS client registers the same name at a second WINS server before the updates from the first WINS server replicate to the second. In this case, WINS resolves the conflict at replication time.

Conflicts at replication can be between two unique name entries, between a unique name entry and a group name entry, or between two group name entries.

Conflicts between unique name entries

When two unique names conflict, WINS resolves the conflict based on three factors:

• State of the entries (active, released, or extinct)

• Ownership of the entries

• Same or different IP addresses

This section describes how WINS resolves conflicts between unique names.

Conflicts between two replicas

When two replicas conflict, the new replica overwrites the existing replica, regardless of whether the addresses match. The only exception to this rule is if the existing replica is active and the new replica is extinct. If the existing replica is active, the new replica is extinct, and different WINS servers own the replicas, then the new replica does not overwrite the existing replica. If the existing replica is active, the new replica is extinct, and the same WINS server owns both, the new extinct replica overwrites the existing active replica.

Conflicts between owned entries and replicas with the same IP address

The replica replaces the owned entry unless the owned entry is active and the replica is extinct. In this case, WINS increments the version ID of the owned entry so that it replicates during the next iteration.

Conflicts between owned entries and replicas with different IP addresses

The replica replaces the owned entry unless the owned entry is active. If the owned entry is active and the replica is extinct, WINS increments the version ID of the owned entry so that it replicates during the next iteration. If both the owned entry and the replica are active, the server receiving the replica challenges the client that registered the owned entry to determine whether the client still uses the name. If it does still use the name, WINS sends the client designated in the replica a name conflict demand. This message puts the client in a conflict state, which forces the client to put the name in a conflict state. A name in a conflict state is marked and the name is no longer used.

Conflicts between unique entries and group entries

When a unique entry and a group entry conflict, WINS keeps the group entry. If the WINS server owns the unique entry and the entry is not in a released or extinct state, the WINS server requests the client named in the unique entry to release the name.

Conflicts between two special group entries

When there is a conflict between two special groups, the new replica replaces the existing entry unless the existing entry is active. If the existing entry is active, WINS increments its version ID so that it replicates at the next iteration. If the new replica is also active, the WINS server updates the member list of the existing entry with any new members from the replica. If the list of active members grows to more than 25, the extra members are not added but are dropped silently.

Conflicts involving multihomed entries

If one of the name entries involved in a name conflict is for a multihomed node, the conflict is resolved in one of the following ways:

• If a multihomed replica conflicts with an extinct or released entry in the database, WINS replaces the existing entry in the database with the replica, unless the existing entry is a normal group and is in a released state. This is the same as the other scenarios in which a single-address entry conflicts with a released normal group entry.

• If a multihomed replica that is extinct conflicts with an active existing entry and both entries are owned by the same server, WINS replaces the active existing entry. If the active existing entry is a replica owned by a different server, WINS does not replace the existing entry. If the active existing entry is owned by the local WINS server and is a unique entry, WINS increments the version ID of the existing record to force replication.

• If an active multihomed replica conflicts with an active, unique, multihomed replica in the local database with the same owner, WINS replaces the existing entry. If the owner is different, WINS does not replace it. If the entry in the database is owned by the local WINS server, and if the members of the record (a single member in the case of a unique record) are a subset of the members of the replica, WINS changes the time stamp of the existing entry and increments its version ID to force replication. If the members of the replica are not a subset, the WINS server challenges the addresses in the existing entry. If there are no responses to the challenges, WINS replaces the existing entry. If there is at least one response to the challenges, WINS notifies the client to release the name from all addresses before it replaces the existing entry with the replica.

• If a multihomed replica conflicts with an existing active group entry, WINS increments the version ID of the existing entry to force replication.

• If a single-address replica conflicts with an existing inactive multihomed entry, WINS replaces the existing entry with the replica. If the replica conflicts with an existing active multihomed entry and both entries are owned by the same owner, WINS replaces the existing entry with the replica. If the existing multihomed entry is a replica owned by a different server, WINS does not replace it. If, however, the existing multihomed entry is owned by the local WINS server and the new replica is a unique record, then WINS challenges the clients that use the addresses in the multihomed record. If there are no responses to the challenges, WINS replaces the existing entry. If there is at least one response to the challenges, WINS sends requests for the name to the addresses in the existing entry and then updates the existing entry. The address in the unique replica, if present in the member list, is ignored in this situation.

WINS Convergence Time

There is a latency period between the time a database entry is updated at one WINS server and the time the entry is replicated to all other WINS servers in the network. This latency period is known as the convergence time for the WINS system. Convergence time can be computed as the sum of the configured replication periods from one server to the next over the longest path. The following figure illustrates a replication configuration and indicates the replication periods between nodes. This figure is not intended to be a realistic configuration, but merely to illustrate a longest replication path.

WINS Convergence

In this figure, the longest replication path is from WINSB to WINSA to WINSC. A name registration request from one of the WINS clients causes the WINSB database to be updated. Changes to the WINSB database are replicated to WINSA every hour, and changes are replicated from WINSA to WINSC every two hours. Therefore, the convergence time for the name registration request in this example is three hours.

The convergence time can vary among different types of name services. For example, name registration requests that occur at one server replicate to the server's replication partner at the next replication event. Name release requests, however, are not replicated. NetBIOS names are released when a network resource shuts down. Because it is common for these names to be reused with the same IP address when the network resource is restarted, replicating the name releases unnecessarily increases the network load of replication. Since these name service requests are not replicated, however, a NetBIOS name can be in the release state in one WINS database and still be in the active state in all other WINS databases.

In addition, some changes can take place and not be reflected in any of the WINS databases. For example, if a WINS client shuts down improperly, as in the case of an unexpected power outage, it is unable to send a name release request to its primary WINS server, and the registered names are not marked as released in the WINS database.

Replication and Name Services Summary

The following table describes typical events that might occur in a NetBIOS network, the name service operations they invoke, the resulting WINS database updates, and whether or not the changed name entry is replicated. These scenarios assume that the WINS server handling the name service request is the owner for the name entry and that each name service request results in a positive response.

Typical WINS Scenarios

Event	Name Service Request / WINS Process	WINS Database Updates	Replication
Computer starts up	Name registration	Name added to database State set to active Owner ID set Version ID incremented Renew interval set	Yes
Computer shuts down	Release	State set to released Owner ID set Extinction interval set	No
Computer restarts, same name and IP address	Name registration	State set to active Owner ID set Version ID incremented Renew interval set	Yes
Computer stays up, renew interval nears	Name refresh	Name added to database State set to active Owner ID set Version ID incremented Renew interval set	Yes
Computer shuts down and restarts on different subnet with different primary WINS server, same name but different IP address	Name registration, which is challenged	State remains active (release from shutdown not replicated) Owner ID set Version ID incremented Renew interval set	Yes
Computer shuts down and stays down, extinction interval expires	Database scavenge	State set to extinct Version ID incremented Extinction time-out set	Yes
Computer remains shut down, extinction time-out expires	Database scavenge	Entry deleted during scavenging	No

Related Information

The following resources contain additional information that is relevant to this section.

• “How DHCP Technology Works”

• “How DNS Works”

For more information about WINS, see the following RFCs in the IETF RFC Database.

• RFC 1001, “Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods.”

• RFC 1002, “Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications.”