Chapter 12 - Windows Internet Name Service Overview

Published: June 27, 2005 | Updated: April 18, 2006

Writer: Joe Davies

Abstract

This chapter describes the use of Windows Internet Name Service (WINS) in Microsoft® Windows Server™ 2003 and Windows® XP operating systems to provide network basic input/output system (NetBIOS) name resolution on a TCP/IP network. A network administrator must understand the role and configuration of WINS clients, WINS servers, and WINS proxies to successfully deploy a NetBIOS name resolution infrastructure and to troubleshoot issues with NetBIOS name resolution.

For a download of the entire "TCP/IP Fundamentals for Microsoft Windows" online book, which contains a version of this chapter that has been updated for Windows Vista and Windows Server 2008, click here.

On This Page

Chapter Objectives
Introduction to WINS
How WINS Works
The WINS Client
The WINS Server Service
The WINS Proxy
Chapter Summary
Chapter Glossary

Chapter Objectives

After completing this chapter, you will be able to:

• Describe the function of Windows Internet Name Service (WINS).

• Explain how WINS clients perform name registration, name renewal, name refresh, and name resolution.

• Configure a WINS client to use primary and secondary WINS servers.

• Install a WINS server and configure it for static mappings and to replicate its database with other WINS servers.

• Describe the function and configuration of a WINS proxy.

Introduction to WINS

Windows Internet Name Service (WINS) is the Windows implementation of a NetBIOS name server (NBNS), which provides a distributed database for registering and querying dynamic mappings of NetBIOS names to IPv4 addresses used on your network. WINS is designed to provide NetBIOS name resolution in routed TCP/IP networks with multiple subnets. Without WINS, you must maintain Lmhosts files.

Before two hosts that use NetBIOS over TCP/IP (NetBT) can communicate, the destination NetBIOS name must be resolved to an IPv4 address. TCP/IP cannot establish communication using a NetBIOS computer name. The basic procedure for WINS-based NetBIOS name resolution is the following:

1. Each time a WINS client starts, it registers its NetBIOS name-to-IPv4 address mappings with a configured WINS server.

2. When a NetBIOS application running on a WINS client initiates communication with another host, NetBT sends a NetBIOS Name Query Request message with the destination NetBIOS name directly to the WINS server, instead of broadcasting it on the local network.

3. If the WINS server finds a NetBIOS name-to-IPv4 address mapping for the queried name in its database, it returns the corresponding IPv4 address to the WINS client.

Using WINS provides the following advantages:

• Client requests for name resolution are sent directly to a WINS server. If the WINS server can resolve the name, it sends the IPv4 address directly to the client. As a result, a broadcast is not needed and broadcast traffic is reduced. However, if the WINS server is unavailable or does not have the appropriate mapping, the WINS client can still use a broadcast in an attempt to resolve the name.

• The WINS database is updated dynamically so that it is always current. This process allows NetBIOS name resolution on networks using DHCP and eliminates the need for local or centralized Lmhosts files.

• WINS provides computer browsing capabilities across subnets and domains. Computer browsing provides the list of computers in My Network Places.

How WINS Works

The WINS Server service in Windows Server 2003 is an implementation of an NBNS as described in Requests for Comments (RFCs) 1001 and 1002. WINS clients use a combination of the following processes:

• Name registration

  Each WINS client is configured with the IPv4 address of a WINS server. When a WINS client starts, it registers its NetBIOS names and their corresponding IPv4 addresses with its WINS server. The WINS server stores the client’s NetBIOS name-to-IPv4 address mappings in its database.

• Name renewal

  All NetBIOS names are registered on a temporary basis so that if the original owner stops using a name, a different host can use it later. At defined intervals, the WINS client renews the registration for its NetBIOS names with the WINS server.

• Name resolution

  A WINS client can obtain the IPv4 addresses for NetBIOS names by querying the WINS server.

• Name release

  When a NetBIOS application no longer needs a NetBIOS name, such as when a NetBIOS-based service is shut down, the WINS client sends a message to the WINS server to release the name.

These processes are described in greater detail in the following sections.

All WINS communications between WINS clients and WINS servers use unicast NetBIOS name management messages over User Datagram Protocol (UDP) port 137, the reserved port for the NetBIOS Name Service.

