MS Windows NT Server 4.0 - WINS Architecture and Capacity Planning

On This Page

	Introduction
	Windows Internet Name Service (WINS)
	Functional Description
	Timers
	Replication
	New in NT 4.0
	Wins Database
	Designing a WINS Infrastructure
	Summary
	Appendix A: Terminology and NetBIOS Names
	Appendix B: NetBT (NetBIOS over TCP) Configuration Parameters
	Appendix C: Name Registration Trace

Introduction

NetBIOS Names

In order to understand the architecture of WINS, it is first necessary to understand the history behind it: that is, NetBIOS. NetBIOS started as a high-level programming language interface for PC-DOS applications to IBM PC-Network broadband LANs. Microsoft® used this NetBIOS interface for designing its networking components. NetBIOS names identify resources and are 16 characters in length. The NetBIOS name space is flat, meaning that names may only be used once within a network. These names are registered dynamically when computers boot, services start, or users log on. NetBIOS names can be registered as unique or as group names. Unique names have one address associated with a name.¹ Group names have more than one address mapped to a name.

Microsoft networking components, such as Windows NT® Workstation and Windows NT Server services, allow the first 15 characters of a NetBIOS name to be specified by the user or administrator, but reserve the 16th character (the suffix) of the NetBIOS name (00-FF hex) to indicate a resource type. (See Appendix A for a list of Microsoft reserved suffixes.) Some third-party applications use different suffixes.

NetBIOS-Based Networks

NetBIOS is a session-level interface that is used by applications to communicate over NetBIOS compatible transports. It is responsible for establishing logical names on the network, establishing sessions between two logical names on the network, and supporting reliable data transfer between computers that have established a session. NetBIOS has been around for more than a decade. Those protocols implemented under Microsoft networking components, including TCP/IP, have a NetBIOS interface or a mapping layer (NetBIOS over TCP/IP is called NetBT). This layer is provided to allow non-native NetBIOS components to fit into a NetBIOS environment. NetBIOS-based communications use NetBIOS names to uniquely identify resources and other nodes on the network.

Name resolution in a NetBIOS network has traditionally been broadcast-based. A Name Registration Request is broadcast and heard by all B- and M-nodes² on the local network. If, after the request is made, no objections are received, the application assumes that it has permission to use the name and issues a Name Overwrite Demand. If the name is already in use, a Negative Name Registration Response datagram is received from the node holding the name. In this case, the requesting application does not have permission to use the name.

There are several disadvantages to a broadcast-based name resolution system. First, nodes may interoperate with one another within a broadcast area but cannot interoperate across routers in a routed network. Second, such a system generates high-broadcast traffic, using significant network bandwidth. Third, every node within the broadcast area must examine each broadcast datagram. This consumes resources on every node.

Broadcast-based name resolution works fine within a small LAN environment. As the LAN grows and eventually merges into a WAN, however, this method is not effective. Large LANs will begin to experience bandwidth problems and once routers are introduced, the system becomes inoperable.

LMHOSTS File

The LMHOSTS file was introduced to assist with remote NetBIOS name resolution. The LMHOSTS file is a static file that maps NetBIOS names to IP addresses. This is similar to the hosts file in functionality; the only difference is that the hosts file is used for mapping host names (hierarchical names) to IP addresses. A NetBIOS name to IP address mapping in the LHHOSTS file allows that NetBIOS name to be resolved for a node that cannot respond to name query broadcasts.

Computers in a Microsoft-based network can resolve NetBIOS names in several different ways. If one method of resolution fails, they try the next method in a fixed order. In a broadcast-based network, the node first checks its remote name cache (the name will be in the cache if it has been used recently or preloaded from LMHOSTS) before broadcasting a name query. As a last resort it uses the LMHOSTS file to obtain the name to IP address mapping (for example, to resolve a name across a router in a broadcast-based network).

Enhancements to LMHOSTS file

The LMHOSTS file introduced initially had limitations and could not be used to support functions such as logon validation across subnets or designing a domain spanning subnets.

The above limitations were removed by introducing a few keywords in the Windows NT 3.1 LMHOSTS file. The keywords and their functionality are described below.

Using centralized LMHOSTS files

The keywords described in the previous section can be used to allow name resolution across small- to medium-sized, routed networks. With Microsoft TCP/IP, an LMHOSTS file can include other LMHOSTS files from local and remote computers using the #INCLUDE statement. Network administrators can maintain one or more global LMHOSTS files for inclusion in local LMHOSTS files. These global LMHOSTS files may be distributed to multiple servers for reliable access by using the existing Windows NT Replicator service.

#BEGIN_ALTERNATE and #END_ALTERNATE keywords can be used to provide a redundant list of servers maintaining copies of the same LMHOSTS file. This is known as a block inclusion, which allows multiple servers to be searched for a valid copy of a specific file. The following example shows the use of these keywords.

In this example, the servers testdc and testbdc are located on subnets remote from the computer that owns the file. During name resolution, the Windows NT system first includes this private file, then gets the global LMHOSTS file from one of two locations: testdc or testbdc.³The first available source for the global LMHOSTS satisfies the block inclusion and its entries are included. Any other servers in the list are not used.

Limitations of LMHOSTS file

Despite the many uses of the LMHOSTS file, there are some limitations to its design. Its greatest limitation is that it is a static file. Because the LMHOSTS file is static, entries have to be updated if the name or the IP address of the computer changes. An IP address might change for several reasons. Physically moving the computer between subnets would require a new IP address, as would a remote user dialing-in via the Remote Access Server (RAS) in Windows NT Server. A new address might also be acquired from a DHCP Server after lease expiration.

In addition to modifying the LMHOSTS file when such changes occur, these changes must be propagated to all the computers needing access to the resource whose name-to-IP address mapping has been modified. A centrally maintained LMHOSTS file can reduce the manual administration effort involved in propagating these mappings to the required computers. However, entering and changing the mappings is still a manual, labor intensive process. This is certainly preferable to keeping an LMHOSTS file on each computer and this solution can be feasible for a company with 10 to 20 servers. With more servers it becomes too complicated to maintain and is not a viable solution for a large enterprise.

This limitation of the LMHOSTS file has been exacerbated by the introduction of the Dynamic Host Configuration Protocol (DHCP). A DHCP server assigns IP addresses to nodes dynamically. It is nearly impossible to keep the LMHOSTS file updated when IP addresses are being assigned dynamically.

Top of page

Windows Internet Name Service (WINS)

WINS provides a distributed database for registering and querying dynamic NetBIOS names to IP address mapping in a routed network environment. It is the best choice for NetBIOS name resolution in such a routed network because it is designed to solve the problems that occur with name resolution in complex Internetworks.

The LMHOSTS file addressed only one disadvantage of broadcast based systems—it allowed resolution of names across routers. Since the system itself was still broadcast-based, the problems of broadcast traffic and load on local nodes were not solved. RFCs 1001/1002 address these problems. They define a protocol that allows name registration and resolution through unicast datagrams to NetBIOS Name Servers (NBNS). Because unicast datagrams are used, the system inherently works across routers. This eliminates the need for an LMHOSTS file, restoring the dynamic nature of NetBIOS name resolution. This, in turn, allows the system to work seamlessly with DHCP. For example, when dynamic addressing through DHCP results in new IP addresses for computers that move between subnets, the changes are automatically updated in the WINS database. Neither the user nor the network administrator needs to make manual accommodations for name resolution in such a case.

