Recovering WINS

Techniques and tools for repairing your WINS servers

In "Recovering DHCP," September 2001, InstantDoc ID 21841, I discussed the importance of Windows 2000's and Windows NT's DHCP services on DHCP-enabled networks. I provided tips, techniques, and tools for performing maintenance and disaster-recovery procedures on DHCP servers. Now I want to provide the same information for another essential network service: WINS.

As is the case with most recovery operations, your ability to successfully recover from disasters related to crucial services such as WINS depends on how well you've prepared for disaster. Even the best system-recovery and data-recovery experts can't do much if they don't have a good backup or if they don't know anything about a service's original configuration. Therefore, you need to take proactive steps so that your WINS implementation is prepared for the worst.

Proactive WINS Measures
Name resolution is crucial not only for properly resolving NetBIOS names to IP addresses but also for the functionality of your entire Windows network. (For more information about name resolution, see "Navigating Name Resolution, Part 1," June 2000, InstantDoc ID 8695, and "Navigating Name Resolution, Part 2," July 2000, InstantDoc ID 8931.) Without name resolution, a Windows network is fairly useless. Despite its legacy NetBIOS-centric nature, WINS is equally important on Active Directory (AD)—enabled Win2K networks, most of which use clients and applications that rely on NetBIOS.

If your organization depends on WINS, you need to perform important WINS maintenance regularly. Proper maintenance can help ensure uptime for WINS and your network as a whole. As part of your daily administrative regimen, examine the System event log on all WINS servers for WINS-related entries. If this job involves many servers and many log entries, you'll probably want to consider using event-log filtering or third-party event-log management utilities to view only WINS servers and WINS-related events. You'll also want to make sure that you've set appropriate WINS logging levels for your network environment. By default, Win2K and NT enable WINS logging in the System event log, which you can use Event Viewer to view.

If you're experiencing problems with WINS and need more detailed information than the event logs provide, you can use the WINS management console on individual WINS servers to enable extended logging features. In Win2K's WINS management console, click the Advanced tab of the WINS server's Properties dialog box and select Log detailed events to Windows event log, as Figure 1 shows. In NT's WINS management console, you select the WINS server, choose Server, Configuration, click Advanced, and select the Log Detailed Events option.

Enabling Consistency Checking
A little-known feature—in both the Win2K and NT versions of WINS—is the ability to periodically verify the WINS database's consistency. During a database consistency check, the system pulls all records from each WINS record owner listed in the current server database—including records of other WINS servers that are indirect (i.e., not directly configured) replication partners. The system then compares all records pulled from remote WINS server databases to the records that reside in the local WINS server's database. In the comparison, the system applies two consistency tests:

Figure 2, page 34, shows the option for enabling the consistency-checking feature in Win2K. If you use NT's WINS Manager, you'll need to modify the registry to enable this feature. The registry parameters that configure WINS reside under the HKEY_LOCAL_MACHINESYSTEM CurrentControlSetWinsParameters subkey. You can also create a subkey called ConsistencyCheck under the Parameters key. This optional subkey causes WINS to perform periodic database consistency checks. Table 1, page 34, shows the ConsistencyCheck subkey's valid registry values, as well as their default data types, default values, ranges, and descriptions.

Use care if you enable consistency checking through the registry because consistency checks have a potential drawback: They can consume substantial resources on both the WINS server and the network. If you add the ConsistencyCheck subkey, make sure that you set its contained values so that you minimize the load on the server and network. To determine a proper consistency-checking configuration (e.g., proper intervals, maximum simultaneous records), consider network topology, number of WINS servers, number of WINS clients, and the number and bandwidth capacities of the WAN links that separate your organization's WINS servers.

Keep in mind that you should schedule consistency checks so that they don't consume excessive server or network resources—for example, after hours when network usage is at its lowest. Figure 3 shows an example of a WINS server's registry with the ConsistencyCheck subtree added.

A hint: If you use Win2K's WINS management console (e.g., from a Win2K administrative workstation), you can use the Win2K console against your NT 4.0 WINS servers to access the GUI-based method of enabling database consistency checking. Still another method of initiating consistency checking on NT WINS servers is to use the Microsoft Windows NT Server 4.0 Resource Kit's Winscl utility's CC command. (For information about Winscl, see Mark Minasi, This Old Resource Kit, "WINSCL," August 1998, InstantDoc ID 3689.) To learn about a related feature of the WINS management console—the Verify Name Records option—see the sidebar "Verifying Registered Name Records."

Compacting with Jetpack
The WINS and DHCP services (in Win2K and NT) use the same Microsoft Jet database technology for their underlying databases. You can use Jetpack, a Microsoft-provided tool, to proactively compact your WINS database. Regularly compacting this database not only keeps its size reasonable but also alerts you to potential corruption—if Jetpack finds major inconsistencies in the database, the utility returns an error message. Jetpack's syntax is

jetpack  

where database.mdb is the database you want to compact and tempdatabase.mdb is the temporary database file to use during the compacting process. For example, to compact your WINS database, you would set the WINS database directory as the current directory (%systemroot%system32wins), stop WINS, then issue the command

jetpack wins.mdb tmp.mdb

This command instructs Jetpack to use tmp.mdb as a temporary database during the compacting operation.