Name Registration

When a WINS client initializes, it registers its NetBIOS names by sending a NetBIOS Name Registration Request message directly to its configured WINS server. NetBIOS names are registered when NetBIOS services or applications start, such as the Workstation, Server, and Messenger services.

If the NetBIOS name is unique and another WINS client has not already registered the name, the WINS server sends a positive Name Registration Response message to the WINS client. This message contains the amount of time, known as the Time to Live (TTL), that the NetBIOS name is registered to the WINS client. The TTL is configured on the WINS server.

When a Duplicate Name Is Found

If a duplicate unique name is registered in the WINS database, the WINS server sends a challenge to the currently registered owner of the name as a unicast NetBIOS Name Query Request message. The WINS server sends the challenge three times at 500-millisecond intervals.

If the current registered owner responds to the challenge successfully, the WINS server sends a negative Name Registration Response message to the WINS client that is attempting to register the duplicate name. If the current registered owner does not respond to the WINS server, the server sends a positive Name Registration Response message to the WINS client that is attempting to register the name and updates its database with the new owner.

When WINS Servers are Unavailable

A typical WINS client is configured with a primary and a secondary WINS server, although you can configure more than two WINS servers. A WINS client makes three attempts to register its names with its primary WINS server. If the third attempt gets no response, the WINS client sends name registration requests to its secondary WINS server (if configured) and any additional servers that have been configured. If none of the WINS servers are available, the WINS client uses local broadcasts to register its NetBIOS names.

Name Renewal

To continue using the same NetBIOS name, a client must renew its registration before the TTL it received in the last positive Name Registration Response message expires. If the client does not renew the registration, the WINS server removes the NetBIOS name from its database. After that point, other computers cannot resolve the NetBIOS name to the address of the former owner and another client can register the name for itself.

Name Refresh Request

Every WINS client attempts to renew its NetBIOS names with its primary WINS server by sending a NetBIOS Name Refresh message when half of the TTL has elapsed or when the computer or the service restarts. If the WINS client does not receive a NetBIOS Name Registration Response message, the client sends another refresh message to its primary WINS server every 10 minutes for one hour. If none of these attempts is successful, the client then tries the secondary WINS server every 10 minutes for one hour. The client continues to send refresh messages to the primary server for an hour and then to the secondary server for an hour until either the name expires or a WINS server responds and renews the name.

If the WINS client succeeds in refreshing its name, the WINS server that responds to the NetBIOS Name Refresh message resets the renewal interval. If the WINS client fails to refresh the name on either the primary or secondary WINS server during the renewal interval, the name is released.

Name Refresh Response

When a WINS server receives the NetBIOS Name Refresh message, the server sends the client a positive Name Registration Response message with a new TTL.

Name Release

When a NetBIOS application running on a WINS client is closed, NetBT instructs the WINS server to release the unique NetBIOS name used by the application. The WINS server then removes the NetBIOS name mapping from its database.

The name release process uses the following types of messages:

• Name Release Request

  The Name Release Request message includes the client’s IPv4 address and the NetBIOS name to be removed from the WINS database.

• Name Release Response

  When the WINS server receives the Name Release Request message, the server checks its database for the specified name. If the WINS server encounters a database error or if a different IPv4 address maps to the registered name, the server sends a negative Name Release Response message to NetBT on the WINS client.

  Otherwise, the WINS server sends a positive Name Release Response message and then designates the specified name as inactive in its database. The positive Name Release Response message contains the released NetBIOS name and a TTL value of 0.

Name Resolution

Computers that are running Windows Server 2003 or Windows XP and that are configured with the IPv4 addresses of WINS servers by default use the H-node NetBIOS node type. NetBT always checks the WINS server for a NetBIOS name-to-IPv4 address mapping before sending a broadcast. The NetBIOS name resolution process is the following:

1. NetBT checks the NetBIOS name cache for the NetBIOS name-to-IPv4 address mapping of the destination.

