Chapter 8 - Managing MS WINS Servers
| Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
Microsoft Windows Internet Name Service (WINS) is an RFC-compliant NetBIOS name- to-IP-address mapping service. WINS allows Windows-based clients to easily locate resources on Transmission Control Protocol/Internet Protocol (TCP/IP) networks. WINS servers maintain databases of static and dynamic resource name—to-IP-address mappings. Because the Microsoft WINS database supports dynamic name and IP address entries, WINS can be used with Dynamic Host Configuration Protocol (DHCP) services to provide easy configuration and administration of Windows-based TCP/IP networks.
The information in this chapter is intended for network administrators and support personnel who need information about WINS and how to plan, manage, and troubleshoot WINS services. The following topics are included in this chapter:
Introduction to Windows Internet Name Service (WINS)
Microsoft WINS servers
Microsoft WINS server push and pull partners
Microsoft WINS clients
Microsoft WINS proxies
Planning for Microsoft WINS server implementation
Using WINS Manager
Viewing WINS server operational status
Configuring WINS server and WINS client behavior
Managing static NetBIOS computer name—to-IP-address mappings
Special names for static entry types
Managing the WINS server database
Troubleshooting WINS servers and databases
On This Page
Introduction to Windows Internet Name Service
Planning for Microsoft WINS Server Implementation
Using WINS Manager
Troubleshooting WINS Servers
Introduction to Windows Internet Name Service
NetBIOS is a session-level interface used by programs to communicate over NetBIOS- compatible transports, including TCP/IP. One function of the NetBIOS interface is to establish logical names for networking programs.
Microsoft Windows Internet Name Service (WINS) is compliant with RFC 1001 and RFC 1002. Microsoft WINS is designed to provide a flexible solution to the problem of locating NetBIOS resources in routed, TCP/IP-based networks.
When using TCP/IP to communicate on a network, a "friendly" Windows-based NetBIOS computer name, such as "mycomputer," must be resolved to an IP address. This is necessary because TCP/IP requires an IP address, such as 172.16.48.1, to establish a connection to a network device. Several different name resolution methods provide NetBIOS name resolution. These methods include:
IP broadcasts
Static mapping files (LMHOSTS and DNS-based HOSTS files)
NetBIOS name server (in Windows NT-based networks, this is the Microsoft WINS server)
Domain Name System server (in Windows NT-based networks, this is the Microsoft DNS Server)
Microsoft WINS Servers
WINS servers are designed to prevent the administrative difficulties that are inherent in the use of both IP broadcasts and static mapping files such as LMHOSTS files. Microsoft WINS is designed to eliminate the need for IP broadcasts (which use valuable network bandwidth and cannot be used in routed networks), while providing a dynamic, distributed database that maintains computer name-to-IP-address mappings.
WINS servers use a replicated database that contains NetBIOS computer names and IP address mappings (database records). When Windows-based computers log on to the network, their computer name and IP addressing mapping are added (registered) to the WINS server database, providing support for dynamic updates. The WINS server database is replicated among multiple WINS servers in a LAN or WAN. One of the benefits of this database design is that it prevents different users from registering duplicate NetBIOS computer names on the network.
WINS servers provide the following benefits:
Dynamic database that supports NetBIOS computer name registration and name resolution in an environment where the dynamic TCP/IP configuration of DHCP-enabled clients is dynamically configured for TCP/IP.
Centralized management of the NetBIOS computer name database and its replication to other WINS servers.
Reduction of NetBIOS name query IP broadcast traffic.
Support for Windows-based clients (including Windows NT Server, Windows NT Workstation, Windows 95, Windows for Workgroups, and LAN Manager 2.x).
Support for transparent browsing across routers for Windows NT Server, Windows NT Workstation, Windows 95, and Windows for Workgroups clients.
The following figure illustrates an intranet with multiple WINS servers in a routed network. The components of a WINS system are shown in the illustration and are discussed in the following sections:
Microsoft WINS server push and pull partners
WINS clients, referred to as WINS-enabled computers
WINS proxy and non-WINS enabled computers
.gif "Cc751207.xng_m01(en-us,TechNet.10).gif")
Figure 8.1: WINS Servers and WINS Clients in a Routed TCP/IP Network
.gif "Cc751207.xng_m01(en-us,TechNet.10).gif")
Microsoft WINS Server Push and Pull Partners
A given network should have one or more WINS servers that WINS clients can contact to resolve a computer name to an IP address. It is desirable to have multiple WINS servers installed on an intranet for the following reasons:
To distribute the NetBIOS computer name query and registration processing load
To provide WINS database redundancy, backup, and disaster recovery
Microsoft WINS servers communicate with other Microsoft WINS servers to fully replicate their databases with each other. This ensures that a name registered with one WINS server is replicated to all other Microsoft WINS servers within the intranet, providing a replicated and enterprise-wide database.
When multiple WINS servers are used, each WINS server is configured as a pull or push partner of at least one other WINS server. The following table describes the pull and push partner types of replication partners.
Table 8.1 WINS Server Replication Partners
Type |
Description |
|---|---|
Pull partner |
A pull partner is a WINS server that pulls (requests) WINS database entries from its push partners. The pull partner pulls new WINS database entries by requesting entries with a higher version number than the last entry it received during the last replication from that push partner. A pull partner can notify push partners that replication is needed by using either of the following: |
Push partner |
A push partner is a WINS server that sends a message to its pull partners that the WINS database has changed. When the pull partners respond to the message with a replication request, the push partner sends a copy of its new WINS database entries to the pull partners. The push partner notifies pull partners of replication requirements by using any of the following: |
It is always a good idea for replication partners to be both push and pull partners of each other. The primary and backup WINS servers must be both push and pull partners with each other to ensure that the primary and backup databases are consistent.
Replication is triggered when a WINS server polls another server to get replicated information. This can begin when the WINS server is started, and is repeated based on the configured update count or time interval, or by using WINS Manager to start immediate replication.
Microsoft WINS Clients
WINS clients, referred to as WINS- enabled clients, are configured to use the services of a WINS server.
Windows NT- based clients are configured with the IP address of one or more WINS servers by using the WINS Address tab on the Microsoft TCP/IP Properties page in Control Panel - Network. The following figure illustrates this configuration page.
.gif "Cc751207.xng_m02a(en-us,TechNet.10).gif")
Figure 8.2: Enabling the WINS Service on a WINS Client
The WINS-enabled client communicates with the WINS server to:
Register the client names in the WINS database.
Get mappings for user names, NetBIOS names, DNS names, and IP addresses from the WINS database.
How WINS Clients Register Their Names
When a WINS-enabled computer is started, the WINS client service attempts to directly contact the WINS server (by using point-to-point communication) to register the client names and corresponding IP address. The type of message the client sends is referred to as a name registrationrequest. The WINS client sends one name registration request (which includes the computer IP address) for the computer, logged-on user, and networking services running on the computer.
Note: The IP address is dynamically assigned by a DHCP server if the client is DHCP-enabled. If DHCP is not used, the IP address is a statically assigned number which you must get from a network administrator and manually configure on the computer.
When the WINS server receives a name registration request, it checks the WINS database to ensure that the name in the request is unique and does not exist in the WINS database. The WINS server responds with either a positive or negative name registration response. The following table describes the processing that occurs for each type of WINS server name registration response.
Table 8.2 WINS Server Response to Name Registration Request
WINS server name registration response |
WINS client behavior |
|---|---|
No response |
The WINS client sends another name registration request. |
Positive |
The WINS server responds with a positive name registration response if there is not a duplicate name in the WINS database. The response includes a time- to- live (TTL) value that indicates how long the client can own that name. The client must renew the name registration before the TTL expires. |
Negative |
If there is an existing registration for the name in the WINS database, the WINS server sends a challenge, referred to as a name query request, to the currently registered owner of the name. |
The following figure illustrates the flow of name registration request and name response.
.gif "Cc751207.xng_m03(en-us,TechNet.10).gif")
Figure 8.3: WINS Client Name Registration
How WINS Clients Renew Their Names
WINS clients must renew their name registrations before the time-to-live (TTL) value expires. The TTL value indicates how long the client can own that name.
When a WINS client renews its name registration, it sends a name refresh request directly (point- to-point) to the WINS server. The name refresh request includes the WINS client's IP address and the name that the client is requesting to have refreshed. The WINS server responds to the name refresh request with a name refresh response that includes a new TTL for the name.
A WINS client first attempts to refresh its name registrations after one-half of the TTL is expired. If the WINS client does not receive a name refresh response from the WINS server, it sends name refresh requests every two minutes, until one-half of the TTL is expired.
If the WINS client does not receive a name refresh response and one-half of the TTL is expired, the WINS client begins sending name refresh requests to a secondary WINS server if the computer is configured with an IP address for a secondary WINS server. The WINS client attempts to refresh its registrations with the secondary WINS server as if it were the first refresh attempt— n time increments equal to one-eighth of the TTL. The WINS client sends the name refresh requests until it successfully receives a name refresh response, or one-half of the TTL is expired. If the WINS client cannot contact the secondary WINS server by the time half of the TTL has expired, it reverts back to the primary WINS server. After a WINS client has successfully refreshed its name registrations, it does not start subsequent name registration requests until one-half of the TTL is expired.
How WINS Clients Release Their Names
When a WINS-enabled computer is correctly stopped, the WINS client sends a name release request to the WINS server. A name release request is sent for each name associated with the computer, logged-on user, and network client service that is registered with the WINS server. The name release request includes the computer IP address and the name that should be released (deleted) from the WINS server database.
Because the WINS-enabled client is configured with the IP address of the WINS server, the name release requests are sent directly to the WINS server. When the WINS server receives a name release request, the WINS server checks the WINS database for the specified name.
Based on the results of the database check, the WINS server sends a positive or negative name release response to the WINS client and removes the specified name from the WINS database. The name release response contains the name released and a TTL of 0 (zero).
Table 8.3 WINS Server Response to Name Release Request
WINS server name release response |
WINS client behavior |
|---|---|
No response |
The WINS client waits to receive the response, and if it does not receive one, it sends another name release request. |
Positive |
The WINS client releases the name and stops. Microsoft WINS clients ignore the contents of the name release response. |
Negative |
The WINS client releases the name and stops. Because Microsoft WINS clients ignore the contents of the name release response when the WINS server sends a negative name release response, the server does not prevent the client from releasing the name and stopping. |
How WINS Clients Perform Name Resolution
WINS clients perform NetBIOS computer name-to-IP-address mapping resolution by using the NetBIOS over TCP/IP (NetBT) component. A Windows NT-based computer is automatically configured to use one of four different NetBT name resolution modes (methods), based on how TCP/IP is configured on the computer. The following table describes the computer (referred to as a node) configuration and its associated NetBT name resolution mode.
Table 8.4 Description of NetBIOS Node Types
NetBIOS name resolution node type |
Description |
|---|---|
b-node |
Uses IP broadcast messages to register and resolve NetBIOS names to IP addresses. Windows NT-based computers can use modified b-node name resolution. |
p-node |
Uses point-to-point communications with a NetBIOS name server (in Windows NT-based networks, this is the WINS server) to register and resolve computer names to IP addresses. |
m-node |
Uses a combination (mix) of b-node and p-node communications to register and resolve NetBIOS names. M-node first uses b-node; then, if necessary, p-node. M-node is typically not the best choice for larger networks because its preference for b-node broadcasts increases network traffic. |
h-node |
Uses a hybrid combination of b-node and p-node. When configured to use h-node, a computer always tries p-node first and uses b-node only if p-node fails. When a Windows NT-based computer is configured as a WINS client, it is by default configured as h-node. To further lessen the potential for IP broadcasts, Windows NT-based computers are configured, by installation default, to use an LMHOSTS file to search for name –to- IP-address mappings before using b-node IP broadcasts. |
Note: Use the ipconfig /all command to display the TCP/IP configuration, including node type, of your computer. For example, on a computer that is configured as a WINS client, the node type Hybrid appears when the ipconfig /all command is entered.
The following figure illustrates the name resolution processes between a WINS client (h-node) and a WINS server.
.gif "Cc751207.xng_m04(en-us,TechNet.10).gif")
Figure 8.4: H-Node Name Resolution for WINS Clients
Microsoft WINS Proxy
A WINS proxy is a WINS-enabled computer that helps resolve name queries for non-WINS enabled computers in routed TCP/IP intranets. By default, non-WINS enabled computers are configured as b-node which use IP broadcasts for name queries. The WINS proxy computer listens on the local subnet for IP broadcast name queries.
When a non-WINS enabled computer sends an IP name query broadcast, the WINS proxy accepts the broadcast and checks its cache for the appropriate NetBIOS computer name-to-IP-address mapping. If the WINS proxy has the correct mapping in its cache, the WINS proxy sends this information to the non-WINS computer. If the name-to-IP-address mapping is not in cache, the WINS proxy queries a WINS server for the name-to-IP-address mapping.
If a WINS server is not available on the local subnet, the WINS proxy can query a WINS server across a router. The WINS proxy caches (stores in memory) computer name-to-IP-address mappings it receives from the WINS server. These mappings are used to respond to subsequent IP broadcast name queries from b-node computers on the local subnet.
The name-to-IP-address mappings that the WINS proxy receives from the WINS server are stored in the WINS proxy cache for a limited time. (By installation default this value is 6 minutes. The minimum value is 1 minute.)
When the WINS proxy receives a response from the WINS server, it stores the mapping in its cache and responds to any subsequent name query broadcasts with the mapping received from the WINS server.
The role of the WINS proxy is similar to that of the DHCP/BOOTP relay agent which forwards DHCP client requests across routers. Because the WINS server does not respond to broadcasts, a computer configured as a WINS proxy should be installed on subnets which contain computers that use broadcasts for name resolution.
Note: To configure a computer as a WINS proxy, you must manually edit that computer's registry. The registry parameter EnableProxy must be set to 1 (REG_DWORD). This parameter is located in the following Registry key:
HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Netbt \Parameters
Planning for Microsoft WINS Server Implementation
The number of Windows NT-based WINS servers that an enterprise requires is based on the number of WINS client connections per server and the network topology. The number of users that can be supported per server varies according to usage patterns, data storage, and processing capabilities of the WINS server computer.
Planning for WINS server implementation on the network typically requires consideration of the issues presented in the following table.
Table 8.5 Network Configuration Planning Issues for WINS Servers
Planning issue |
Guideline |
|---|---|
How many WINS servers are required to ensure distribution of name query and name registration loads throughout the network? |
One WINS server can handle NetBIOS name resolution requests for 10,000 computers. However, the location of routers on the network and the distribution of clients in each subnet should be considered when deciding how many WINS servers are required. See the following sections: "Planning for WINS Server Performance," "Planning for WINS Client Network Traffic," and "Planning for Replication Partners and Proxies." |
Is the WAN bandwidth sufficient to support WINS server and WINS client name registration traffic? |
See the next section, "Planning for WINS Client Network Traffic." |
How many WINS servers are needed for disaster recovery, backup, and redundancy requirements? |
See the following sections: "Planning for WINS Server Fault Tolerance" and "Planning for WINS Server Performance." |
How can a planned distribution of WINS servers throughout the network be validated before installation? |
When planning a network configuration, a generally accepted approach is to consider the consequences of two simultaneous failures at different points on the network. |
Other planning issues for WINS servers can be similar to those for implementing Microsoft DHCP servers, as described in Chapter 7, "Managing Microsoft DHCP Servers."
Planning for WINS Client Network Traffic
WINS clients generate the following types of network traffic:
Name registration
Name refresh
Name release
Name query
When a WINS-enabled client starts on the network, it sends a name registration request for the computer name, user name, domain name, and any additional Microsoft network client services running on the computer. In other words, when a WINS client starts on the network, it generates a minimum of three name registration requests and three entries in the WINS database.
A Windows NT Server-based WINS client usually registers more NetBIOS names than other WINS-enabled clients. The name registration requests generated by a computer running under Windows NT Server include the following:
Server component
Domain names
Replicator service name
Messenger service name
Browser service name
Additional network program and service names
WINS Client Traffic on Routed Networks
When planning for WINS client traffic on large routed networks, consider the effect of name query, registration, and response traffic routed between subnets. Name requests and responses that occur at the daily startup of computers must pass through the traffic queues on the routers, and may cause delays at peak times.
Daily Startup of WINS Clients
An active WINS client name registration in a WINS server database is replicated to all pull partners configured on that WINS server. After some time, the active name registration is replicated to all WINS servers on the network.
When the WINS client is turned off at the end of the day, it releases the name. When the computer is started the next morning, the WINS client registers the name again with the WINS server, and receives a new version ID. This new, active name registration entry is replicated to the WINS server's pull partners as on the previous day.
Therefore the number of name registration entries that are replicated each day is roughly equivalent to the number of computers started each day times the number of NetBIOS names registered at each computer.
On large networks (50,000 or more computers), the biggest traffic load may be the name registration requests generated when WINS clients start on the network.. Fortunately, the difference in time zones in large enterprise networks provides some distribution of this WINS client startup load.
Roving User
When a user stops the computer and then moves and starts the computer on a different subnet with another primary WINS server, name challenge traffic is generated. Typically, the name registration request is answered with a Wait for Acknowledgment message (100 bytes), and the new WINS server (assuming the active entry was replicated) challenges the IP address that is currently in its database for this name (Name Query packet, 92 bytes). When there is no reply, as can be expected in this case, the WINS server repeats the challenge two more times and then updates the name registration entry with the new IP address and a new version ID. The new version ID indicates that the entry must be replicated from its new "owning" WINS server to other WINS servers on the network.
Estimating WINS Client Traffic
You can estimate WINS client traffic based on the behavior of the WINS clients as described in the preceding sections. However, when estimating WINS client traffic, you must also consider the network topology and the design or configuration of the routers in the network. In some cases it may not always be possible to predict the traffic load on a specific network router because the routers may be designed, or configured, to autonomously route traffic based on factors other than traffic load.
Planning for WINS Server Replication Across Wide Area Networks
The frequency of WINS database replication between WINS servers is a major planning issue. The WINS server database should be replicated frequently enough that the down-time of a single WINS server does not affect the reliability of the mapping information in the database of other WINS servers. However, when planning WINS database replication frequency, you do not want frequency of database replication to interfere with network throughput, which could happen if replication frequency is set to a small time interval.
Consider the network topology when planning for replication frequency. For example, if your network has multiple hubs connected by relatively slow wide-area-network (WAN) links, you can configure WINS database replication between WINS servers on the slow links to occur less frequently than replication on the local area network or on fast WAN links. This reduces traffic across the slow link and reduces contention between replication traffic and WINS client name queries.
For example, WIN servers at a central local-area-network site may be configured to replicate every 15 minutes, while database replication between WINS servers in different WAN hubs might be scheduled for every 30 minutes, and replication between WINS servers on different continents might be scheduled to replicate twice a day. The following figure illustrates this example of variation in replication frequency.
.gif "Figure 8.5: Enterprise Network Configuration and WINS Server Replication")
Figure 8.5: Enterprise Network Configuration and WINS Server Replication
Planning for Replication Convergence Time
The time needed to replicate a new entry in a WINS database from the WINS server that owns the entry to all other WINS servers on the network is called convergence time. When planning for WINS servers, you need to decide what is acceptable as the convergence time for your network.
This following figure illustrates an example network installation of WINS servers and the database replication interval between each WINS server. This example network configuration is presented to show how replication interval between WINS servers affects the convergence time.
.gif "Figure 8.6: Replication Intervals Between WINS Servers in a Routed TCP/IP Network")
Figure 8.6: Replication Intervals Between WINS Servers in a Routed TCP/IP Network
If a WINS client registers its name with the WINS server labeled WINS_C in the figure, other WINS clients can query WINS_C for this name and get the name –to-IP-address mapping. WINS clients that query any of the other WINS servers shown in the figure (WINS_A, WINS_B, and WINS_D) do not get a positive response until the entry is replicated from the WINS_C server to WINS_A, WINS_B, and WINS_D. WINS_C is configured to start replication when the push Update Count threshold is exceeded or when the pull Replication Interval expires on its WINS pull partner, WINS_A. (For this example, WINS_A is configured with a replication interval of 15 minutes.)
Only when the pull Replication Interval expires is the entry replicated, but queries for the new name to WINS servers B and D may still not be successful. The time interval for replication to server B is 15 minutes; to server D, it is 12 hours. The convergence time is calculated as:
12 hours + 2x (15 minutes) = 12.5 hour
Name query requests may, in reality, succeed before the convergence time has passed. This would happen if the entries have to be replicated over a shorter path than the worst case path. And it would also happen when an Update Count threshold would be passed before the Replication Interval would expire; this would result in earlier replication of the new entry. The longer the replication path, the longer the convergence time.
Planning for WINS Server Fault Tolerance
There are two basic types of WINS server failures:
A WINS server may crash, or be stopped to do maintenance.
Network failures including failures of routers and link stations.
In Figure 8.6, a failure of WINS-A or WINS-B would segment the distribution of WINS server services. Entries would no longer be replicated from WINS-C to WINS-D, and vice versa. Because the IP address and name would no longer match for updated clients, other clients would not be able to connect to the updated computers. Adding replication between WINS-B and WINS-C would improve the configuration for cases in which WINS-A fails. Adding replication between WINS-D and WINS-C would improve fault tolerance in a case where the WINS-B server fails.
Failure of one of the links between A, B, and C could be tolerated because the underlying router network would reroute the traffic. Failure of the link between B and D, however, would segment the communication between WINS servers and would make other network traffic impossible should there be an on-demand backup link between D and C. The WINS replication traffic would then be rerouted by the underlying router infrastructure.
Planning for WINS Server Performance
A WINS server can typically service:
1,500 name registrations per minute.
4,500 queries per minute.
A conservative recommendation is that you plan to install one WINS server and a backup server for every 10,000 computers on the network, based on these numbers and the possibility for large-scale power outages that would cause many computers to re-start simultaneously.
Two factors enhance WINS server performance. WINS server performance can be increased almost 25 percent on a computer with two processors. WINS server name replication response time can be measurably improved by using a dedicated disk.
After you establish WINS servers on the intranet, you can adjust the time between a WINS client name registration and name renewal. This is referred to as the Renewal Interval. Setting this interval to reduce the numbers of registrations can help tune server response time. (The Renewal Interval is specified when configuring the WINS server.)
Planning for Replication Partners and Proxies
Choosing whether to configure another WINS server as a push partner or pull partner depends on several considerations, including the specific configuration of servers at your site, whether the partner is across a wide area network (WAN), and how important it is to distribute changes throughout the network. Only one computer configured as a WINS proxy should be installed on each subnet. (Configuring more than one WINS proxy per subnet can overload the WINS servers on the same subnet.)
In one possible configuration, one WINS server can be designated as the central server, and all other WINS servers can be configured as both push partner and pull partner of this central server. Such a configuration ensures that the WINS database on each server contains addresses for every node on the WAN.
.gif "Figure 8.7: WINS Servers Replication by using a Central WINS Server")
Figure 8.7: WINS Servers Replication by using a Central WINS Server
Another option is to set up a chain of WINS servers, where each server is both the push partner and pull partner with a nearby WINS server. In such a configuration, the two servers at the ends of the chain would also be push and pull partners with each other.
.gif "Cc751207.xng_m08(en-us,TechNet.10).gif")
Figure 8.8: WINS Servers Replication in a Chained Network Configuration
Other replication partner configurations can be established for your site's needs. For example, in the following illustration, Server1 has only Server2 as a partner, but Server2 has three partners. So, for example, Server1 gets all replicated information from Server2, but Server2 gets information from Server1, Server3, and Server4.
.gif "Cc751207.xng_m09(en-us,TechNet.10).gif")
Figure 8.9: WINS Server Replication in a T Network Configuration
If Server2, for example, needs to perform pull replications with WINS ServerB, make sure it is a push partner of Server3.
If Server2 needs to push replications to Server3, it should be a pull partner of WINS ServerB.
Fine-tuning WINS Server Replication Traffic
Fine-tuning the Replication Intervals may save some bandwidth on WAN links. Figure 8.10 illustrates a network configuration based on the network configuration first illustrated in Figure 8.6. The network configuration in Figure 8.6 was changed to the configuration shown in Figure 8.10 to illustrate one possible method for reducing convergence time.
.gif "Cc751207.xng_m10(en-us,TechNet.10).gif")
Figure 8.10: Reducing WINS Server Replication Convergence Time
By keeping the pull Replication Intervals between WINS-C and WINS-B short (15 minutes), WINS servers A, B, and C can be reasonably synchronized. Replicas are never pulled in twice; only replicas with a higher version ID are copied. When WINS-B has an entry directly from WINS-C, it does not pull that entry from WINS-A.
However, under the example configuration there is the chance that both WINS-D and WINS-B can pull replicas from WINS-C by using the link between WINS-B and WINS-C. The resultant load on the link between WINS-B and WINS-C would increase.
In the example, this problem can be avoided if WINS-D is configured to pull replicas from WINS-B first and then check WINS-C. The pull Replication Interval between WINS-D and WINS-C would typically be the same 12 hours. Remember to configure push Update Counts (on WINS-D and WINS-C) to correspond to the 12 hours pull Replication Interval; otherwise unexpected replication is triggered by the Update Count threshold and not by the pull Replication Interval.
Using WINS Manager
When you install a WINS server, the WINS Manager graphic administration tool is added to the Administrative Tools (Common) Programs group on the Start menu.
.gif "Cc751207.xng_m11(en-us,TechNet.10).gif")
Figure 8.11: Using WINS Manager
Use WINS Manager to view and change parameters for WINS servers on the network for which you have administrator privileges. WINS Manager Help is organized to provide information for each of the specific administration and configuration tasks that you need to perform to manage WINS servers. See WINS Manager Help for specific task lists and instructions.
Note: Other tools you can use to manage WINS servers include the Performance Monitor and SNMP agent service. Use Performance Monitor to monitor WINS server performance. Use the SNMP service to monitor and configure WINS servers by using third-party SNMP manager tools. Note that when using a third-party SNMP manager tool, some WINS queries may time out; if so, you should increase the time-out on the SNMP tool you are using.
Viewing WINS Server Operational Status
WINS Manager allows you to view administrative and operational information about WINS servers. When you open WINS Manager, it displays basic statistics about the selected WINS server in the right pane of the WINS Manager window. The following table describes these basic statistics for WINS servers.
Table 8.6 Statistics in WINS Manager
Statistic |
Description |
|---|---|
Database Initialized |
The last time static mappings were imported into the WINS database. |
Statistics Cleared |
The time when statistics for the WINS server were last cleared with the Clear Statistics command from the View menu. |
Last Replication Times |
The times at which the WINS database was last replicated. |
Periodic |
The last time the WINS database was replicated based on the replication interval specified in the Preferences dialog box. |
Admin Trigger |
The last time the WINS database was replicated because the administrator clicked the Replicate Now button in the Replication Partners dialog box. |
Net Update |
The last time the WINS database was replicated as a result of a network request, which is a push notification message that requests propagation. |
Total Queries Received |
The number of name query request messages received by this WINS server. Successful indicates how many names were successfully matched in the database, and Failed indicates how many names this WINS server could not resolve. |
Total Releases |
The number of messages received that indicate a NetBIOS program has stopped. Successful indicates how many names were successfully released, and Failed indicates how many names this WINS server could not release. |
Total Registrations |
The number of messages received that indicate name registrations for clients. |
You can display additional statistics by clicking Detailed Information on the Server menu. The following table describes these detailed information statistics.
Table 8.7 Detailed Information Statistics for WINS Manager
Statistic |
Meaning |
|---|---|
Last Address Change |
Indicates the time at which the last WINS database change was replicated. |
Last Scavenging Times |
Indicates the last times that the database was cleaned for specific types of entries. (For information about database scavenging, see "Managing the WINS Server Database" later in this chapter.) |
Periodic |
Indicates when the database was cleaned based on the renewal interval specified in the WINS Server Configuration-(Local) dialog box. |
Admin Trigger |
Indicates when the database was last cleaned because the administrator chose Initiate Scavenging. |
Extinction |
Indicates when the database was last cleaned based on the Extinction interval specified in the WINS Server Configuration dialog box. |
Verification |
Indicates when the database was last cleaned based on the verify interval specified in the WINS Server Configuration dialog box. |
Unique Registrations |
Indicates the number of name registration requests that have been accepted by this WINS server. |
Unique Conflicts |
The number of conflicts encountered during registration of unique names owned by this WINS server. |
Unique Renewals |
The number of renewals received for unique names. |
Group Registrations |
The number of registration requests for groups that have been accepted by this WINS server. (For information about groups, see Table 8.10 later in this chapter.) |
Group Conflicts |
The number of conflicts encountered during registration of group names. |
Group Renewals |
The number of renewals received for group names. |
Configuring WINS Server and WINS Client Behavior
Use WINS Manager to configure WINS server management of WINS client mappings by using the configuration options in the WINS Server Configuration - (Local) dialog box. The configuration options allow you to specify time intervals that govern WINS client behavior as described in the following table.
Table 8.8 Configuration Options for WINS Server
Configuration option |
Description |
|---|---|
Renewal Interval |
Specifies how often a client reregisters its name. The default is six days. |
Extinction Interval |
Specifies the interval between when an entry is marked as released and when it is marked as extinct. The default is dependent on the renewal interval and, if the WINS server has replication partners, on the maximum replication time interval. Maximum allowable value is six days. |
Extinction Timeout |
Specifies the interval between when an entry is marked extinct and when the entry is finally scavenged from the database. The default is dependent on the renewal interval and, if the WINS server has replication partners, on the maximum replication time interval. The default is six days. |
Verify Interval |
Specifies the interval after which the WINS server must verify that old names it does not own are still active. The default is dependent on the extinction interval. The maximum allowable value is 24 days. |
The extinction interval, extinction timeout, and verify interval are derived from the renewal interval and the partner replication interval. The WINS server adjusts the values specified by the administrator to keep the inconsistency between a WINS server and its partners as small as possible.
You can run the Registry Editor program at the command prompt to configure a WINS server by changing the values of the Registry parameters listed in the following table.
Table 8.9 Advanced WINS Server Configuration Options
Configuration option |
Description |
|---|---|
Logging Enabled |
Specifies whether logging of database changes to J50.log files should be turned on. |
Log Detailed Events |
Specifies whether logging events is verbose mode. (This requires considerable computer resources and should be turned off if you are tuning for performance.) |
Replicate Only With Partners |
Specifies that replication occurs only with configured WINS pull or push partners. If this option is not checked, an administrator can ask a WINS server to pull or push from or to a non-listed WINS server partner. By default, this option is checked. |
Backup On |
Specifies that the database is backed up automatically when WINS Manager is stopped, except when the computer is stopped. |
Migrate On/Off |
Specifies that static unique and multihomed records in the database are treated as dynamic when they conflict with a new registration or replica. This means that if they are no longer valid, they are overwritten by the new registration or replica. Check this option if you are upgrading non-Windows NT-based computers to Windows NT. By default, this option is not checked. |
Starting Version |
Specifies the highest version ID number for the database. Usually, you do not need to change this value unless the database becomes corrupted and needs to start fresh. In such a case, set this value to a number higher than appears as the version number counter for this WINS server on all the remote partners that earlier replicated the local WINS server's records. WINS may adjust the value you specify to a higher one to ensure that database records are quickly replicated to other WINS servers. The maximum allowable value is 231 - 1. This value can be seen in the View Database dialog box in WINS Manager. |
Database Backup |
Specifies the directory where the WINS database backup is stored. If you specify a backup path, WINS automatically performs a full backup of its database to this directory every 24 hours. WINS uses this directory to perform an automatic restoration of the database in the event that the database is found to be corrupted when WINS is started. Do not specify a network directory. |
Managing Static NetBIOS Name-to-IP-Address Mappings
Static mappings are non-dynamic database entries of NetBIOS computer name-to-IP address mappings for computers on the network that are not WINS-enabled or special groups of network devices.
Click Static Mappings on the Mappings menu in WINS Manager to view, add, edit, import, or delete static mappings.
Once entered to the WINS server database, static name-to-IP-address mappings cannot be challenged or removed, except by an administrator who manually removes the specific mapping by using WINS Manager to remove the entry from the WINS server database. All changes made to the WINS server database by using WINS Manager take effect immediately.
Important: A DHCP reserved (or static) IP address for a unique name in a multihomed computer overrides an obsolete WINS static mapping if the WINS server advanced configuration option Migration On/Off is checked "on."
Static NetBIOS name mappings can be any of the types listed in the following table.
Table 8.10 Types of Static NetBIOS Name Mappings
Type option |
Description |
|---|---|
Unique |
A unique name that maps to a single IP address. Contrast with multihomed type. |
Group |
Also referred to as a "Normal" Group. When adding an entry to Group by using WINS Manager, you must enter the computer name and IP address. |
Domain |
A NetBIOS name-to-IP-address mapping that has 0x1C as the 16th byte. A domain group stores up to a maximum of 25 addresses for members. For registrations after the 25th address, WINS overwrites a replica address or, if none is present, it overwrites the oldest registration. |
Internet group |
Internet groups are user-defined groups that allow you to group resources, such as printers, for easy reference and browsing. The default 16th byte of an Internet group name is set equal to 0x20. An Internet group can store up to a maximum of 25 addresses for members. |
Multihomed |
A unique name that can have more than one address. This is used for multihomed computers. The maximum number of addresses that can be registered as multihomed is 25. For registrations after the 25th address, WINS overwrites a replica address or, if none is present, it overwrites the oldest registration. Contrast with Unique type. |
Managing the WINS Server Database
The WINS database under Windows NT Server 4.0 uses the performance-enhanced Exchange Server Storage engine version 4.0.
There is no built-in limit to the number of records that a WINS server can replicate or store. The size of the database is dependent upon the number of WINS clients on the network. The WINS database grows over time as a result of clients starting and stopping on the network.
The size of the WINS database is not directly proportional to the number of active client entries. Over time, as some WINS client entries become obsolete, and are deleted, there remains some unused space.
To recover the unused space, the WINS database is compacted. Under Windows NT Server 4.0, WINS server database compaction occurs as an automatic background process during idle time after a database update.
Because the WINS server database compaction occurs while the database is being used, you do not need to stop the WINS server to compact the database.
Note: Under Windows NT Server 3.51 or earlier, you must manually compact the WINS server database. See the topic "Compacting the WINS Server Database" in the section "Troubleshooting the WINS Server Database" later in this chapter. In most cases there is no need to manually compact the WINS server database under Windows NT Server 4.0. However, if you decide to do so, use this same procedure.
The following database files are stored in the \%systemroot%\System32\Wins directory.
Table 8.11 Microsoft WINS Server Database Files
File |
Description |
|---|---|
J50.log and J50#####.log |
A log of all transactions done with the database. This file is used by WINS to recover data if necessary. |
J50.chk |
A checkpoint file. |
Wins.mdb |
The WINS server database file which contains two tables: |
Winstmp.mdb |
A temporary file that is created by the WINS server service. This file is used by the database as a swap file during index maintenance operations and may remain in the %systemroot%\System32\Wins directory after a crash. |
Important: The J50.log, J50#####.log, Wins.mdb, and Winstmp.mdb files should not be removed or tampered with in any manner.
WINS Manager provides the tools you need to maintain, view, back up, and restore the WINS server database. For example, you use the WINS Manager to back up the WINS server database files, and this administrative task should be done when you back up other files on the WINS server.
Backing Up the Database
WINS Manager provides backup tools so that you can back up the WINS database. After you specify a backup directory for the database, WINS performs complete database backups every three hours, by installation default.
For specific instructions on how to back up and restore the WINS database, see the Help topic "Backing Up and Restoring the Database" in WINS Manager Help.
You should also periodically back up the Registry entries for the WINS server.
Scavenging the Database
Scavenging the WINS server database is an administrative task related to backing up the database. Like any database, the WINS server database of address mappings needs to be periodically cleaned and backed up.
The local WINS server database should periodically be cleared of released entries and old entries that were registered at another WINS server and replicated to the local WINS server, but for some reason did not get removed from the local WINS database when the entries were removed from the remote WINS server database.
This process, called scavenging, is done automatically over intervals defined by the relationship between the Renewal and Extinct intervals defined in the Configuration dialog box. You can also clean the database manually.
The following table describes the results of scavenging the WINS database.
Table 8.12 Scavenging the WINS Database
State before scavenging |
State after scavenging |
|---|---|
Owned active names for which the Renewal interval has expired |
Marked released |
Owned released name for which the Extinct interval has expired |
Marked extinct |
Owned extinct names for which the Extinct timeout has expired |
Deleted |
Replicas of extinct names for which the Extinct timeout has expired |
Deleted |
Replicas of active names for which the Verify interval has expired |
Revalidated |
Replicas of extinct or deleted names |
Deleted |
Troubleshooting WINS Servers
This section describes some basic troubleshooting steps for common problems. It also describes how to restore or rebuild the WINS database.
The following error conditions can indicate potential problems with the WINS server:
The administrator can't connect to a WINS server by using WINS Manager and receives an error message when attempting to do so.
The WINS client service or Windows Internet Name Service might be down and cannot be restarted.
Verifying WINS Service Status
The first troubleshooting task is to make sure the appropriate services are running.
To ensure that the WINS services are running
Use the Services option in Control Panel to verify that the WINS services are running.
In the Services dialog box for the client computer, "Started" should appear in the Status column for the WINS client service. For the WINS server itself, "Started" should appear in the Status column for the Windows Internet Name Service.
If a necessary service is not started on either computer, start the service.
Resolving Common WINS Errors
To resolve "duplicate name" error messages
Check the WINS database for the entries for that name that have a static name -to-IP-address mapping. If there is a static address record, delete it from the WINS server database.
Or, set the value of MigrateOn in the Registry equal to 1, so that the static records in the database can be updated by dynamic registrations (after the WINS server successfully challenges the old address).
To locate the source of "network path not found" error messages on a WINS client
Check the WINS database for the name. If the name is not present in the database, check whether the destination or target computer uses b-node name resolution. If so, add a static mapping for it in the WINS database.
If the computer is configured as p-node, m-node, or h-node, and if its IP address is different from the one in the WINS database, then it may be that its address changed recently and the new address has not yet replicated to the local WINS server. To get the latest records, ask the WINS server that registered the address to perform a push replication with propagation to the local WINS server.
To discover why a WINS server cannot pull or push replications to another WINS server
Use the ping utility to verify that each WINS server is running and can be connected to.
Ensure that each server is correctly configured as both a pull and push partner.
If ServerA needs to perform pull replications with ServerB, make sure it is a push partner of ServerB.
If ServerA needs to push replications to ServerB, it should be a pull partner of ServerB.
To determine the configuration of a replication partner, check the values under the Pull and Push keys in the Registry.
To determine why WINS backup fails
Make sure the path for the WINS backup directory is on a local disk on the WINS server.
WINS cannot back up its database files to a remote drive.
Troubleshooting the WINS Server Database
This section describes how to restore, rebuild, or move the WINS database. Also provided is a procedure for compacting the WINS database for Windows NT Server version 3.51 or earlier. (Microsoft WINS running under Windows NT Server version 4.0 provides automatic compacting of the WINS database.)
Restoring a WINS Server Database
If you have determined that the Windows Internet Name Service is running on the WINS server, but you cannot connect to the server using WINS Manager, then the WINS database is not available or has become corrupted. If a WINS server fails for any reason, you can restore the database from a backup copy.
You can use WINS Manager to restore the WINS database, or you can manually restore the database. For information about using WINS Manager to restore a WINS database, see the topic "Backing Up and Restoring the Database" in WINS Manager Help.
To restore a WINS database manually
Before starting, make a copy of the WINS database files.
In the \%Systemroot%\System32\Wins directory, delete the J50.log, J50#####.log, and Wins.tmp files.
Copy an uncorrupted backup version of Wins.mdb to the \Systemroot\System32\Wins directory.
Restart the WINS service on the WINS server, using the procedure in the next section.
Restarting and Rebuilding a Stopped WINS Server
In rare circumstances, the WINS server may not start or a STOP error might occur. If the WINS server is stopped, use the following procedure to restart it.
To restart a WINS server that is stopped
Turn off the power to the server and wait at least 15 seconds.
Turn on the power, start Windows NT Server, and then log on under an account with Administrator rights.
At the command prompt, type net start wins, and then press ENTER.
If the hardware for the WINS server is malfunctioning or other problems prevent you from running Windows NT, you must rebuild the WINS database on another computer.
To rebuild a WINS server
If you can start the original WINS server using MS-DOS, use MS-DOS to make backup copies of the files in the \Systemroot\System32\Wins directory.
If you cannot start the computer with MS-DOS, you must use the last backup version of the WINS database files.
Install Windows NT Server and Microsoft TCP/IP to create a new WINS server using the same hard drive location and \Systemroot directory.
That is, if the original server stored the WINS files on C:\Winnt35\System32\Wins, then the new WINS server must use this same path to the WINS files.
Make sure the WINS services on the new server are stopped, and then use the Registry Editor to restore the WINS keys from backup files.
Copy the WINS backup files to the \Systemroot\System32\Wins directory.
Restart the new, rebuilt WINS server.
Moving the WINS Server Database
You may find a situation where you need to move a WINS database to another computer. To do this, use the following procedure.
To move a WINS database
Stop the Windows Internet Name Service on the current computer, using the procedure in the preceding section.
Copy the \System32\Wins directory to the new computer that has been configured as a WINS server.
Make sure the new directory is under exactly the same drive letter and path as on the old computer.
If you must copy the files to a different directory, copy Wins.mdb, but do not copy the checkpoint (.chk) or log files.
Start the Windows Internet Name Service on the new computer.
The service automatically starts using the .mdb and .log files copied from the old computer.
Compacting the WINS Server Database
Windows NT Server version 4.0 is designed to automatically compact the WINS database, and you should normally not need to run this procedure. However, if you are using Windows NT Server version 3.51 or earlier, after WINS has been running for a while, the database might need to be compacted to improve WINS performance. You should compact the WINS database whenever it approaches 30 MB.
You can use the Jetpack.exe utility provided with Windows NT Server version 3.5 and 3.51 to compact a WINS database. Jetpack.exe is a command-line utility that is run in the Windows NT Server command window. The utility is found in the \%Systemroot\System32 directory.
The Jetpack.exe syntax is:
Jetpack.exe <database name> <temp database name>
For example:
> CD %SYSTEMROOT%\SYSTEM32\WINS > JETPACK WINS.MDB TMP.MDB
In the preceding examples, Tmp.mdb is a temporary database that is used by Jetpack.exe. Wins.mdb is the WINS database file. When Jetpack.exe is started, it performs the following sequential tasks:
Copies database information to a temporary database file called Tmp.mdb.
Deletes the original database file, Wins.mdb.
Renames the temporary database file to the original filename.
To compact the WINS database
In Control Panel, on the local WINS server computer, double-click Services.
Under Service, click Windows Internet Name Service.
Click Stop, and then click Close. (Alternatively, you can type net stop wins at the command prompt.)
Click Start, and then click Run.
In Open, type Jetpack.exe, and then click OK.
Restart the Windows Internet Name Service by using the Services dialog box.