The WINS protocol is based on and is compatible with the protocols defined for NBNS in RFCs 1001/1002, so it is interoperable with other implementations of these RFCs. Another RFC-compliant implementation of the client can talk to the WINS server, and similarly, a Microsoft TCP/IP client can talk to other implementations of the NBNS server. However, because the WINS server-to-server replication protocol is not specified in the standard, the WINS server will not interoperate with other implementations of a NetBIOS Name Server. Data will not be replicated between the WINS server and the non-WINS NBNS. Therefore the WINS system as a whole will not converge and name resolution will not be guaranteed. WINS consists of two main components, the WINS server and WINS client.

WINS Server

WINS Client

Benefits of Using WINS

WINS/DNS Integration

In Windows NT 4.0 Microsoft's implementation of DNS is tightly integrated with WINS. This allows non-WINS clients to resolve NetBIOS names by querying a DNS server. Administrators can now remove any static entries for Microsoft-based clients in legacy DNS server zone files in favor of the dynamic WINS/DNS integration. For example, if a non-Microsoft-based client wants to get to a Web page on an HTTP server that is DHCP/WINS enabled, the client can query the DNS server, the DNS server can query WINS and the name can be resolved and returned to the client. Previous to the WINS integration, there was no way to reliably resolve the name because of the dynamic IP addressing. Please see the DNS and Microsoft Windows NT 4.0 white paper for details on the WINS/DNS integration.

Top of page

Functional Description

The following functional description specifically discusses name registration and resolution within a WINS system. Broadcast-based systems may be mentioned from time to time for comparison but they will not be discussed in detail.

In a WINS system, all names are registered with a WINS server. The names are stored in a database on the WINS server which answers requests for name-to-IP address resolution based on the entries in this database. Redundancy and load balancing are maintained by allowing more than one WINS server in the WINS system. These servers replicate their database entries among one another periodically in order to maintain a consistent view of the name space.

Each name has an entry in the database. It is owned by the WINS server it registered with and is a replica on all other WINS servers. Each entry has a state associated with it—the entry may be in the active, released, or extinct (also known as tombstone) state.⁴ Entries are also assigned a version ID. This number is used in the replication process and will be discussed later.

The WINS system also allows the registration of static names. This enables the administrator to register names for servers running operating systems that are not capable of dynamic name registration. WINS distinguishes between dynamic and static entries. Static names are treated somewhat differently than dynamic names (this will be discussed later).

Name Registration, Refresh, and Release

Name Registration

Name Registration is a request for the use of a name. The request may be for a unique (exclusive) or a group (shared) name. NetBIOS applications may register one or more names. Names are acquired dynamically through the registration procedure; each application contends with other applications in real time.

In order to request a name, the client node sends a Name Registration Request directly to the WINS server. The WINS server accepts or rejects the name registration by issuing a Positive or Negative Name Registration Response to the requesting node. The action taken by the WINS server depends on several factors; whether the name already exists in the database and in what state, whether it has the same or a different address, and whether the request is for a unique or group entry.

If the name does not exist in the database, it is accepted as a new registration. The name is entered with a new version ID, a Time Stamp of Current Time + Renewal Interval, and the WINS server's owner ID. A Positive Name Registration Response is sent. The Renewal Interval reflects the Time to Live (TTL) of the name. This is discussed in more detail in the sections on Name Refresh and Timers.

If the name is already entered in the database with the same IP address as that being requested, the action taken depends on state and ownership. If the state is active and the entry is owned by this WINS server, the Time Stamp will be updated and a Positive Name Registration Response will be sent. If the entry is in the released or tombstone state or if the entry is owned by another WINS server, the registration is treated as new. Time stamp, version ID, and ownership are all updated and a Positive Name Registration Response is sent.

In the case where the name exists in the WINS database but with a different IP address than that being requested, the WINS server must be careful to avoid duplicate names. If the database entry is in the released or tombstone state, the WINS server is free to assign that name. The request is treated as a new registration and a Positive Name Registration Response is sent. If, however, the entry is in the active state, the node holding the name must be challenged to see if it still exists on the network.⁵The WINS server first sends a Wait for Acknowledgment (WACK) Response to the requesting node, specifying a time in the TTL field that the client should be prepared to wait for a response. The WINS server then issues a Name Query Request to the node registered in the database. If the node still exists, it sends a Positive Name Query Response back to the WINS server. The WINS server, in turn, sends a Negative Name Registration Response back to the requesting node, rejecting the name registration. If a Positive Name Query Response is received, the WINS server will send the Name Query Request two additional times at approximately a 500 ms interval. After three attempts with no response, a Positive Name Registration Response is returned to the requesting node and the name is registered in the database as a new registration.

Name Refresh

Names held by WINS are given a Time to Live (TTL) or Renewal Interval during name registration. A name must be refreshed before this interval ends or it will be released. Names are refreshed by sending a Name Refresh Request to the WINS server.⁶ It is the responsibility of the client to refresh the name before the Renewal Interval expires. Windows NT clients refresh at 1/2 of the Renewal Interval. Other client stacks may refresh at different frequencies. The client node may increase the refresh rate if the WINS server does not respond to the refresh request. The WINS server treats a Name Refresh in the same way as a Name Registration.

Name Release

NetBIOS names may be explicitly or silently released. Names are explicitly released when a node shuts down gracefully. A silent release typically occurs when an end node fails or is powered off. The silent release is noted at the WINS server when a name is not refreshed within the Renewal Interval.

When a name is released, the database entry is marked as released and Time Stamped with Current Time + Extinction Interval. This information is not propagated to partner WINS servers. If the release is explicit, the WINS server makes itself the owner of the record if it is not already.

In Windows NT 4.0 the release is handled differently if the Owner ID is different (the client is releasing to a different WINS server than it registered with). In this case the entry is marked as extinct. The Time Stamp is Current Time + Extinction Interval + Extinction Time-out . This is done to avoid windows of inconsistencies between a secondary and primary WINS server. Without doing this, the name would stay released on one WINS server and active on the other for longer than desired periods because a released record would not be replicated again since it has already been replicated once. Changing the released record to the extinct state results in its replication and brings WINS databases into sync faster for this potentially troublesome case. For example, if a client's primary WINS server were unavailable when the client was shut down, the name release would be directed to the secondary WINS server. If the primary WINS server were available again when the client rebooted, the client would register and continue to refresh with the primary WINS server which still believes the client to be in the active state. The secondary WINS server database would keep the client in the released state.

Conflicts detected during registration

When a client node registers or refreshes a name, that name may already exist in the WINS database. The action taken by the WINS server depends on what state the registered name is in. The name might be unique or a group name. It might be owned or replica, static or dynamic. It might be active, released, or extinct (tombstone). The IP address might be the same or different.

Two cases are always the same and very simple. Normal group entries and Static entries are never overwritten.⁷ The WINS server always returns a Negative Name Registration Response to a request for a name that is entered in the database as a group or static name. Special groups get additional members during a Special group registration. In this case if the record in conflict is in the released or tombstone state, the record registration will be treated as new.

