Over the years, some organizations have been able to retire this service, but others that still maintain pre-Windows 2000 clients or legacy NetBIOS applications have had a lot of trouble getting this service retired once and for all. For some, keeping WINS functioning properly, especially on very large networks, has proven to be quite challenging. If the following best practices are followed, a dramatic improvement in the function of WINS is dramatically realized.
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. You should not have more than 20 WINS servers in your replication design.
You should have at least two WINS servers
One WINS server is adequate for a network of 10,000 nodes. Therefore, for most instances, no more than two servers are needed so that fault tolerance is included as part of your design.
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, each WINS server computer should point only to its own IP address when configuring its TCP/IP properties.
Avoid using static WINS entries
Static WINS entries require further administrative action to ensure their successful and intended use. They may be difficult to purge out of the database when they are no longer needed, especially in a very complex, distributed design.
Schedule consistency checking for an off-peak time
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.
For best results in WINS replication, use a hub-and-spoke design model
Convergence time is a critical part of WINS. 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 maximize server performance, use hardware with optimal disk performance
WINS causes frequent and intensive activity on server hard disks. To provide for the best performance, consider RAID solutions that improve disk-access time.
Avoid using multi-homed WINS servers
Avoid using WINS servers with more than one network interface. WINS servers with more than one IP address can cause problems with replication and registration.
Perform routine offline compaction
Using JETPACK, it is important to compact the WINS database regularly (monthly). This will ensure that the database does not grow too large with empty space and degrades performance. Monitor any changes to the size of the server database file, Wins.mdb, which is located by default in the systemroot\System32\WINS\ folder. The size of the database should not grow over 40 MB in size.
Perform regular backups of the WINS database
The WINS console offers a backup option that you can use to restore a server database if corruption occurs.
Prevent unwanted WINS owners from replicating into your database
In a delegated design where different WINS infrastructures replicate with each other, such as in the case of organizations that partner with each other, you will lose control over which WINS servers participate in the overall replication model. For example, your WINS replication partner may not manage their WINS infrastructure using best practices. Their old, stale data will replicate into your database. BLOCK or ALLOW only the WINS servers that should be participating in the WINS replication design. You can configure these settings via the Replication Partners, Properties, Advanced Tab.
Delete Stale WINS Owners
Old, retired WINS servers somehow manage to remain in your WINS database. Right click “Active Registrations”, Delete Owners… Remove any old WINS servers that you know no longer participate in the replication cycle. Following these best practices should help you manage a healthy WINS infrastructure. Once your network no longer maintains pre-Windows 2000 systems and legacy NetBIOS applications, you will be able to start retiring the WINS infrastructure.
title: “Best Practices When Running Wins On Your Network” ShowToc: true date: “2022-12-18” author: “Casey Morales”
Over the years, some organizations have been able to retire this service, but others that still maintain pre-Windows 2000 clients or legacy NetBIOS applications have had a lot of trouble getting this service retired once and for all. For some, keeping WINS functioning properly, especially on very large networks, has proven to be quite challenging. If the following best practices are followed, a dramatic improvement in the function of WINS is dramatically realized.
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. You should not have more than 20 WINS servers in your replication design.
You should have at least two WINS servers
One WINS server is adequate for a network of 10,000 nodes. Therefore, for most instances, no more than two servers are needed so that fault tolerance is included as part of your design.
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, each WINS server computer should point only to its own IP address when configuring its TCP/IP properties.
Avoid using static WINS entries
Static WINS entries require further administrative action to ensure their successful and intended use. They may be difficult to purge out of the database when they are no longer needed, especially in a very complex, distributed design.
Schedule consistency checking for an off-peak time
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.
For best results in WINS replication, use a hub-and-spoke design model
Convergence time is a critical part of WINS. 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 maximize server performance, use hardware with optimal disk performance
WINS causes frequent and intensive activity on server hard disks. To provide for the best performance, consider RAID solutions that improve disk-access time.
Avoid using multi-homed WINS servers
Avoid using WINS servers with more than one network interface. WINS servers with more than one IP address can cause problems with replication and registration.
Perform routine offline compaction
Using JETPACK, it is important to compact the WINS database regularly (monthly). This will ensure that the database does not grow too large with empty space and degrades performance. Monitor any changes to the size of the server database file, Wins.mdb, which is located by default in the systemroot\System32\WINS\ folder. The size of the database should not grow over 40 MB in size.
Perform regular backups of the WINS database
The WINS console offers a backup option that you can use to restore a server database if corruption occurs.
Prevent unwanted WINS owners from replicating into your database
In a delegated design where different WINS infrastructures replicate with each other, such as in the case of organizations that partner with each other, you will lose control over which WINS servers participate in the overall replication model. For example, your WINS replication partner may not manage their WINS infrastructure using best practices. Their old, stale data will replicate into your database. BLOCK or ALLOW only the WINS servers that should be participating in the WINS replication design. You can configure these settings via the Replication Partners, Properties, Advanced Tab.
Delete Stale WINS Owners
Old, retired WINS servers somehow manage to remain in your WINS database. Right click “Active Registrations”, Delete Owners… Remove any old WINS servers that you know no longer participate in the replication cycle. Following these best practices should help you manage a healthy WINS infrastructure. Once your network no longer maintains pre-Windows 2000 systems and legacy NetBIOS applications, you will be able to start retiring the WINS infrastructure.