2. If the name is not resolved from the NetBIOS name cache, NetBT sends a unicast NetBIOS Name Query Request message to the configured primary WINS server.

   If the primary WINS server can resolve the name, the server responds with a positive NetBIOS Name Query Response message that contains the IPv4 address for the requested NetBIOS name.

   If the primary WINS server does not respond after three separate attempts or responds with a negative Name Query Response message, the client sends a NetBIOS Name Query Request message to its configured secondary WINS server.

   If additional WINS servers are configured and the secondary WINS server does not respond after three separate attempts or responds with a negative Name Query Response message, the client sends a NetBIOS Name Query Request message to the additional configured WINS server or servers in configuration order.

3. If none of the servers respond with a positive Name Query Response message, the WINS client broadcasts up to three Name Query Request messages on the local subnet.

If the name is not resolved from these methods, the WINS client might still resolve the name by parsing the Lmhosts file; converting the NetBIOS name to a single-label, unqualified domain name; and checking it against the local host name, the Domain Name System (DNS) client resolver cache, and DNS. For more information, see Chapter 11, "NetBIOS Over TCP/IP."

The WINS Client

You can configure the WINS client, known as the TCP/IP NetBIOS Helper service in the Services snap-in, in the following ways:

• Automatically, using the Dynamic Host Configuration Protocol (DHCP) and DHCP options.

• Manually, using either the Netsh tool or the properties of the Internet Protocol (TCP/IP) component in Network Connections.

• Automatically, for Point-to-Point Protocol (PPP) connections.

To determine the IPv4 addresses of the WINS servers that are assigned to the connections of your computer running Windows Server 2003 or Windows XP, do one of the following:

• Use the ipconfig /all command.

• Use the netsh interface ip show wins command.

• Open the Network Connections folder, right-click a connection, and click Status. Click the Support tab, and then click Details.

DHCP Configuration of a WINS Client

You can assign WINS servers to DHCP clients by configuring the WINS/NBNS Servers DHCP option (option 44) on your DHCP server. If WINS servers are manually configured in the properties of the Internet Protocol (TCP/IP) component, the WINS client ignores the DHCP-based WINS server settings.

WINS clients running Windows Server 2003 or Windows XP automatically use the H-node NetBIOS node type when it is assigned IPv4 addresses of WINS servers. Because of this behavior, you do not also need to configure the 046 WINS/NBT Node Type DHCP option (option 46) with a value of 0x8 (H-node) on your DHCP server.

Manual Configuration of the WINS Client Using Network Connections

To manually configure the WINS client using Network Connections, you must obtain properties of the Internet Protocol (TCP/IP) component for your LAN connection. You can then manually configure the IPv4 addresses of WINS servers in two ways:

• Primary and alternate WINS server addresses for the alternate configuration for the connection

• Advanced TCP/IP properties

If you have specified an alternate configuration, you can also specify the IPv4 addresses of a primary and an alternate WINS server. Figure 12-1 shows an example of configuring a primary WINS server on the Alternate Configuration tab.

Figure 12-1 Primary and alternate WINS servers on the Alternate Configuration tab

To manually configure IPv4 addresses of WINS servers or to configure additional settings on a WINS client, open the properties dialog box for the Internet Protocol (TCP/IP) component, click Advanced on the General tab, and then click the WINS tab. Figure 12-2 shows an example.

Figure 12-2 The WINS tab from the advanced configuration of the Internet Protocol (TCP/IP) component

On the WINS tab, you can configure an ordered list of WINS servers that the computer queries. The WINS servers configured in WINS addresses, in order of use override the WINS server addresses received through DHCP.

Manual Configuration of the WINS Client Using Netsh

You can also configure the IPv4 addresses of WINS servers from the command line using the Netsh tool and the following command:

netsh interface ip set wins [name=]ConnectionName [source=]dhcp|static [addr=]IPv4Address|none

The netsh interface ip set wins command parameters are as follows:

• ConnectionName is the name of the connection as it appears in the Network Connections folder.

• source is either dhcp, which sets DHCP as the source for configuring WINS servers for the specific connection, or static, which sets the source for configuring WINS servers to the WINS tab in the advanced properties of the Internet Protocol (TCP/IP) component.

• IPv4Address is either an IPv4 address for a WINS server or none, which clears the list of WINS servers.