This leaves us with unique dynamic entries.

If the IP addresses are the same, the WINS server will return a Positive Name Registration Response and take the following action:

If the IP addresses are different and the database record is released or tombstoned, the name registration will be treated as new. A Positive Name Registration Response will be sent and the entry updated to reflect the new time, ownership, new version ID, and active state.

If the database entry is in the active state with a different IP address, the WINS server must determine if the name with the old IP address still exists. A Name Query Request is sent to the old IP address. If the old address responds with a Positive Name Query Response, the WINS server, in turn, rejects the new registration with a Negative Name Registration Response. If the old address does not respond to the Name Query, the new registration is accepted.

See full-sized image.

Name Registration

In the previous diagram, let's assume that Client_B is a DHCP client. We will start our example on 1/18/96 at about 2:10 PM. The Renewal Interval is set at the default, which is four days. When we power on Client_B, the IP address, subnet mask, default gateway, primary (WINS_A), and secondary (WINS_B) WINS servers are received from the DHCP server. Client_B discovers the MAC address of the primary WINS server with an Address Resolution Protocol (ARP) request. A Name Registration Request is then sent by UDP datagram directly to WINS_A. Assume that, at this time, there is no entry for Client_B in the WINS_A database. WINS_A sends a Positive Name Registration Response to Client_B and a record for Client_B is entered in the WINS database. The Time Stamp is Current Time + Renewal Interval and the version ID is the value of the registration counter on WINS_A. The registration counter on WINS_A is then incremented by one. This entry will be replicated to WINS_B when the next Replication Interval timer expires (or when the update count, if specified when configuring a partner as a push partner for this WINS, is reached), if it is still in the active state at that time.⁸

In the Positive Name Registration Response, WINS_A sends a Time to Live (TTL). This is the Renewal Interval set by the administrator for WINS_A.

Name Refresh

At 1/2 Renewal Interval (Windows NT client), Client_B sends a Name Refresh Request to WINS_A. WINS_A returns a Positive Name Registration Response and updates the database record with a new Time Stamp.

The WINS server treats a Name Refresh Request exactly the same as a Name Registration Request. If Client_B does not send a Name Refresh Request to WINS_A within the Renewal Interval, WINS_A will put Client_B in the released state.

Name Release

The user shuts down his machine for the evening at 5:35 PM on 1/18/96. When Client_B is shut down gracefully, it issues a Name Release Request to WINS_A. WINS_A responds with a Positive Name Release Response. The database record is updated by placing Client_B in the released state and updating the Time Stamp. The Time Stamp in this case is Current Time + Extinction Interval. The Extinction Interval in this case is four days. The version ID is not changed at this time because a record in the released state is never replicated.

If Client_B is not reregistered before the Extinction Interval expires, it will become extinct (or a tombstone)

Name Reregistration with the same WINS server

When the user reboots the next morning, 1/19/96, at 8:15 AM, Client_B will again send a Name Registration Request to WINS_A. This time, an entry for Client_B does exist in the WINS database. Because the entry is in the released state, WINS_A can issue a Positive Name Registration Response without a challenge (challenge will be discussed later). In the database, the entry is placed in the active state, the time is stamped with Current Time + Renewal Interval, and the version ID is given the value of the registration counter. Because of the new version ID, this entry will be replicated to other WINS_B when the next Replication Interval timer expires (or update count is reached).⁹

Name Reregistration with a different WINS server

See full-sized image.

In this example, let's say that Client_B is a laptop computer. At 12:30 PM on 1/19/96 the user shuts down Client_B (putting Client_B in the released state on WINS_A) and then goes to another building where Client_B is connected to a different subnet (at about 1:15 PM). When Client_B boots on this subnet, it receives WINS_B as its primary WINS server. Client_B sends a Name Registration Request to WINS_B. WINS_B already has an entry for Client_B that had been replicated from WINS_A.¹⁰

The existing entry shows WINS_A as the owner WINS server and has a different IP address than the current request.¹¹ In this case, WINS_B must determine if the name registered in its database still exists on the network. WINS_B sends a Wait for Acknowledgment (WACK) Response to the (new) Client_B with an estimated time necessary to complete the request. It then challenges the (old) Client_B by sending it a Name Query Request. If WINS_B were to receive a Positive Name Query Response from the (old) Client_B, it would send a Negative Name Registration Response to the (new) Client_B, denying the Name Registration. However, in this case, the (old) Client_B is no longer on the network (because it is a laptop that was moved). Therefore, WINS_B receives no response to its Name Query Request and may issue a Positive Name Registration Response to the (new) Client_B. The database entry is modified to indicate the new WINS owner and new IP address. It is Time Stamped with Current Time + Renewal Interval and the version ID is set to the registration counter from WINS_B.

Extinction process

To reduce network traffic, we do not want to replicate entries whenever a node is shut down. However, we also don't want the WINS database cluttered with entries for nodes that have been permanently removed. When Client_B is shut down (at 6:45 PM on 1/19/96), it is placed in the released state as discussed above and Time Stamped with Current Time + Extinction Interval.

During this period it remains in the released state and is not replicated. If, after the Extinction Interval, the name still has not been reregistered, the entry is placed in the extinct (or tombstone) state at scavenge time and the time is stamped with Current Time + Extinction Time-out. In this case, we will assume that the Extinction Time-out has been set to 24 hr. Scavenging happened that day at 7:05 PM.

At this point the version ID is also updated and the entry is replicated. The replica is also Time Stamped at the receiving WINS with Current Time + Extinction Time-out. If at the end of Extinction Time-out, the name is still not registered, it is removed from the WINS databases at scavenge time.

Name Query

Name Query transactions are initiated by end nodes to obtain the IP addresses of a NetBIOS name. The WINS server replies to queries with a list of IP addresses for each owner of the name (more than one address only if it is a Special Group or a multihomed name). The WINS server sends as many answers to the query as will fit into a UDP packet. Because Special Groups are limited to 25 names, all information will always fit into the UDP packet.

A Windows NT 3.5 computer only queried the secondary WINS server for NetBIOS name resolution when it did not receive a response from the primary WINS server. If a NetBIOS name was not found in the primary WINS database, Windows NT 3.5 did not search the secondary WINS server. The search order was changed in Windows NT 3.51. Now the secondary WINS server is queried when the Primary does not respond or when the requested name is not found in the primary WINS server database. This new search order also applies to Windows 95 and Windows for Workgroups 3.11 (using TCP/IP-32 for Windows for Workgroups version 3.11b and the updated redirector files).

See full-sized image.

Querying a WINS server directly

In the previous diagram, when Client_B wishes to communicate with Client_C, the name Client_C must be resolved to the IP address 128.11.33.104. Client_B first looks in its local name cache for the name-to-IP address mapping. If Client_B has used the name recently, it will still be available in the cache. If the remote name cache does not contain the mapping, Client_B sends a Name Query Request to WINS_A. If WINS_A finds the name in its database it sends a Positive Name Query Response to Client_B with the IP address of Client_C. If the name is not found in the database, WINS_A sends a Negative Name Query Response to Client_B. There are several reasons why the name Client_C might not be in the database on WINS_A.

