Best Practices for WINS Servers

  • Article

Keeping WINS servers up and functioning prevents WINS clients from reverting to B-node name resolution and flooding a network with broadcast requests. Here are a few suggestions for keeping servers operating efficiently.

Use the Default Configuration

The default settings of WINS, set when the service is first installed, provide the optimal configuration for most conditions and should be used in most WINS network installations. If you modify the default settings, be sure that the need to do so is clear and necessary, and that you understand all the implications.

Minimize the Number of WINS Servers

Using too many WINS servers can complicate network problems, so be conservative when adding WINS servers to your network. Use the minimum number of WINS servers to support all your clients while maintaining acceptable performance.

When planning your servers, remember that each WINS server can simultaneously handle hundreds of registrations and queries per second. In part, this is because the data exchanged between WINS servers and WINS clients is typically small. The average WINS record is about 40 bytes.

WINS network traffic during client registration can be much less than that of DHCP, which uses client broadcasts to discover servers. By default, most WINS clients first send directed point-to-point datagrams to the primary WINS servers.

In general, avoid deploying large numbers of WINS servers unless they are strictly necessary. Limiting the number of WINS servers minimizes WAN traffic related to WINS replication, provides good NetBIOS name resolution, and reduces administrative problems without sacrificing functionality. To design a WINS installation that includes more than 20 WINS servers, seek assistance from Microsoft Product Support Services.

Requests to WINS servers are directed datagrams, meaning that WINS requests are routed. Therefore, one WINS server is adequate for a network of 10,000 nodes, although to provide fault tolerance, at least two WINS servers are recommended. Because the data exchange between WINS servers and clients is typically about 40 bytes in size, and WINS communicates using directed datagrams, a single WINS server may be enough for very small networks.

Based on the number of CPUs in the computer, WINS determines how many threads to create to handle client queries; it creates one thread per CPU. Each name registration takes about 40 milliseconds with logging enabled. If logging is disabled, registrations are much faster, but this configuration introduces the risk of losing the last few updates to the WINS database when a failure occurs.

Use High-Performance Disk Hardware

WINS causes frequent and intense activity on server hard disks. To provide the best performance, consider RAID-based solutions that improve disk access time when you purchase hardware for a WINS server. You should include WINS when evaluating the performance of a server. By monitoring system hardware performance in the most demanding areas of utilization (CPU, memory, and disk I/O), you make the best assessments of when a WINS server is overloaded and should be upgraded.

Add Network Interface Hardware Carefully

Be careful when adding more network adapters to a computer running Windows 2000. You can increase the reliability of mission-critical systems while adding the hardware simply by reducing the number of services running on the computer. Many of the services running on a mission-critical computer (such as a primary domain controller) can be offloaded to other computers and then returned to the upgraded original computer once the change is complete.

Configure Each Server to Point to Itself

Each WINS server you install on your network must register in WINS its own set of unique and group NetBIOS names. WINS service problems can occur when registration and ownership of a WINS record become split—that is, when names registered for a particular WINS server are owned by different WINS servers. To prevent these problems, configure each WINS server as its own primary and secondary WINS servers.

WINS Server Fault Tolerance

To prevent a WINS failure from affecting server communications, you may want to consider using an LMHOSTS file to provide secondary name resolution in the event of a WINS failure. While these files are not a recommended solution, in rare circumstances they may provide an effective stopgap measure. LMHOSTS files must be tightly managed because changes in the NetBIOS environment will not automatically update static name files.

To use LMHOSTS for name resolution, you must make a correctly configured LMHOSTS file available for locating Windows 2000 computers when WINS servers fail. A master LMHOSTS file should contain static IP address mappings for Windows 2000 computers. This file should be distributed to each Windows domain using one of the following three options:

  • The typical Windows 2000 LMHOSTS file contains a universal naming convention (UNC) path to a central file. By pointing to a single file, you need only maintain one copy of the LMHOSTS file.

  • For computers without Windows 2000, you can schedule a job using the scheduler service to distribute the master LMHOSTS file to the required servers automatically. The winat command from the Windows   2000 Resource Kit may make this task easier. Send the file to the primary domain controller (PDC) and one backup domain controller (BDC) on each domain.

  • The least efficient option is to manually copy the file to each server and client that needs it, or to update each LMHOSTS file locally. This may be still be worthwhile for a network with a single WINS server.

Once the LMHOSTS file is prepared and distributed, if a server fails, the local LMHOSTS file of each server references the master LMHOSTS file on the PDC sharepoint. If you use an #INCLUDE statement, the central LMHOSTS file is also available from alternate servers.

Do Not Use Extended Characters

Do not use extended characters in NetBIOS names, especially the underscore ( _ ) and the period ( . ). The underscore character is converted to a dash in DNS host names. For example, NTServer_1 becomes NTServer-1, leading to failure of name resolution of a name that may, in fact, be recorded in the DNS files.

Align the Lease and Refresh Periods for DHCP and WINS

When you configure a network to use both DHCP and WINS, set the DHCP lease period to be roughly equal to or greater than the WINS renewal period. This prevents a situation in which the WINS server fails to notice that a DHCP client releases a DHCP-assigned IP address; the client cannot send a WINS renewal request if the client fails to renew its IP address. If another computer is assigned that IP address before the WINS server notes the change, the WINS server mistakenly directs requests for the address to the new client.