To configure a remote computer, use the –r RemoteComputer parameter as the last parameter in the command line. You can specify RemoteComputer with either a computer name or an IPv4 address.

Configuration of the WINS Client for Remote Access Clients

Remote access clients (using either dial-up access or a virtual private network connection) obtain the initial configuration of a primary and an alternate WINS server during the negotiation of the Point-to-Point Protocol (PPP) connection. RFC 1877 defines the Internet Protocol Control Protocol (IPCP) Primary NBNS Server Address and Secondary NBNS Server Address options. Computers running Windows XP or Windows Server 2003 also use a DHCPInform message to obtain an updated list of WINS servers. If a remote access server running Windows Server 2003 is correctly configured with the DHCP Relay Agent routing protocol component, the remote access server forwards the DHCPInform message to a DHCP server and forwards the response (a DHCPAck message) back to the remote access client.

If the remote access client receives a response to the DHCPInform message, the WINS servers in the DHCPAck message replace the WINS servers configured using IPCP.

The WINS Server Service

The WINS Server service in Windows Server 2003 supports the following features:

• An RFC-compliant NBNS

• Static mapping maintenance

  You can manually add entries to the WINS server database for the NetBIOS names of non-WINS clients.

• WINS server replication

  To ensure that NetBT nodes can resolve any NetBIOS name on the network by querying any WINS server, the WINS Server service supports database replication between WINS servers.

Installing the WINS Server Service

You can install the WINS Server service for Windows Server 2003 in the following ways:

• As a Windows component using the Add or Remove Programs item in Control Panel.

• With the Manage Your Server Wizard.

To install the WINS Server service with the Add or Remove Programs item in Control Panel, use the following steps:

1. Click Start, click Control Panel, double-click Add or Remove Programs, and then click Add/Remove Windows Components.

2. In Components, select the Networking Services check box, and then click Details.

3. In Subcomponents of Networking Services, select the Windows Internet Name Service (WINS) check box, click OK, and then click Next.

4. If prompted, in Copy files from, type the full path to the installation files for Windows Server 2003, and then click OK.

To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure.

To configure the WINS Server service, you configure the properties for the WINS server, static mappings, and replication.

Properties of the WINS Server

To modify the properties of a WINS server, open the WINS snap-in, right-click the name of the server in the tree, and then click Properties. Figure 12-3 shows an example of the resulting properties dialog box.

Figure 12-3 The properties dialog box for a WINS server

From this dialog box, you can configure properties on the following tabs:

• General You can specify how often to refresh the WINS statistics that appear in the Active Registrations node in the WINS snap-in, what the path to the WINS backup database is, and whether to backup the WINS database when the WINS Server service is shut down.

• Intervals You can specify various WINS server timers that Table 12-1 lists.

• Database Verification You can enable the periodic checking of database consistency to help maintain database integrity among WINS servers in a large network.

• Advanced You can enable the logging of detailed events to the system event log and enable and configure burst handling to distribute peak loads during WINS client registration or renewal. You can also specify the path for the WINS database, the starting version ID number (used to track changes in the local WINS database), and whether to allow NetBIOS names that are compatible with Microsoft LAN Manager.

Table 12-1 WINS server timers

Configuration option

Description

Renewal Interval

Specifies how often a client must reregister its name. This is the TTL for the NetBIOS name registration or renewal. The default value is six days.

Extinction Interval

Specifies the interval between when a database entry is marked as released and when it is marked as extinct. The default depends on the renewal interval and, if the WINS server has replication partners, on the maximum replication time interval. You cannot specify an interval that is longer than six days.

Extinction Timeout

Specifies the interval between when an entry is marked extinct and when the entry is removed from the database. The default depends on the renewal interval and, if the WINS server has replication partners, on the maximum replication time interval. The default value is six days.

Verification Interval

Specifies the interval after which the WINS server must verify whether old names that it does not own are still active. The default depends on the extinction interval. You cannot specify an interval that is longer than 24 days.

Static Entries for Non-WINS Clients

If a WINS client tries to connect to a non-WINS client on a remote subnet, the name of the non-WINS client cannot be resolved because it is not registered with the WINS server. On a network that has NetBT nodes that do not support WINS (non-WINS clients), you can configure static mappings of the NetBIOS names used by each non-WINS client to its IPv4 address. By configuring these mappings in a WINS server database, you ensure that a WINS client can resolve NetBIOS names of non-WINS clients without having to maintain a local or central Lmhosts file.