After receiving the Negative Name Query Response, Client_B's actions depend on which TCP/IP stack it is running. If it is running Microsoft's TCP/IP stack, it will query its secondary WINS server. If the secondary WINS server also issues a Negative Name Query Response Client_B will then, assuming it is configured as an h-node client (see Appendix A), broadcast a Name Query Request. The request will fail in this case because Client_C is on a different network and the router will not forward the broadcast. Next Client_B will do a LMHOSTS and finally a DNS lookup to resolve the name.¹³

Proxy Servers

RFC 1001 recommends that b-nodes (see Appendix A) not be used in a routed network. However, in practice, b-nodes are sometimes used in routed networks. In some cases, there are reasons why these b-nodes cannot be removed or updated immediately. For this reason, Microsoft introduced proxy servers.

Proxy servers are nodes that listen for b-node name service functions (registration, release, query) and respond for those names that are not on the local network. Proxy servers communicate with the WINS server with directed datagrams to retrieve the information necessary to respond to these broadcasts.

Broadcast name registrations are not stored by the proxy, nor are they registered in the WINS database. They are simply checked against the WINS database (by sending a Name Query Request) to ensure that the names do not conflict with other names in the database. If the name exists in the WINS database, the proxy may send a Negative Name Registration Response to the b-node attempting to register the name. The action of sending a negative response is configurable. By default it is disabled. See EnableProxyRegCheck in Appendix A.

In response to a Name Release Request, the proxy simply deletes the name from its remote name cache.

When the proxy receives a name query it checks its remote name table. The proxy must be able to differentiate name queries for local names on the subnet and remote names elsewhere in the network. It compares the address of names it resolves to its own address using the subnet mask, and if the two match, then the proxy does not respond to the name query. This guarantees that the proxy will not respond to queries for names local to the subnet.

If the name is found in the remote name cache, a response is sent to the client. If the name cannot be found, the WINS server is queried and the name is entered into the remote name table in a "resolving" state. Should another query come in for the same name before the WINS server has responded, the proxy will not query the WINS server again. When the response is returned from the WINS server, the remote table entry is updated with the correct address and the state is changed to "resolved." When the next name query comes in for that name, a response is sent to the client. There is no provision in NetBIOS for a name server to "deliver" a name resolution to a client. A name is always resolved in response to a query, therefore the b-nodes used with the proxy should have configurable retry time-outs and number of retries in order to still be retrying the name query after the WINS server has responded to the proxy server.

In order to reduce duplicate traffic, it is recommended that only one or two proxy servers be active on a subnet.

Querying with Proxy Server

See full-sized image.

In the example shown above, we have a small broadcast-based LAN consisting of Client_A and Client_B connected to a larger network through a router. A NetBIOS application on Client_B wishes to communicate with Client_C. Normally, this would not be possible. However, by using a Windows NT Workstation-based client as a proxy server on the same LAN as Client_B, Client_B and Client_C can communicate.

Client_B broadcasts a Name Query Request to obtain the IP address of Client_C. Client_C does not receive the request because the router does not pass the broadcast. The proxy server sees a Name Query Request broadcast for a node on a different subnet and sends a Name Query Request directed datagram to WINS_B. WINS_B returns a Positive Name Query Response containing the IP address for Client_C to the proxy server where it is cached for future queries.

Secondary WINS Servers

Client nodes are configured with a primary and secondary WINS server. If the primary WINS server cannot be reached for any function (registration, refresh, release, query), the client will request that function from its secondary WINS server. The client will try periodically to switch back to its primary WINS server.

Top of page

Timers

There are four configurable timer values. Microsoft has chosen the defaults with care and in general they should not be modified. They are designed to keep network traffic and the load on WINS servers at a minimum. They represent the best tradeoff, considering the various configurations in which WINS servers may be deployed, between these goals and keeping the window, during which the databases remain out of synch, small. Considerations such as long weekends, avoidance of unnecessary replication traffic, ability to handle large number of clients quickly under worst case scenarios (for example all PCs come up during a short time interval), as well as tradeoffs between quick clutter removal and retaining entries to ensure replication have been factored into the determination of these intervals.

Renewal Interval

This is also known as the Name Refresh Time-out or the Time to Live (TTL). When a name is registered with the WINS server, the database entry is Time Stamped with Current Time + Renewal Interval. A client must refresh its name with the WINS server within this interval or the name will be released. When a name is released (either by timing out or the by the explicit release of the name by the client), no action is taken other than changing the entry to the released state and Time Stamping the entry with Current Time + Extinction Interval. This change is not replicated to other WINS servers. When a name is in the released state and a new registration comes in with a different address, the name can be immediately given to the new client without challenge because it is known that the old client is no longer using the name. The default Renewal Interval is four days (six days in Windows NT 4.0).

Extinction Interval

This is also known as the Name Age Time-out or the Tombstone Interval. This is the interval at which released names are changed to the extinct (or tombstone) state. At this time the entry is Time Stamped with Current Time + Extinction Time-out and the version ID of the entry is updated causing this information to be propagated to all WINS servers at the next replication time. When extinct (or tombstone) entries are created , they are Time Stamped with Current Time + Extinction Time-out at the pulling WINS server. The default Extinction Interval is based on renewal and replication times. This is typically four days in Windows NT 3.51 and six days in Windows NT 4.0.

Extinction Time-out

This is also known as Tombstone Time-out. Extinct (or tombstone) records that are older than Extinction Time-out are removed from the database. The default Extinction Time-out is based on a number of factors. This default is also typically four days in Windows NT 3.51 and six days in Windows NT 4.0.

Verify Interval

Replication should ensure that the databases stay synchronized. However, under certain abnormal conditions, names no longer in use could remain in the database. We refer to this as a database clutter. For example, if a tombstone record is removed before being replicated, the active state of the record in the replica databases would never change. This could happen if the replication partner was not reachable during the extinction time-out period.

When an active entry is replicated, it is Time Stamped with Current Time + Verify Interval on the pulling WINS server. If, at scavenge (see section on Scavenging for a defintion) time, records are found that are older than the Verify Interval, a query is sent to the WINS server that owns that name asking if the version ID is still valid. A negative response (invalid record) causes the record to be removed. A positive response (valid record) causes the Time Stamp to be updated. If the WINS server cannot be contacted, the entries are left until the next Verify Interval (or until the administrator triggers scavenging). No records are removed if the owning WINS server cannot be contacted. The default Verify Interval is twenty-four days.

Server Clocks

The replication and scavenging algorithms rely on a reasonable consistent system clock. Setting the system clock forward or backward will, of course, affect these algorithms. However, because the Time Stamps are always entered locally, the WINS servers do not need to be time synchronized. The time only has to be consistent on each individual server.

Note: The above timer parameters are not strictly static. The values configured by the administrator may be altered by WINS in some situations. The algorithms by which WINS alters these parameters may be changed at any time by the WINS developers and therefore can not be definitively documented. As an example only, the algorithm for determining these values was at one time (version 3.5) as follows:

Static Entries

Many nodes on a network, such as a server running the UNIX operating system, are not capable of registering a name with the WINS server. These names might be resolved from a LMHOSTS file or by querying a DNS server, but a better solution would be to enter the name to IP address mapping statically in the WINS server. This accomplishes two things. First, it allows nodes to resolve the name with a query to the WINS server without having to resort to secondary resolution methods. This results in faster name resolution. Second, it prevents the WINS server from allowing another node to dynamically register the name.

