WINS Features and Functions

WINS in Windows 2000 still behaves very much like WINS in Windows NT. The section provides an overview of some old functionality you may have forgotten about, as well as some of the new functions that you should be aware of.

WINS Proxy – Just like in NT 4, you can configure a Windows 2000 system as a WINS proxy. A WINS proxy is a system that listens for NetBIOS broadcasts on the network and forwards those broadcasts to a WINS server for resolution. WINS proxies are used when a subnet contains systems that use NetBIOS but do not support WINS, allowing these systems to use NetBIOS naming and communicate across a TCP/IP internetwork. Like in NT 4, a WINS proxy is configured via a registry setting, so you’ll need to add the setting EnableProxy with a value of 1 to the path HKLM\System\CurrentControlSet\Services\NetBT\Parameters

Burst Handling – At certain times during the day, WINS servers may take on a heavy load of registrations, such as when people boot up their PCs when they get into the office at around 9am, or after a network failure. WINS in Windows 2000 has the ability to handle these high-impact times using burst handling (this also existed in NT versions with SP 3 and above). Turned on by default, the WINS server handles requests normally until the burst-queue reaches 500 requests (the medium setting). After it reaches 500 queued registration requests (which can be changed via the WINS console as shown below), the server begins responding positively to clients immediately with a TTL of 5 minutes for the first 100 clients above 500, increasing the TTL by an additional 5 minutes for every 100 clients thereafter. This basically forces the clients to fully reregister with the WINS server once the load had decreased on the server.

Manual Tombstoning – The manual tombstoning feature in Windows 2000 exists to help ensure the consistency of WINS databases in environments where WINS replication is used. In effect, it allows you to manually tombstone records that you wish to have invalidated (not deleted) in WINS, such that the information will be replicated to all other WINS servers. This feature exists because a deleted record (one removed from the WINS database entirely) could be re-replicated to a server, since other servers would think that the record was still valid. The tombstoned record would then replicate and cause that record to be tombstoned on other WINS servers, and so on. The record would eventually be deleted from the WINS database once the tombstone lifetime expires.

Verify Database Consistency – Be careful with this one. WINS in Windows 2000 has a feature available called ‘Verify Database Consistency’ which allows you to verify that the information found in a given WINS database is correct and up-to-date. In effect, the feature forces the local WINS server to check all records replicated from other WINS servers and compare them with the current local versions found on the WINS server that owns the record. The local WINS server will then update the information as necessary. The problem with this command is that it is very resource intensive in large environments – it is suggested that it only be down in periods of low activity, such as after working hours.

Database Backup – In order to have the WINS database backed up automatically, you need to specify a backup path on the server’s General property tab. Once provided, the database will be backed up to this location every 3 hours. You can also specify that the database be backed up automatically when the WINS service stops (as it would on shutdown, for example). The General tab is shown below.

Persistent Connections – Another new feature in Windows 2000, WINS replication partners can now maintain (and do by default) persistent connections with one another. That means that less time and resources are used on the WINS server, since the necessary connection is always established between partners. This can be turned off via the Replication Partners properties (see the screen shot in the WINS replication section)

WINS Users Group – This group is created after WINS is installed, and membership allows a user read-only access to information stored in the WINS console, a useful feature for first-line network support.

Author: Dan DiNicolo

Dan DiNicolo is a freelance author, consultant, trainer, and the managing editor of He is the author of the CCNA Study Guide found on this site, as well as many books including the PC Magazine titles Windows XP Security Solutions and Windows Vista Security Solutions. Click here to contact Dan.