To configure a static mapping, do the following:

1. Open the WINS snap-in, open a server name in the tree, right-click Active Registrations, and then click New Static Mappings.

2. In the New Static Mapping dialog box, type the computer name of the non-WINS client in Computer name.

3. In NetBIOS scope, type the NetBIOS scope ID for the computer name if needed. The use of a NetBIOS scope ID is not recommended. For more information about NetBIOS scope IDs, see Chapter 11, "NetBIOS over TCP/IP."

4. In Type, click the entry type to indicate whether the name is a unique name or a kind of group with a special name, as described in Table 12-2.

5. In IP address, type the IPv4 address of the non-WINS client.

6. Click OK.

The mapping is immediately added as an entry in the WINS database.

Table 12-2 Static WINS mapping type options

Type option

Description

Unique

A unique name maps to a single IPv4 address.

Group

Also referred to as a normal group. When adding an entry to a group by using the WINS snap-in, you must type the computer name and IPv4 address. However, the WINS database does not store the IPv4 addresses of individual members of a group. Because the member addresses are not stored, you can add as many members as you want to a group. Clients send broadcast name packets to communicate with group members.

Domain Name

A NetBIOS name-to-IPv4 address mapping that has 0x1C as the 16th byte of the NetBIOS name. A domain name is a NetBIOS Internet group that stores up to 25 addresses for group members. For registrations after the 25th address, WINS overwrites a replicated address or, if none exist, WINS overwrites the oldest registration.

Internet Group

Internet groups are user-defined groups that enable you to group resources, such as printers, for easy reference. An Internet group can store up to 25 addresses for members. A group member that was added by a WINS client, however, does not replace a group member added by using the WINS snap-in or by importing an Lmhosts file.

Multihomed

A unique name that can have more than one address. This type of entry is used for a computer with multiple network adapters or assigned IP addresses (multihomed computers). You can register up to 25 addresses as multihomed. For registrations after the 25th address, WINS overwrites a replicated address or, if none exist, WINS overwrites the oldest registration.

Figure 12-4 shows an example of a static WINS mapping.

Figure 12-4 An example of a WINS static mapping

Database Replication Between WINS Servers

You can configure all WINS servers on a network to fully replicate their database entries with other WINS servers. This functionality ensures that a name registered with one WINS server is eventually replicated to all other WINS servers and allows any WINS client, regardless of which WINS server it is configured with, to resolve any valid NetBIOS name on the network. Database replication can occur whenever the WINS database changes, including when a NetBIOS name is released.

Replicating databases allows a WINS server to resolve NetBIOS names that have been registered with other WINS servers. For example, if Host A registered with WINS Server 1 and Host B registered with WINS Server 2, NetBIOS applications on Host A and Host B cannot communicate unless WINS Server 1 and WINS Server 2 replicate their databases to each other.

To replicate database entries between a pair of WINS servers, you must configure each WINS server as a pull partner, a push partner, or both with the other WINS server.

• A push partner is a WINS server that sends a message to its pull partners, notifying them that it has new WINS database entries. When a WINS server’s pull partner responds to the message with a replication request, the WINS server sends (pushes) copies of its new WINS database entries (also known as replicas) to the requesting pull partner.

• A pull partner is a WINS server that pulls WINS database entries from its push partners by requesting any new WINS database entries that the push partners have. The pull partner requests the new WINS database entries that have a higher version number than the last entry the pull partner received during the most recent replication.

Figure 12-5 shows an example replication configuration between WINS servers in Sydney and Seattle and the resulting information flow.

Figure 12-5 Example push-and-pull partner configuration and resulting information flow

Although you configure push and pull partners separately, the typical configuration is to have two WINS servers exchange information in both directions. In this case, both WINS servers will be push and pull partners with each other.

WINS servers replicate only any new entries in their databases. Servers do not replicate their entire WINS databases each time replication occurs.

Push and Pull Operations