Static entries may be entered interactively or by importing an LMHOSTS file. They are never released and they are never overwritten by dynamic entries.¹⁴

Migrate On

The sole purpose of Migrate On is to ease the process of making a B-node an H-. P-, or M-node (WINS client). If set, the static nature of unique/mh names is compromised by WINS in that these records are now treated as pseudo-static. Pseudo-static means that a dynamic name registration will be allowed to overwrite a unique/mh static entry if the static's address(es) are different and prove to be wrong (the challenge mechanism is used to confirm this). If there were no concept of pseudo-static, the registrations would fail and the machine registering the names would not be able to come up properly.

The static nature of 1C groups is not compromised through Migrate On because these entries do not prevent any node from coming up. A static 1C entry can only be changed by an administrator. Dynamic name registrations that conflict with a static 1C name will return with success (to prevent name in conflict problem at the client) but the address in the registration will not be added to the member list in the WINS database.

Groups and Multihomed Names

In addition to unique entries, the WINS server allows groups and multihomed names to be registered. The WINS server recognizes two types of groups; normal groups and special groups.

Normal groups

A normal group name does not actually have an address associated with it. It is assumed to be valid on any subnet. The same group can be registered at more than one WINS server. The Time Stamp on the group entry reflects the time for the last registration or refresh received for that group. The whole group has a single time associated with it which indicates the last time a name registration or refresh for the name was received from a node on any subnet. On a name query for the group, WINS will return the limited broadcast address. The WINS client will then issue a subnet broadcast to resolve the name.

As the group names replicate from one WINS server to another, the name is simply created on servers that do not already have it since there is no address to propagate with the name. When a group is not refreshed, it is released and eventually becomes a tombstone. These states, however, have a slightly different meaning for groups than they do for unique entries. The WINS server continues to answer name queries for released and tombstone groups. Unique name registrations that clash with these are returned a negative response. These states for group entries may be thought of as pseudo states (pseudo-released and pseudo-tombstone). At Extinction Interval, the version ID is incremented which causes the state information to be replicated to other WINS servers.

Special groups

Special groups are also known as Internet groups. When a name registration is received for a special group, the actual address rather than the limited broadcast address, will be stored in the group. A Time Stamp and an Owner ID will be stored with each address entry in the group. This reflects the last registration/refresh received for that entry by the WINS server is designated by the Owner ID. When a name query is received for such a group, the IP addresses that haven't timed out will be returned. These groups, like normal groups, get replicated. Only active members of the group are replicated. In Windows NT Server 3.5x, there is only one special group. This is the <domain_name>[1Ch]. This name is registered for use by the domain controllers within a domain and may contain up to 25 IP addresses. When queried, the IP address of the Primary Domain Controller (assuming the domain [0x1B] name was registered) will be followed by up to 24 IP addresses of Backup Domain Controllers will be returned. If this is not a static name and it has fewer than 25 entries, names registering dynamically will be added to it. If the group already has 25 entries, the WINS server will remove a replicated entry so that the new member can be added. If all the entries are owned by the WINS server (no replicated entries), the oldest member will be removed so that the new member may be added. WINS does not distinguish between local and remote domain controllers. It stores the members in the order of most recently refreshed to least recently refreshed. The [1Ch] domain name is used by the backup domain controllers to locate the PDC and is used when pass-through authentication is needed to validate a logon request. A statically mapped Internet group name registers itself as this type.

Unfortunately, there is no way to view the IP addresses contained in an Internet group with the WINS Manager, unless the Internet group is statically mapped in the WINS database (The group can be viewed with the winscl.exe program in the Resource Kit). The IP address that is displayed for this registration is the IP address of the last WINS Client to register/renew the Internet group name. When a dynamic registration for an Internet group is received, the WINS client's address and Time Stamp are stored in the Internet group.

In Windows NT 4.0, user defined special groups other than <domain_name>[1Ch] are allowed. An administrator can specify special group names of his/her own choice. There are two ways of doing this. One is through the WINS manager tool. The other is through the LMHOSTS file.

WINS Manager

In the "Add Mappings" window, enter a name and check the "Internet Group" radio button.

LMHOSTS

Specify the name just as you would a domain name except that the keyword is SG instead of DOM. An example is given below

128.11.80.182   nodea #SG:mygroup

The above results in a special group - mygroup<0x20>, being created with one member 128.11.80.182. Three unique records nodea<0x3), nodea<0x20>, nodea<0x0> are also created.

The above is similar to what happens when you have the following:

128.11.80.182   nodea #DOM:mygroup

In this case, a domain mygroup<0x1C) is created with 157.55.80.182 as a member. three unique entries nodea<0x3), nodea<0x20>, nodea<0x0> are also created.

Specifying the name of a special group without specifying an address, can be done by giving the name of the group prefixed by #SG: #SG:mygroup. You can not do this for domains. That is, you can not have #DOM:mygroup to specify mygroup<0x1C> as a domain.

Addresses entered via the LMHOSTS file or via WINSADMN become permanent addresses in the special group and can be removed only through WINS Manager. In the case of special groups, excluding domains, members can get added as a result of dynamic group registrations. A dynamic member will however never replace a permanent member added via LMHOSTS or WINS manager.

Multihomed names

A multihomed node can register one or more addresses by sending them in a name registration packet with the opcode set to a Microsoft defined value. This opcode is not prescribed by RFC 1001/1002 since these RFCs do not discuss multihomed clients. The opcode is one of the unused values in the 4 bit opcode field.

A multihomed name in the database of a WINS can have one or more addresses in it. When a refresh is received for a multihomed name and the address in the refresh packet is found in the multihomed name's record, the member address's Time Stamp is updated. The Time Stamp of the record is also updated so that it continues to reflect the most recent refresh/registration received for one or more members of the name. When the member address refreshed is found to be owned by another WINS, its ownership is changed to that of the local WINS and the version stamp of the record is updated.

When a registration is received for a multihomed name or when a refresh comes in with an address not in the list of addresses of the multihomed name in the database, each address in the list other than the address received in the registration/ refresh is challenged in sequence until a positive response is received or until all addresses have been exhausted. If a positive response is received, the list of one or more addresses sent in the response is examined to determine if the list contains the address in the registration/refresh. If it does, a Positive Name Registration Response is returned to the client and the record in the database is appropriately updated—those addresses not there are inserted, those there have their Time Stamp and Owner ID updated. If however the list of addresses in the response is not a superset of the list found for the multihomed name, a Negative Name Registration response is returned to the client and the record in the database is left untouched. If all addresses in the list are exhausted without getting a positive response (or no response), the record in the database is overwritten with the new mapping and a positive response is returned to the client.

Multihomed name initialization through the LMHOSTS file

In Windows NT 4.0 it is possible to initialize multihomed names in the LMHOSTS file. The format of giving the name is exactly the same as for a unique name except that the keywords #MH must be put after the name as is shown below.

128.11.80.182     nodea_ptm #MH
128.11.80.185     nodea_ptm #MH

The above example creates MH records nodea_ptm<0x0>, nodea_ptm<0x20>, nodea_ptm<0x3> with two addresses.

