Chapter 8 - Managing MS WINS Servers
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
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:
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:
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:
Figure 8.1 WINS Servers and WINS Clients in a Routed TCP/IP Network
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:
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
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.
Figure 8.2 Enabling the WINS Service on a WINS Client
The WINS-enabled client communicates with the WINS server to:
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 registration request. 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.
The following figure illustrates the flow of name registration request and name response.
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).
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.
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.
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.
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:
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:
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.
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.
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.
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:
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:
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.
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.
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.
Figure 8.9 WINS Server Replication in a T Network Configuration
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.
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.
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.
You can display additional statistics by clicking Detailed Information on the Server menu. The following table describes these detailed information statistics.
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.
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.
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.
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.
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.
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:
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
Resolving Common WINS Errors
To resolve "duplicate name" error messages
To locate the source of "network path not found" error messages on a WINS client
To discover why a WINS server cannot pull or push replications to another WINS server
To determine why WINS backup fails
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
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
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
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
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>
> 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:
To compact the WINS database