The initiation of information being exchanged between two WINS servers can happen through either a push operation or a pull operation. In a push operation, a WINS server notifies its pull partners that it has new entries that it wants to send. The WINS server sends out a directed “Have new entries” notification to all pull partners. The pull partners respond with a “Send new entries” notification. The originating WINS server then sends the new entries.

To initiate a push operation, the WINS Server service relies on a push trigger specified during the configuration of WINS replication. A push trigger is based on a threshold of a certain number of entries that have changed, regardless of the time it takes to reach the threshold.

Figure 12-6 shows the push operation.

Figure 12-6 The push operation

Using the example in Figure 12-6, the Sydney WINS server has been configured with a push trigger of 1000 entries. When 1000 entries in the Sydney WINS database have changed, it initiates a push operation with the Seattle WINS server.

In a pull operation, pull partners send a “Send new entries” notification to their push partners. The push partners then respond with all the new entries. To initiate a pull operation, the WINS Server service relies on a pull trigger specified during the configuration of WINS replication. A pull trigger is based on scheduled times, regardless of the number of entries to be sent.

Figure 12-7 shows the pull operation.

Figure 12-7 The pull operation

In the example in Figure 12-7, the Seattle WINS server has been configured with a pull trigger of every day at 12:00 AM. At 12:00 AM each day, the Seattle WINS server initiates a pull operation with the Sydney WINS server.

For both push and pull operations, the data flows from the push partner to the pull partner. The push partner always pushes the actual replicated entries to the pull partner. The main difference between push and pull operations is the nature of the trigger (number of changed entries or a scheduled time) and which replication partner sends the first notification.

Configuring a WINS Server as a Push or Pull Partner

Determining whether to configure a WINS server as a pull partner or a push partner depends on the network environment. Keep these rules in mind when you configure WINS server replication:

• Configure pull replication between sites, especially across slow links, because you can configure pull replication to occur at specific intervals.

• Configure push replication when servers are connected by fast links, because push replication occurs when the configured number of updated WINS database entries is reached.

Figure 12-8 shows an example of WINS server replication.

Figure 12-8 Example of a WINS server replication configuration

In this example:

• All WINS servers at each site use push replication to push their new database entries to a single server at their site.

• The servers that receive the push replication use pull replication between each other because the network link between Sydney and Seattle is relatively slow. Replication should occur when the link is the least busy, such as late at night.

Configuring Database Replication

To add a replication partner for a WINS server and to configure replication options, do the following:

1. Open the WINS snap-in, and then open the appropriate server in the tree.

2. Right-click Replication Partners, and then click New Replication Partner.

3. In New Replication Partner, type the name or IPv4 address of the WINS server to add as a replication partner.

4. In the details pane, double-click the newly added server.

5. In the ServerName Properties dialog box, click the Advanced tab.

6. Configure the replication partner type and the pull and push replication settings as needed, and then click OK.

Figure 12-9 shows the Advanced tab for the properties of a WINS replication partner.

Figure 12-9 The Advanced tab for the properties of a WINS replication partner

Replication occurs under the following conditions:

• During WINS Server service start-up.

  When a replication partner is configured, the WINS Server service, by default, automatically performs pull replication each time it is started. You can also configure the service to perform push replication each time it is started.

• At a configured time or interval, such as every five hours (pull trigger).

• When a WINS server reaches a configured threshold for the number of registrations and changes to the WINS database (push trigger).

  When the server reaches the threshold, it notifies all of its pull partners, which request the new entries.

• When you manually initiate replication using the WINS snap-in.

  To initiate replication with all replication partners, right-click the Replication Partners node of the appropriate server in the WINS snap-in, and click Replicate now. To initiate replication with a specific replication partner, right-click the partner in the details pane and click either Start push replication or Start pull replication.

• When you manually initiate replication using the netsh wins server init replicate command.

WINS Automatic Replication Partners

If your IPv4 network supports multicast forwarding and routing, you can configure the WINS Server service to automatically find other WINS servers on the network by sending WINS autoconfiguration messages to the multicast IPv4 address 224.0.1.24. When enabled, this multicasting occurs by default every 40 minutes. Any WINS servers found on the network are automatically configured as push and pull replication partners, with pull replication set to occur every two hours. If your IPv4 network does not support multicast forwarding and routing, the WINS server will find only other WINS servers on its local subnet.