128.11.80.181     nodea_ptm #MH  #DOM:REDMOND
128.11.80.185     nodea_ptm #MH  #DOM:REDMOND

The example above creates MH records nodea_ptm<0x0>, nodea_ptm<0x20>, nodea_ptm<0x3> with two addresses and creates a domain REDMOND<0x1c> with the two addresses as members.

128.11.80.181     nodea_ptm #MH  #SG:MYGROUP
128.11.80.185     nodea_ptm #MH  #SG:MYGROUP

The above examplecreates MH records nodea_ptm<0x0>, nodea_ptm<0x20>, nodea_ptm<0x3> with two addresses. Creates a special group MYGROUP with the two addresses as members.

Top of page

Replication

Multiple WINS servers increase availability and balance the load among servers. The WINS system must maintain a stable name space. If a node has registered a name-to-address mapping with one WINS server, that mapping must be available reliably from any WINS server. This is accomplished through replication of the WINS databases among WINS servers. Replication is carried out among partners, rather than each server replicating to all other servers. Each WINS server must be configured with at least one other WINS server as a replication partner. This ensures that a name registered with one WINS server is eventually replicated to all other WINS servers. Replication of registered names to all WINS servers is necessary to allow resolution of names registered to different servers. All name-to-address mapping changes will converge within the Convergence Time of the entire WINS system. A name release will not propagate as fast as a name registration. This is because it is common for names to be released and then reused with the same mapping as PCs are rebooted or turned off for the evening or the weekend. Replicating each of these releases would unnecessarily increase the network load of replication. If a client node crashes or is simply powered off, the registered name is not cleanly released by a NetBIOS Name Release datagram. Therefore, the presence of a name-to-address record in the WINS database does not necessarily mean that the node is running. It only means that at some reasonable time in the past, that node claimed the IP address.

A replication partner can be a pull or a push partner. A pull partner is a WINS server that requests new WINS database entries (replicas) from its partner. This is done by requesting entries with a higher version ID than the last entry received from a partner during the last replication. The pull occurs at configured time intervals or in response to an update notification from a push partner. A push partner is a WINS server that sends update notification messages (If configured to do so by setting the update count or by turning on replicate up on address change. When it is not configured in this way, the WINS server will propagate triggers received from a partner to all other partners.to its partner when its WINS database has changed. The partner then may pull these changed entries. The update notification occurs after a configurable number of changes to the WINS database.

When replication is configured between two WINS servers, it is recommended that both servers be push and pull partners of the other. The Primary and Secondary WINS server of any client must have a push and pull relationship with each other. In general, NetBIOS names are presented as a flat namespace. Attempts to impose a hierarchy on this namespace through one-way replication schemes result in problems with name uniqueness and resolution and cannot be recommended.

Overview of the Replication Process

See full-sized image.

The figure above shows an extremely large WINS implementation—servicing in excess of 100,000 nodes. In a configuration with so many WINS servers it is tempting to create many push/pull relationships for redundancy. This can lead to a system that, while functional, is overly complex and difficult to understand and troubleshoot. We have imposed some order on the above configuration by using a hub structure. Four major hubs are located in Seattle, San Francisco, Chicago, and Los Angeles. These hubs serve as secondary WINS servers for their regions while connecting the four geographic locations. All primary WINS servers are configured as Push/Pull partners with the hubs and the hubs are configured as push/pull partners with other hubs. Let's assume the primary WINS servers replicate with the hubs every 15 minutes. and the hub to hub Replication Interval is 30 minutes. The convergence time of the WINS system is the time it takes for a node registration to be replicated to all WINS servers. In this case the longest time would be from a Seattle primary to a Chicago primary. The convergence time is 15 +30 +30 +15 minutes or 1.5 hours. Of course we've ignored the fact that some of our WINS servers are connected across slow links. It is probably not necessary for the servers in Paris or Berlin to replicate every 15 minutes. We might configure them to replicate every two hours or even every 24 hours depending on the volatility of the WINS system. We will discuss more about replication across slow links in a later section. We mentioned redundancy earlier. In our configuration there is some, but not a lot of, redundancy. If the link between Seattle and Los Angeles is down, replication will still occur through San Francisco. But what happens if the Seattle hub itself goes down? In this case, the Seattle area will no longer be able to replicate with the rest of the WINS system. Network connectivity, however, is still functional and all WINS servers contain the entire WINS database. Name resolution will continue to function normally. All that is lost are changes to the WINS system since the Seattle hub went down. A Seattle user won't be able to resolve the name of a file server in Chicago that came on-line while the Seattle hub was down. Once the hub is returned to service, all changes will be replicated.

The following example shows replication between two WINS servers in more detail.

Detailed Replication Example

See full-sized image.

Let's look at the database tables for WINS_A and WINS_B on January 1, 1996. All four clients were powered on this morning between 8:00 AM and 8:15 AM. Client_2 has just been shut down. The following parameters are set in WINS_A and WINS_B:

Before replication, WINS_A has the following two entries:

WINS_B has the following two entries:

Clients_ 1, 3, and 4 were Time Stamped with Current Time + Renewal Interval at the Time they booted and Client_2 was Time Stamped with Current Time + Extinction Interval when it was released. The version IDs indicate the value of the registration counter at the time of registration. The registration counter is incremented by one each time it is used to generate a new version ID in the database. Each WINS server has its own registration counter. The version ID jumps from 4B3 for Client_1 to 4C2 for Client_2. This indicates that fourteen registrations (or extinctions or release to active transitions) took place between the registration of Client_1 and Client_2.

Replication takes place at 8:30:45 by WINS_A's clock. WINS_B's clock is 8:31:15 at this time. Of course the replication won't all take place in the same second, but we'll use these times to generate the Time Stamps. Note that replication does not mean both pull at the same time. Each will pull according to its individual pull schedule. After replication, the WINS_A database will look like the following:

After replication, the WINS_B database will look like the following:

Client_1 has been replicated to WINS_B and Client_3 and Client_4 have been replicated to WINS_A. The replicas have all kept their original owner and version ID and have been Time Stamped with Current Time + Verify Interval. ¹⁵ Client_2 has not been replicated because it is in the released state. This is a little unusual (but possible) because Client_2 shut down before its first replication. If Client_2 had not been shut down until after the replication, WINS_B would have a replica of Client_2 in the active state. This replica would remain in the active state even after Client_2 released because the change in state would not be replicated.

If Client_2 remains shut down for the Extinction Interval) it will be placed in the extinct (or tombstone) state. At the first scavenging after January 5, 1996 8:23:43 AM(assuming an Extinction Interval of four days), WINS_A's will look like the following:

Notice that Client_2 has entered the tombstone state and that both the Time Stamp and the version ID have changed. The Time Stamp is now Current Time + Extinction Time-out and the new version ID will cause this entry to be replicated at the next replication. Notice also that Client_1 has a new Time Stamp while retaining its version ID. It has continued to be renewed throughout the last four days. The renewal rate is dependent on the client stack.

After replication at 10:00:23 AM WINS_B's database will look like the following (notice that Client_3 and 4 were renewed):

If Client_2 remains down for one more day (the Extinction Time-out) it will be removed from the databases at scavenge time.

