WINS doesn't automatically back up its configuration-related Registry keys. WINS stores all the Registry entries that relate to a WINS server's operation in two important subkeys of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\WINS. First, WINS stores all of a WINS server's configuration options in the Parameters subkey. These server options, which you set through WINS Administrator's Server, Configuration menu, include the renewal, extinction, and verify intervals and the setting that defines whether WINS performs a backup on termination. The other important subkey of WINS is the Partners subkey, in which WINS stores information about the server's current replication partners. Within the Partners subkey, you'll see push and pull subkeys for each of the server's replication partners; you set update counts and time intervals for replication within these push and pull subkeys.
Because the WINS Registry information is fairly static on most servers, you don't need to back up the WINS Registry keys as frequently as the DHCP Registry keys. Unless your WINS server has many replication partners, re-creating these keys from scratch isn't terribly painful. As long as you document your configuration options on your WINS servers, recovery of a failed WINS server need not rely on a restored Registry. However, if you choose to back up these keys, use a simple tool such as regedit.exe to export the WINS key to a Registry file, which you can quickly import when you need to restore the server.
Tools for Performing Regular Maintenance
Jetpack is the only must-have tool I've found for DHCP database maintenance, but several tools in Microsoft Windows NT Server 4.0 Resource Kit and SP4 let you perform periodic maintenance tasks on your WINS servers. I recommend that you install the most recent supplement to the resource kit—Supplement Three as of this writing—on your WINS server.
WINSCHK. The WINSCHK resource kit tool performs multiple functions for checking the health of your WINS servers. You can type WINSCHK at a command prompt to see the available options.
The first option lets you periodically poll all your replicated WINS servers for a specific set of NetBIOS names. You can use WINSCHK to verify that crucial names are always available in your WINS database. For example, a domain's DOMAIN[1C] record is important for clients attempting to locate a domain controller for authentication. If a WINS server is missing this record, you might have problems. The first WINSCHK option takes two text files as input: servers.txt, which contains the IP address for a WINS server in your replicated environment, and names.txt, which contains the list of records you want to search for on each WINS server. WINSCHK looks for the names.txt entries on all servers that contain replicas of the WINS database on the server that servers.txt specifies. Names.txt entries need to have the following form:
<Name>*sixteenth-byte type
For example, to verify that the Master and Resource domains have the record 1C available, create a names.txt file that looks like
MASTER*1C
RESOURCE*1C
Note that you must capitalize the domain names.
The second WINSCHK option checks version consistency on your WINS servers. This option returns a table of record version numbers for each owner database that each replica knows about. The table gives you an at-a-glance view of whether replication is working properly.
The third option lets you monitor communications between your replicating WINS servers and warns you if your primary and secondary WINS servers are down at the same time. WINSCHK writes the results of the third option to a file called monitor.log.
WINSCHK's final option checks WINS partners' replication configuration. This option ensures that you have configured both push and pull replication and have set the Update Count value for each pair of replication partners. (For more information about the Update Count setting, see David Lafferty, "Setting Your WINS Strategy," October 1997.)
WINSCL. This powerful resource kit utility lets you do everything from deleting ranges of records from a WINS database to manually running a consistency check against a WINS server. (For more information about WINSCL, see Mark Minasi, "WINSCL," August 1998.) Supplement Three improves WINSCL and makes the tool less finicky about syntax. However, WINSCL is no longer as necessary as it was before SP4, because Microsoft incorporated the utility's biggest benefit—its ability to delete individual WINS records—into SP4's WINS Administrator tool.
WINS Administrator. WINS Administrator is your primary interface with the WINS database. In SP4, the tool lets you delete individual records or groups of records from a database and the database's replicas. When you select Mappings, Show Database in SP4's WINS Administrator, you'll see a new Delete Mapping button. If you select one or more records in the database and click Delete Mapping, you'll see a dialog box that asks whether you want to delete or tombstone the selected records. If you choose Delete, WINS deletes the records from the current database, regardless of which server originally replicated the record. If you select TombStone, WINS deletes the records from the WINS server and propagates that deletion order to all the server's replication partners. You must initiate the tombstone operation from the WINS server that originally registered the record. (For more information about WINS Administrator's new tombstoning feature, see Alistair G. Lowe-Norris, "Tombstones Mark the Coming of the End for WINS," page 99, and Mark Minasi, "Service Pack 4," page 87.)
A Little Work Up Front Goes a Long Way
A little bit of proactive monitoring and maintenance helps keep your WINS and DHCP infrastructures humming. If these services are important to your environment, spend the time necessary to get a handle on your databases before you hear about problems from users.