Automatic replication is disabled by default. To enable this feature, select the Enable Automatic Partner Configuration check box on the Advanced tab for the properties of the Replication Partners node in the WINS snap-in. On the Advanced tab, you can also configure the interval to check for new partners and the TTL for the multicast packets sent, which determines how far the multicast packets can travel before being discarded by routers.

The WINS Proxy

A WINS proxy is a WINS client computer that is configured to act on behalf of other NetBT computers that are not WINS clients. WINS proxies help resolve NetBIOS name queries from non-WINS clients. By default, most non-WINS clients send broadcasts to register their NetBIOS names on the network and to resolve NetBIOS name queries. A WINS proxy listens to broadcast NetBIOS name queries sent on the subnet, queries a WINS server, and replies to the NetBIOS name query.

WINS proxies are useful or necessary only on subnets that contain NetBIOS broadcast-only (or B-node) clients. For most Windows-based networks, WINS-capable clients are common and WINS proxies are typically not needed.

You can use WINS proxies in the following ways:

• When a non-WINS client registers a unique name, the WINS proxy checks the name against its configured WINS server. If the unique name exists in the WINS server database, the WINS proxy sends a negative Name Registration Response message back to the non-WINS client that is attempting to register the name.

• When a non-WINS client releases a NetBIOS name, the WINS proxy deletes the name from its NetBIOS name cache.

• When a non-WINS client sends a broadcast name query, the WINS proxy attempts to resolve the name either by using information contained in its NetBIOS name cache or by sending its own NetBIOS Name Query Request message to its WINS server.

How WINS Proxies Resolve Names

Figure 12-10 shows how a WINS proxy resolves a NetBIOS name requested by a non-WINS client.

Figure 12-10 How a WINS proxy resolves a NetBIOS name for a non-WINS client

The WINS proxy (Host A) uses the following steps to resolve a NetBIOS name for the non-WINS computer (Host B):

1. Host B broadcasts a NetBIOS Name Query Request message on the local subnet.

2. Host A receives the broadcast message and checks its NetBIOS name cache for an entry that matches the NetBIOS name specified in the NetBIOS Name Query Request message.

3. If Host A has a matching NetBIOS name-to-IPv4 address mapping in its NetBIOS name cache, Host A returns the IPv4 address to Host B using a positive NetBIOS Name Query Response message. If not, Host A sends a unicast NetBIOS Name Query Request message to its WINS server for the name that Host B requested.

4. If the WINS server can resolve the NetBIOS name, it sends a positive NetBIOS Name Query Response message back to Host A.

5. Host A receives the positive NetBIOS Name Query Response message, adds this mapping to its NetBIOS name cache, and then sends a unicast positive NetBIOS Name Query Response message to Host B.

If the WINS server sends a negative NetBIOS Name Query Response message to Host A, Host A sends no messages to Host B.

WINS Proxies and Name Registration

When a non-WINS client broadcasts a NetBIOS Name Registration Request message for a unique name, the WINS proxy sends a NetBIOS Name Query Request message to its configured WINS server to verify that the name has not already been registered with WINS. If the WINS server sends a positive NetBIOS Name Query Response message to the WINS proxy, the proxy sends a negative NetBIOS Name Registration Response message to the non-WINS client. If the WINS server sends a negative NetBIOS Name Query Response message to the WINS proxy, the proxy does not respond to the non-WINS client.

Configuration of a WINS Proxy

To enable a computer running Windows Server 2003 or Windows XP as a WINS proxy, set the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NetBT\Parameters\EnableProxy registry value to 1 (REG_DWORD), and then restart the TCP/IP NetBIOS Helper service.

Note

Note Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

To provide fault tolerance if a WINS proxy becomes unavailable, you should use two WINS proxies for each subnet that contains non-WINS clients.

Chapter Summary

The chapter includes the following pieces of key information:

• WINS is the Windows implementation of a NetBIOS name server, which provides a database for registering and querying dynamic mappings of NetBIOS names to IPv4 addresses used on your network.

• When a WINS client starts, it registers its NetBIOS names with its configured WINS server. A WINS client renews the registration of its NetBIOS names on an ongoing basis.

