Condividi tramite

WINS Best Practices

  • Articolo

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

Best practices

  • Use default settings to configure WINS servers.

    The preconfigured WINS settings 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 of the implications.

  • Avoid using static WINS entries for anything other than mission-critical servers.

    Static WINS entries require further administrative action to ensure their successful and intended use. However, static entries can be useful for specific purposes, such as to safeguard against WINS registration of the names used by critically important servers.

    For example, a static entry in WINS can be used to prevent other computers from taking over the use of the name of a critical server while that server is unavailable.

    The biggest disadvantage of using static WINS entries is that it complicates administration of name and address changes in your network. For example, if either the IP address or the computer name of a static WINS entry changes, you might have to manually update other configurations also, such as DHCP servers, DNS servers, end systems, and Lmhosts files.

    If you decide to use static WINS entries, the following are suggestions for configuring other WINS and DHCP service properties and avoiding common problems:

    • For each IP address used in static WINS mapping, consider using a corresponding client address reservation to reserve the IP address at the DHCP server. For more information, see Using client reservations.

    • If you use static WINS entries only to support temporary changes on your network, keep the default Overwrite unique static mappings at this server (migrate on) setting selected in the WINS console.

      When Overwrite unique static mappings at this server (migrate on) is selected, any temporary unique or multihomed static entries that you add can be challenged and dynamically updated by clients. An attempt later by any client to dynamically register a unique or multihomed name entry over an existing static entry of the same name results in a challenge process.

      In the challenge, the IP address in the static mapping is compared to any IP address that the named client attempts to dynamically register in WINS. If the two addresses are different, and the static IP address is determined to no longer be active or in use, the IP mapping can be migrated (from a static to dynamic mapping), and the IP address is updated in WINS.

    • If you use static WINS entries on a permanent basis, you can disable Overwrite unique static mappings at this server (migrate on). This prevents a dynamic WINS entry from overriding a static WINS entry that maps to the name and address of a critical server on your network.

  • Schedule consistency checking for an off-peak time.

    For the Windows Server 2003 family, WINS consistency checking is available through the WINS console. Periodically, you should use this feature to check the WINS database for consistency. However, consistency checking is network and resource intensive for the WINS server computer. For this reason, run WINS consistency checks during times of low traffic, such as at night or on weekends.

  • Select Push/Pull when configuring replication partners.

    In general, Push/Pull is a simple and effective way to ensure full WINS replication between partners. For most WINS installations, avoid the use of limited replication partnerships (Push Only or Pull Only) between WINS servers. In some large enterprise WINS networks, limited replication partnering can effectively support replication over slow wide area network (WAN) links. However, when you plan limited WINS replication, note the design and configuration when choosing to use limited replication partnerships.

  • For best results in WINS replication and convergence time, use a hub-and-spoke design model.

    Convergence time is a critical part of WINS planning. Convergence time is 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. To review the convergence time for your WINS network design, ask the following question for each of your WINS servers:

    How long does it take for a change in WINS data at one WINS server to replicate and appear at other WINS servers in the network?

    In most cases, the hub-and-spoke model provides a simple and effective planning method for organizations that require full and speedy convergence with minimal administrative intervention. For example, you can use this model for organizations with centralized headquarters or a corporate data center (the hub) and several branch offices (the spokes). A second, redundant hub (that is, a second WINS server in the central location) can increase the fault tolerance for WINS.

    For more information on how to configure a simple hub-and-spoke model, view the following graphic.

    WINS replication using hub-and-spoke mode

  • Use only as many WINS servers as you need.

    Too many WINS servers on a network can complicate any problems that arise. Be conservative when adding WINS servers to your network, using the least number of WINS servers to support all clients while maintaining acceptable performance from each server. If you are currently designing a WINS installation that includes more than 20 WINS servers, seek assistance from Microsoft Product Support Services before finalizing your plans.

    By default, most WINS clients first try to communicate using directed point-to-point datagrams with their configured primary WINS servers. One WINS server adequately supports a small routed internetwork. However, at least two WINS servers are recommended, to provide a fault-tolerant WINS installation.

    For more information on WINS server planning, see Planning WINS networks.

  • To maximize server performance, purchase hardware with optimal disk performance characteristics to handle WINS.

    WINS causes frequent and intensive activity on server hard disks. To provide for the best performance, consider RAID solutions that improve disk-access time when you purchase new hardware to use as a WINS server. You should view WINS as part of a full performance evaluation of the server. By monitoring system hardware performance in the most demanding areas of utilization (that is, CPU, memory, and disk input/output) you make the best assessments of when a WINS server is overloaded and should be upgraded.

  • When using multihomed servers, follow well-known considerations for configuring WINS and TCP/IP properties.

    When using multihomed WINS servers, it is best to configure all server IP addresses as replication partners with other WINS servers. Using a multihomed WINS server as a router or gateway between disjointed networks is not recommended.

  • Monitor and perform regular, offline compaction.

    Although manual compaction of the WINS server database is not as important for the Windows Server 2003 family as it was for earlier versions, it is still useful. For disk defragmentation and improved server disk performance, use offline WINS compaction regularly (such as monthly or weekly). Then, monitor any changes to the size of the server database file, Wins.mdb, which is located by default in the systemroot\System32\WINS\ folder.

    At each offline compaction, it is useful to check the file size of Wins.mdb both before and after compaction, to measure growth and reduction. This information can be helpful in determining the actual benefits to using offline compaction. Based on this information, you can then gauge how often to repeat offline compaction for measurable gains.

  • Perform regular backups of the WINS database.

    Besides using server tape backup of the WINS server computer, the WINS console offers a backup option which you can use to restore a server database if corruption occurs. For more information, see Troubleshooting WINS databases.

  • Configure clients with more WINS server IP addresses.

    In earlier versions of Windows NT, you could manually configure clients to use only a primary and secondary WINS server. For the Windows Server 2003 family, you can configure WINS clients (either manually or through DHCP) to use up to 12 WINS servers, two of which can be used to register clients. You can either statically configure this list (using the Internet Protocol (TCP/IP) Properties dialog box) or distribute it to DHCP clients (using option 44). A larger list of WINS servers gives clients additional fault tolerance for WINS when their configured primary WINS server is not available.

  • Use NBTSTAT -RR to register and troubleshoot client connectivity.

    For the Windows Server 2003 family, the NBTSTAT -RR command-line option forces immediate release and renewal of local client names. You can use this command-line option to refresh the client entries in WINS and replicate them to other replication partners without requiring a client reboot.

  • Configure each WINS server computer to point to itself.

    Each WINS server that you install on your network must register its own set of NetBIOS unique and group names in WINS. To prevent WINS service problems that can occur when a WINS record becomes split (that is, when names registered for a particular WINS server are owned by different WINS servers), each WINS server computer should point only to its own IP address when configuring its TCP/IP properties.