Windows Internet Name Service
Windows Internet Name Service |
|
Keeping WINS servers up and functioning prevents WINS clients from reverting
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.
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.
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.
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.
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.
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:
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 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.
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.