To compact the database, Jetpack copies records from the primary database to the temporary database, then deletes the original database and renames the temporary database to the original database's name (i.e., wins.mdb). For more information about Jetpack, see the Microsoft article "How to Use Jetpack.exe to Compact a WINS or DHCP Database" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q145881). For a list of Jetpack's error codes, see the Microsoft article "Jetpack Error Codes for Windows 2000 and Windows NT 4.0" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q172570). If you're running WINS in a clustered environment, you'll need to use a different procedure for running Jetpack. For details, see the Microsoft article "How to Use the Jetpack Utility on a Clustered WINS/DHCP Database" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q283251).

One of Jetpack's functions is to repair inconsistencies and corruption, but it might not fix every problem. If Jetpack can't fix a certain problem, you'll probably need to restore a known good copy of the WINS database or rebuild it from scratch.

Backing Up WINS
You probably already back up your WINS database as part of your daily network backup routine, but you might want to consider maintaining additional backups of your WINS databases. Secondary backups give you an additional "ace in the hole" for recovery purposes and can also save you if your regular backups are corrupted or unusable.

By default, WINS automatically backs up its database every 24 hours, but you can also instruct WINS to create additional backups when WINS is terminated (e.g., by an administrator or network-management utility). In the Microsoft Management Console (MMC)—based Win2K version of the WINS management utility, you'll find a Back up database during server shutdown option on the General tab of the WINS server's Properties dialog box. To access the capability in NT, select the WINS server, choose Server, Configuration, click Advanced, and select the Backup On Termination check box, as Figure 4 shows. This option causes WINS to automatically back up its database (wins.mdb) and two related files (j500000xx.log and wins.pat). An important note about this option: This automated backup doesn't occur during server shutdown, even though the system terminates the service as usual on shutdown.

You can also perform WINS backups manually. You might be backing up your WINS server daily, but unless your backup software supports open-file backups—only a few products offer such support—your backups might be skipping the WINS database. For this reason, you should back up the WINS database while WINS is stopped. If you have a backup program that doesn't support open files, you might want to run a prebackup job (e.g., a script, a batch file) that stops WINS and a postbackup job that restarts the service. If you've selected the Backup On Termination option, the system will automatically back up the database when you stop the service. Or you can stop WINS, then use a backup utility or file-copy operation to back up the three important WINS files—wins.mdg, j500000xx.log, and wins.pat—to a location of your choosing.

If you're running the WINS management utility from the server that you're backing up, you can also use the management console's built-in backup feature to accomplish the backup. In the utility's Win2K version, the option appears on the menu that you access by right-clicking a server name in the left contents pane; in the NT version, the option is available on the Mappings menu. To use this option, you must enable logging on the WINS server. Don't confuse this logging option with the event-logging and advanced event-logging options that I discussed earlier—this option relates not to event logging but rather to whether WINS writes database transactions to the J50.log file before committing them to the database.

Where the Backup Things Are
Whenever you back up WINS, WINS places the database backup files into a two-level-deep subdirectory called wins_bakew (under the currently configured WINS database backup path). Under NT, the backup folder's root defaults to %systemroot%system32winsbackup, thus making the full path of the default location %systemroot%system32winsbackupwins_bakew.

However, under Win2K, the backup path's root defaults to the %systemroot%system32wins folder—not to a backup subfolder. The resulting confusion is compounded if other administrators have set up some servers with custom backup paths or if you've upgraded servers from NT to Win2K. Also, if you attempt to manually back up a WINS database on a server that doesn't have an entry for its database backup path, the WINS management utility will prompt you to enter the path. To determine the current location of your WINS backups, you'll need to examine each WINS server configuration. Microsoft recommends that you use the path %systemroot%system32wins. In any case, always use local disks and pathnames in the backup destination path—avoid using network disks or Universal Naming Convention (UNC) pathnames.

Restoring a Wigged-Out WINS
If you discover WINS problems—whether through reports from administrators or users, through errors or garbage record entries in the WINS management console, or through critical errors in your WINS server's System log—you can take steps to start resolving the problem. If the problem is simply that certain WINS records appear to be garbage entries or are somehow invalid, try deleting the offending records from the database. For information about deleting and tombstoning WINS records, see Alistair G. Lowe-Norris, "Tombstones Mark the Coming of the End for WINS," March 1999, InstantDoc ID 4881.

If the problem is more severe and you have specific error codes or event IDs from the System event log, start by searching for the particular error or ID at the Microsoft Support Knowledge Base at http://support.microsoft.com. You might discover clues to the nature of the problem that save you from wrongly assuming that your WINS database is corrupted.

If you're convinced that your WINS database is corrupted, try using the Jetpack utility to confirm your suspicions. If Jetpack confirms corruption—or if you need to bring back an alternative version of the WINS database for other reasons—your next step is to restore the database.

First, stop WINS on the server you're restoring. You can now use one of several methods to accomplish the relatively simple task of restoring a WINS database. One method is to run the WINS management utility from the WINS server you want to restore and use the Restore Local Database option.

You can also restore the WINS database files manually or from backup files that reside elsewhere (e.g., in another directory, on removable storage). Follow these steps to do a manual restore:

The Microsoft articles "Recovering a WINS Database From Other Backup Sources" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q235609) and "Restoring a Windows 2000 WINS Database from Other Backup Sources" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q244810) describe this procedure in more detail for Win2K and NT, respectively.

Although you can use other methods to restore the WINS database, this procedure is the one that Microsoft supports and recommends. Before you perform any restore operation, you should back up the WINS database files in case you need to recover them later—for example, if you discover that the files you're restoring are corrupted.

Be Proactive
You don't need to be a hapless victim, waiting for your WINS servers to stop functioning. By following this article's recommendations, you can significantly increase the reliability of your WINS environment and reduce the possibility of WINS-related downtime.