The WINS_A database will look like the following:

The WINS_B database will look like the following:

During the first scavenging after January 25, 1996 8:30 AM WINS_A will verify with WINS_B that Client_3 and Client_4 are still valid active names. WINS_B will do the same for Client_1 with WINS_A.

Pulling WINS Database Entries

See full-sized image.

The WINS server maintains an IP address - Owner ID mapping table in its local database. This table gives the mappings between the IP addresses and Owner IDs of WINS servers that have entries in its local database. A sample IP address - Owner ID mapping table for WINS-A is given below

During WINS initialization the WINS server scans the Name to IP address mapping table to determine the maximum version ID corresponding to each owner registered in its database. It creates an in-memory table (this table is never committed to the database), called the Push Partner -Version # mapping table and initializes it with the information retrieved above. This table has an entry for each Push partner. Each entry contains the maximum version ID found for all owners in the local database of the Push partner. For example, if the local WINS server has an Owner ID of 0, then given the above IP-Address to Owner ID mapping table, the Push Partner-Version # table might look like the one given below:

It shows that at the local database of the WINS server identified by Owner ID 0, there are entries owned by three WINS servers with Owner IDs of 0, 1, 2. The highest version numbers for entries are 100, 900, and 630, respectively.

The WINS server is now ready to determine whether it needs to update its database. It sends a message to each push partner it has asking it to respond back with the IP address-max version number records pertaining to its local database. As it hears back from each push partner, the WINS server fills and grows its own table. The table might take on more columns. For example, if WINS_B at IP address 128.11.24.8 (Owner ID 1) responds back with a record for WINS_D at IP address 128.11.26.4, a column for an Owner ID 3 is added to the local Push Partner -Version Number mapping table. This column is for the indirect push partner, WINS_D, at IP address 128.11.26.4. At the same time the mapping 128.11.26.4 - 3 is stored in the IP address-Owner ID table. The relevant cells in the new table are initialized. To illustrate by example, let us say that WINS_B at 128.11.24.8 responded back with the following three records:

128.11.24.8	 999
128.11.26.4	 700
128.11.23.7	 89

The local Push Partner - Version Number table would now become:

The IP address to Owner ID table would be grown by the following record

After all Push partners have responded, the IP address-Version # table should be fully filled up.

It is examined to determine which push partner has the latest data for each owner. A WINS server will always have the highest version ID for entries owned by it, however, all WINS servers might not be partners of the requesting pull partner. The starting version ID that is required to sync the local database is then determined and the push partner is requested to send the database records with version IDs equal or greater than this. The push partner will send all records with version numbers higher than that. If a push partner has the latest data for more than one owner, one single request may be sent to retrieve the records for all. Of course, in this simple example, who has the most current data for a database never changes. When WINS_A pulls data, WINS_B has the latest data for itself and WINS_D; WINS_C has the latest data for itself. In a more complex model such as the one shown earlier in the figure at the beginning of this section, there are loops in the replication paths and replication takes place at differing intervals.

When the push partner receives a request from another WINS server it retrieves the required records from its local database and sends them in the response. The records are retrieved by seeking to the record that starts the range and then moving sequentially over the records until the last one in the range has been retrieved.

When the data is received from the push partners, the pull partner updates its database.

What gets replicated

As described above, all entries with version IDs greater than those in the pulling database get replicated. However, not every change to a database causes the version id of a record to be incremented.

Records in the WINS database contain state and ownership information. Records may be in an active, released, or extinct (tombstone) state. They are owned by the local database or are replicas from another WINS server. A record is also static or dynamic.

When names are registered with a WINS server, they are entered in the database in an active state and Time Stamped with Current Time + Renewal Interval. The version ID is taken from the version id counter which is then incremented. If a name is explicitly released or fails to refresh during the Renewal Interval, it enters the released state. The entry is Time Stamped with Current Time + Extinction Interval. The version ID in not changed. Thus, records in the released state will not be replicated.¹⁶If a record remains in the released state for more than the Extinction Interval, it enters the extinct (or tombstone) state. It is Time Stamped with Current Time + Extinction Time-out and receives a new version ID to cause it to be replicated. If a record remains in the extinct (or tombstone) state for more than the Extinction Time-out, it is deleted from the database.

Only records in the active or tombstone states are replicated. In the replica database these records are entered with the fields received from the owner database with the exception of ownership and Time Stamp. The ownership field is taken from the local IP address - Owner id mapping table. This does not mean that the ownership of the replica changes. It just means that the value used to represent a particular WINS server differs from server to server. For example, WINS_D might be represented by a 2 on WINS_B but a 3 on WINS_A. An active record is Time Stamped with (local) Current Time + Verify Interval. A tombstone record is Time Stamped with (local) Current Time + Extinction Time-out.

Conflicts Detected During Replication

Name conflicts are normally handled at the time of name registration. However, it is possible for the same name to be registered at two different WINS servers. This would happen if the same name were registered at a second WINS server before the database from the first WINS server had been replicated. In this case, the conflict will be noted and resolved at replication time.

Conflict at replication can be:

Conflict between unique entries

When resolving conflicts between unique entries the following is taken into account:

Conflict between two replicas with the same or different IP addresses

The replica in the database is overwritten by the new replica, regardless of whether the addresses match or not, unless the replica in the database is active and the new replica is a tombstone. In this case, the replica in the database is not overwritten by the new replica unless they are both owned by the same WINS server.

Conflict between owned entry and replica with same IP address

The database record is replaced by the replica unless the database record is active and the replica is a tombstone. In that case, the version ID of the database record is incremented so that the record gets propagated at replication time.

Conflict between owned entry and replica with the different IP addresses

The database record is replaced by the replica unless the database record is active. In such a case, if the replica is a tombstone, the database record's version ID is incremented so that the record gets propagated at replication time. If the replica is also active, then the database record's node is challenged to determine if it still has the name. If it still has it, the replica's node is sent a Name Conflict Demand forcing the node to place the name in the conflict state.

Conflict between a unique entry and a group entry

When the conflict is between a unique entry and a group entry, the group entry is kept. If the unique entry is owned by the WINS server and is not in the released or tombstone state, the WINS server asks the node in the unique entry to release the name.

Conflict between two Special Group entries

The database record is replaced by the replica unless it is active. If it is active, its version ID is incremented so that the record gets propagated at replication time. If the replica is also in the active state, the member list of the database record is updated with any members in the replica that are not already in it. If the list of members in the active state grows to more than 25, the extra members are not inserted.

Conflict involving a Multihomed record

If a multihomed replica conflicts with a tombstone or released entry in the database, the entry in the database is replaced with the replica unless the entry is a normal group and is in the released state. This is no different from the other scenarios where a non-multihomed entry conflicts with a released normal group entry.

If a tombstone multihomed replica clashes with an active database entry whose owner is the same as that of the multihomed replica, then the database entry is replaced. If however, the active database entry is a replica owned by a different owner, it is not replaced. If the active database entry is owned by the local WINS server and happens to be a unique entry, its version ID is incremented to cause propagation.

