Steps to take to recover a crashed WINS server

WINS is a vital component of Windows NT servers in large network environments. Although Microsoft went a long way toward eliminating WINS in Windows 2000, it's still there. When your WINS server goes bad, you need a way to restore the WINS database. Here's how.

Update: See also Troubleshoot WINS on Windows 2000

Identifying errors

Various errors are associated with WINS that may be flagged in Event Viewer. The Event IDs you're most likely to see include:

• 4318
• 4224
• 7022
• 7023
• 37

These errors deal with the inability to start the WINS service, find the WINS.mdb file/directory, or read the database header. In addition, you may see Event IDs in the low-300s range, which indicate that the WINS database is trying to repair itself and/or has successfully done so.

Some things to try first

Before proceeding with a repair operation, you need to check that the root of your problem doesn't lie with insufficient disk space. If the WINS database lives on a volume with low disk space, this fact alone may cause WINS to stop working properly, and it may cause corruption.

If restore attempts don't succeed, you should attempt a database compaction. A fragmented database is more likely to become corrupted. Much as with DHCP, the WINS database should be compacted periodically, especially if it exceeds 25 to 30 MB. Remember that it's quite possible for a WINS database to be large because of the numerous types of records WINS holds for each machine. Dynamic compaction is performed in WINS, but you still need to make periodic file size checks. Use the Jetpack.exe utility on the Windows 2000 CD for the compaction. You'll need to drop to the command line and type in the following commands, pressing [Enter] after each line:

CD %SYSTEMROOT%\SYSTEM32\WINS
NET STOP WINS
JETPACK WINS.MDB TMP.MDB
NET START WINS

Notice that you need to stop the WINS service first. If you don't, you'll likely corrupt the database further or compaction will fail. Jetpack.exe compacts the database file WINS.MDB, renaming it TMP.MDB. Jetpack.exe also deletes the old WINS.MDB and then renames the compacted file TMP.MDB to its new name, WINS.MDB. You can use any filename other than TMP.MDB, but make sure that you don't choose a name already used by another file in the same directory. If you do, it'll get overwritten and your day really will be shot. Only after the compacted file is saved as WINS.MDB can you restart the WINS service.

If all else fails

If your WINS database appears corrupted beyond repair, you can try to fix it using a utility called Winscl.exe, found in the Windows 2000 Server Resource Kit. It's a powerful utility that lets you manually inspect and correct errors in a WINS database. For instance, Winscl.exe can completely remove entries that are corrupt and, in doing so, may allow you to bring your WINS installation back online. (A full discussion of Winscl.exe is beyond the scope of this article, but you can refer to the Resource Kit and/or to Microsoft's Knowledge Base for more information.) It's important to keep in mind that Winscl.exe is a resource hog and it can affect the availability of bandwidth. You should plan an adequate amount of time to run it.

The final approach is to stop the WINS service and simply delete all the files in the WINS directory - but not the directory structure. When you restart the WINS service, all new files will be generated. Then, you'll need to check that all machines have reregistered themselves. You'll also need to delete the WINS files on push-pull partners so that all data is new when replication starts. Some administrators prefer this approach, especially in a smaller environment, because debugging WINS can take a long time. In large environments, this approach can be problematic and can eat up bandwidth, due to the greater number of client reregistrations and server replication actions that are required.

Best practices may help you avoid problems

Here's a list of some of the best practices you can follow to avoid many of these WINS problems from the outset:

• Assess how many WINS servers you need to service the number of clients in your environment. One WINS server can service 5,000 machines, but this may not be the best setup for your situation.
• Fault tolerance is crucial, as with any network service. Make sure you can replicate the WINS database to enough servers in case of failure. The aim is seamless service provision.
• Place WINS services on computers other than domain controllers. Registration and authentication traffic is heaviest at the same times of the working day, so a domain controller may become overworked.
• Avoid using static entries in WINS, because they need management. WINS is an automated service to save you time, so take advantage of that.
• Perform regular backups from the WINS console. This will speed up recovery. Make sure you also have offsite backups.
• Estimate the loads WINS places on network bandwidth, especially if you have a slow WAN link. Refer to the Resource Kit for more information on WINS' bandwidth needs.
• Use the WINS console to perform regular consistency checks. This is resource- and bandwidth-intensive, so schedule the activity outside of office hours if possible.
• Ensure that your replication setup is sensible and makes the best use of available network resources.
• Test your WINS deployment plan and modify it, if needed.