• WINS clients send their NetBIOS name queries to their configured WINS servers for NetBIOS name resolution.

• When a NetBIOS application on a WINS client is shut down, the WINS client releases the names registered with its configured WINS server.

• You can configure the WINS client for Windows Server 2003 and Windows XP by DHCP, through Network Connections, using the Netsh tool, and during the establishment of a PPP connection.

• The WINS Server service for Windows Server 2003 supports static mappings for non-WINS clients and WINS database replication with other WINS servers.

• A pull partner is a WINS server that pulls or requests replication of updated WINS database entries from other WINS servers (those configured to use it as a push partner) at a configured interval. Pull partners request entries with a higher version ID than that of the last entry received from its configured partner.

• A push partner is a WINS server that pushes or notifies other WINS servers (those configured to use it as a pull partner) of the need to replicate their database entries when a specified number of entries have changed.

• A WINS proxy is a WINS client computer configured to act on behalf of non-WINS clients. WINS proxies help detect duplicate names and resolve NetBIOS name queries for NetBT computers.

Chapter Glossary

DNS – See Domain Name System (DNS).

DNS client resolver cache – A RAM-based table that contains both the entries in the Hosts file and the results of recent DNS name queries.

DNS server – A server that maintains a database of mappings of DNS domain names to various types of data, such as IP addresses.

Domain Name System (DNS) – A hierarchical, distributed database that contains mappings of DNS domain names to various types of data, such as IP addresses. With DNS, users can specify computers and services by friendly names. DNS also enables the discovery of other information stored in its database.

Host name – The name of a computer or device on a network. Users specify computers on the network by their host names. For another computer to be found, its host name must either appear in the Hosts file or be known by a DNS server. For most computers running Windows, the host name and the computer name are the same.

Lmhosts file – A local text file that maps NetBIOS names to IP addresses for hosts that are located on remote subnets. For computers running Windows, this file is stored in the systemroot\System32\Drivers\Etc folder.

NBNS – See NetBIOS name server (NBNS).

NetBIOS – See network basic input/output system (NetBIOS).

NetBIOS name - A 16-byte name for an application that uses the network basic input/output system (NetBIOS).

NetBIOS name cache – A dynamically maintained table that stores recently resolved NetBIOS names and their associated IPv4 addresses.

NetBIOS name resolution – The process of resolving a NetBIOS name to an IPv4 address.

NetBIOS name server (NBNS) – A server that stores NetBIOS name-to-IPv4 address mappings and that resolves NetBIOS names for NetBIOS-enabled hosts. The WINS Server service is the Microsoft implementation of an NBNS.

NetBIOS node type – A designation of the specific way that NetBIOS nodes resolve NetBIOS names.

NetBIOS over TCP/IP (NetBT) – The implementation of the NetBIOS session protocol over TCP/IP (IPv4 only) that provides network name registration and verification, session establishment and termination, and data transfer services for reliable connection-oriented sessions and unreliable connectionless datagrams.

NetBT – See NetBIOS over TCP/IP (NetBT).

Network basic input/output system (NetBIOS) – A standard API for user applications to submit network I/O and control directives to underlying network protocol software and a protocol that functions at the Session layer.

pull partner – A WINS component that requests replication of updated WINS database entries from its push partner.

push partner – A WINS component that notifies its pull partner when updated WINS database entries are available for replication.

static mapping – A manually created entry in the database of a WINS server so that WINS clients can resolve the NetBIOS names of non-WINS clients.

Time-to-Live (TTL) – The amount of time that a NetBIOS name is stored on a WINS server. The TTL is configured on the WINS server.

TTL – See Time-to-Live (TTL).

Windows Internet Name Service (WINS) – The Microsoft implementation of an NBNS.

WINS – See Windows Internet Name Service (WINS).

WINS client – A component of the TCP/IP protocol for Windows Server 2003 or Windows XP that supports NetBIOS name operations using a WINS server.

WINS proxy – A WINS client computer configured to act on behalf of non-WINS clients. WINS proxies help detect duplicate NetBIOS names and resolve NetBIOS name queries for NetBT computers.

WINS server – A computer running the WINS Server service.