If an active multihomed replica clashes with an active unique/multihomed replica in the local database having the same owner, it is replaced. If the owner is different, it is not replaced. If the entry in the database is owned by the local WINS server, and if the members of the record (one the in case where it is a unique record) is a subset of the members in the replica, the database record's Time Stamp is changed and version ID incremented to propagate it. If the replica's members are not a subset, the local record's addresses are challenged. If all challenges succeed (that is the node challenged does not respond to any challenge), the database record is replaced. If at least one challenge fails, the node is told to release the name from all addresses prior to replacing the database record with the replica.

If a multihomed replica clashed with an active group entry in the database, the version ID of the entry in the database is incremented to cause propagation.

If a non-multihomed replica clashes with a non-active multihomed record in the database, the database record is replaced. If it clashes with an active multihomed entry in the database owned by the same owner, the database record is replaced. If the multihomed entry in the database is a replica owned by a different owner, it is not replaced. If however, it is owned by the local WINS server and the replica pulled in is a unique record, then the addresses in the multihomed record are challenged. If all challenges succeed, the database record is replaced. If at least one challenge fails, the addresses in the database record are sent release requests for the name and then the database record is updated.

Note: The address in the unique replica, if present in the member list, is ignored in the above situation.

Scavenging

Scavenging maintains the correct state information in the database. The Scavenging Timer is started at boot time and is equal to ½ the Renewal Interval. Scavenging first occurs after ½ the Renewal Interval.¹⁷ During the first scavenging, all scavenging actions are performed except for the deletion of the tombstones. Tombstones may not be deleted until at least three days have elapsed since boot. This is to allow for sufficient time for their replication. Scavenging reoccurs at ½ the Renewal Interval (or may be initiated manually).

Scavenging follows the following algorithm:

Get records owned by self
If Current Time > Time Stamp
Change State
Active -> Released
Released -> Tombstone
Tombstone -> delete from database
Get replica Tombstones
If Current Time > Time Stamp
Delete record from database
Get Active replicas
If Current Time > Time Stamp
Verify with owner that record still exists
If exists
Time Stamp = Current Time + Verify Interval
Else
Delete record from database

Top of page

New in NT 4.0

Burst Mode

The burst handling parameter is used to temporarily achieve a steady state in the WINS server when the WINS server is either started with a clean database or many WINS clients come online for the first time. Either situation causes a large amount of name registration and name refresh traffic to occur. The WINS server currently stores a maximum of 25000 name registrations and refresh queries in it's queue before dropping queries. By using this parameter the WINS server can be configured to send success responses to the clients whose requests are dropped. These responses will have TTLs that will slow down the refresh rate of those WINS clients and regulate the burst of WINS client traffic. This will result in a steady state being reached much more quickly.

This feature may be enabled by creating the "BurstHandling" key under the HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \WINS \Parameters key and setting the value to 1.

Name: BurstHandling

Type = REG_DWORD
Value: 0 or 1
Default = 0

Administering WINS Through a Firewall

When doing remote WINS administration, an initial session set up is to port 135. This is followed by another session to a random port above 1024. This is because the WINS Administrator uses "dynamic endpoints" in RPC. Internet firewalls cannot be configured to pass this traffic when the port is not consistent. In Windows NT 4.0 the system defaults for dynamic port allocation may be defined in the registry.

In order to allow remote administration of WINS through a firewall, a list of all ports available (or not available) from the Internet should be defined in the registry with the following keys. These keys are located under:

HKEY_LOCAL_MACHINE \Software \Microsoft \Rpc \Internet

Name: Ports

Type: REG_MULTI_SZ - set of IP port ranges
Description: Specifies a set of IP port ranges consisting of either all of the ports available from the Internet or all of the ports not available from the Internet. Each string represents a single port or an inclusive set of ports (for example,"1000-1050" "1984"). If any entries are outside the range of zero to 65535, or if any string cannot be interpreted, the RPC run time will treat the entire configuration as invalid.

Name: PortsInternetAvailable
Type: REG_SZ - Y or N (not case-sensitive)

Description: If Y, the ports listed in the Ports key are all the Internet-available ports on that machine. If N, the ports listed in the Ports key are all those ports that are not Internet-available.

Name: UseInternetPorts
Type: REG_SZ - Y or N (not case-sensitive)

Description: Specifies the system default policy. If Y, the processes using the default will be assigned ports from the set of Internet-available ports, as defined above. If N, processes using the default will be assigned ports from the set of intranet-only ports.

Consistency Check by WINS

In Windows NT 4.0 it is possible to periodically check the WINS database for consistency. However, consistency checking is very network intensive and consumes a lot of cycles on the WINS server. This is because the WINS replicates all records for an owner whose records are being checked from another WINS to determine whether its database with regard to the owner is in synch with the other WINS. One should be prudent in selecting the values for different parameters below. The type of existing network configuration (number of WINS servers, WAN/LAN lines between WINS servers, number of WINS clients, and so on) will help to determine appropriate values for the these parameters.

This feature may be enabled by creating the "ConsistencyCheck" key under the HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services WINS\Parameters key.

Optionally, the following values may be created under this key

Name: TimeInterval
Type: REG_DWORD - No Of Seconds

Description: Specifies the time interval at which WINS will do a consistency check.
Default: 24 hours

Name: SpTime
Type: REG_SZ hh:mm:ss

Description: Specifies the specific time in hh:mm:ss format at which the first consistency check will be done. Thereafter, it will be done periodically at TimeInterval seconds.
Default: 2:00:00 (2 am).

Name: MaxRecsAtATime
Type: REG_DWORD No Of Recs

Description: The maximum number of records that will be replicated in one consistency check cycle. WINS does consistency checks on the records of each owner of WINS. After checking one owner it either goes on to the next one in its list of owners or stops based on the MaxRecsAtATime value.
Default: 30000

Name: UseRplPnrs
Type: DWORD 0 or non-zero value

Description: If set to a non-zero value, WINS will contact only its pull [artners when doing consistency checks on the records in its database. If the owner whose records need to be checked is a Pull Partner, it will be used. Otherwise, a random pull partner will be used.

Note: WINS never deletes records in its database if the partner with which it is doing verification is not the owner. This is because WINS does not know which database is more current.

WINSCHK

There is a new tool in the Windows NT 4.0 Resource Kit—WINSCHK. This command-line utility checks name and version number inconsistencies that may appear in Windows Internet Name Service (WINS) databases, monitors replication activity, and verifies the replication topology in an enterprise network. It is particularly useful for WINS administrators.

With WINSCHK, you can remotely check and resolve WINS database replication issues. You can isolate some of the most common problems that lead to database inconsistencies with an easy-to-use tool that can be run in a central location.

This tool supplements WINSCL with options geared towards flagging possible causes for database inconsistencies, such as:

The tool also helps monitor the actual replication activity by allowing the user to:

The tool can be used in interactive or non-interactive mode. In the latter, a log of all the tool activity is kept in the local directory (WINSTST.LOG). The option to monitor WINS activity can be run in the background, which dumps all logs into MONITOR.LOG.

WINSCHK provides the following options:

Top of page

Wins Database

The WINS server uses a relational database engine to access an ISAM (Indexed Sequential Access Method) database. The WINS database consists of two tables. The IP address - Owner ID mapping table and the Name to IP address mapping table.

IP Address - Owner ID Mapping Table

This table contains a row for each WINS server that has entries in the Name to IP