Planning WINS networks

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2, Windows Server 8 Beta

Planning WINS networks

Before you install WINS servers on your network, plan the following tasks:

  1. Determine the number of WINS servers that you need.

    One WINS server can handle NetBIOS name resolution requests for a large number of computers. However, consider the location of routers on your network and the distribution of clients in each subnet when you decide how many WINS servers are actually required.

  2. Plan the replication partnerships.

    Determine whether to configure WINS servers as either pull or push partners, and set partner preferences for each server. For more information, see Configuring WINS replication.

  3. Assess the impact of WINS communication traffic on slower links.

    Although WINS is designed to help reduce broadcast traffic between local subnets, it does create some traffic between servers and clients. This can be particularly important if you use WINS on routed TCP/IP networks.

    Also consider the effects of slower speed links (such as those typically used for wide area networks) on both replication traffic between WINS servers and NetBIOS registration and renewal traffic required for WINS clients.

  4. Assess the level of fault tolerance within your network for WINS.

    Consider how shutting down a WINS server (even temporarily) affects your network. Use additional WINS servers for failure recovery, backup, and redundancy.

  5. Test and revise your planned WINS installation.

    By testing the performance of your network installation of WINS, you can better identify potential problems before they occur. Use WINS server performance counters, which are available through the use of System Monitor.

Planning how many WINS servers to use

On a smaller network, a single WINS server can adequately service up to 10,000 clients for NetBIOS name resolution requests. To provide additional fault tolerance, you can configure a second computer running a Microsoft® Windows Server 2003 server operating system as a secondary (or backup) WINS server for clients. If you use only two WINS servers, you can easily set them up as replication partners of each other. For simple replication between two servers, one server should be set as a pull partner and the other as a push partner. Replication can be either manual or automatic, which you can configure by selecting the Enable automatic partner configuration check box on the Advanced tab of the Replication Partner Properties dialog box.

A larger network sometimes requires more WINS servers for several reasons including, most importantly, the number of client connections per server. The number of users that each WINS server can support varies with usage patterns, data storage, and the processing capabilities of the WINS server computer. Some enterprise network environments require more robust hardware to handle WINS activity, so you might benefit from upgrading the server computer.

When planning your servers, remember that each WINS server can simultaneously handle hundreds of registrations and queries per second. The WINS development and testing team compiled the following statistics as a profile of WINS performance during preliminary testing of Windows Server 2003 operating systems:

Average registrations/second

300

Average queries/second

350

These measurements were based on a server computer running WINS with no other additional services running and installed on currently available hardware. The specific hardware used includes the following: a single Intel Pentium II 350 MHz processor, 128 MB of RAM, and a standard IDE hard drive, which was used to store the WINS database. As a point of reference, WINS records data exchanged between servers and clients is typically small. On average, WINS records are about 40 bytes in size.

A conservative recommendation for large networks is to install one WINS server and a backup server for every 10,000 computers on the network. This reflects the previously suggested baseline performance and provides for large-scale power outages that could cause many WINS computers to restart simultaneously. Capacity is dependent upon server and network resources. Processor speed, available RAM, database storage space, and network resources can have a significant impact.

Two factors can enhance WINS server performance:

  • Using two installed processors on the computer running WINS. This can increase performance by almost 25 percent.

  • Using a dedicated high-performance disk drive, separate from the system drive, for the WINS database.

Notes

  • After you establish WINS servers on your intranet, you can adjust the renew interval, which is the time between a WINS client name registration and name renewal. By using this setting to reduce the number of registrations, you can tune server response time.

    For more information, see Modify name record settings and Modifying WINS server defaults.

  • The default WINS database location is systemroot\System32\Wins. If you choose to move the WINS database to another location, you can change the database path using the WINS console.

    For more information, see Set the WINS database path.

Planning for fault tolerance

To ensure you are planning a fault-tolerant WINS design, ask the following question for each server on your network: What happens to WINS if this server shuts down or if clients cannot reach it?

To help answer the question, consider the two common scenarios in which a WINS server could fail to perform in its role on a network:

  1. Hardware or power failures that require downtime for server repair or maintenance.

  2. A network link or router failure that isolates a WINS server from clients.

To plan for these, determine the maximum length of time any given WINS server could be out of service on your network, factoring in the length of both planned and unplanned outages.

Also consider what happens to your WINS clients if their primary WINS server is shut down. By maintaining and assigning secondary WINS servers for clients, you can reduce the effects of a single WINS server being offline.

Planning for network performance

Begin planning by estimating the amount of network traffic between WINS clients and WINS servers under normal conditions. You should predict and monitor the following:

  • NetBIOS names commonly registered by WINS clients.

  • WINS registration and renewal caused by daily startup of clients.

  • Roving users and their effect when moving within a routed network.

  • WAN links and their effect on replication performance and convergence.

When planning for WINS network performance, it is important to understand the types of traffic that WINS clients typically generate on a network, as listed below.

Daily start up of WINS clients

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 Windows NT® network client services running on the computer.

A WINS client running Windows XP usually registers more NetBIOS names than other WINS-enabled clients. The name registration requests generated by a computer running under these versions of Windows can include the following: File Server, Domain, the Replicator service, the Messenger service, the Computer Browser service, and additional network service names.

An active WINS client name registration in a WINS server database replicates to all pull partners configured on that WINS server. Eventually, the active name registration replicates to all WINS servers on the network.

When a WINS client is shut down at the end of a workday, it releases the name. When the computer is restarted at the beginning of next workday, the WINS client registers the name again with the WINS server and receives a new version ID. This new, active name registration entry replicates to the pull partners of the WINS server.

Assuming that this cycle occurs each day for each computer, the number of name registration entries replicated each day is approximately the number of computers that start each day multiplied by the number of NetBIOS names registered at each computer.

On large networks (50,000 or more computers), the biggest traffic load represents the name registration requests generated when WINS clients start on the network.

Planning considerations for routed WINS 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 can cause delays at peak times.

Roving or mobile users also present challenges for planning WINS in routed networks. When a user stops a computer and then moves it to another location--starting the computer on a different subnet with a different primary WINS server--the resulting changes can generate name-challenge traffic for WINS.

Typically, the name registration request is answered with a brief "Wait for Acknowledgment" message. Assuming the name being registered was previously replicated to the new server, it challenges the IP address currently in its database for this name with a brief query. When, as expected, there is no reply, the WINS server retries the challenge two more times for a total of three attempts. If all three attempts fail, the challenge is successful and the new WINS server updates the name registration entry in its database with the new IP address, incrementing the version ID. The new version ID indicates that the entry must be replicated from its new owner--the new WINS server--to other WINS servers on the network.

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, also consider the network topology and the design or configuration of the network routers. In some cases, it is not possible to predict the traffic load on a specific network router because the routers are configured to autonomously route traffic based on factors other than traffic load.