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.
There are various errors associated with WINS that may be flagged in Event Viewer. The most common Event ID’s you’re likely to see include:
These errors deal with the inability to start the WINS service, find the WINS.mdb file/directory, and the inability to read the database header. In addition, you may see Event ID’s in the low-300 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.
More than one way
This article is aimed at curing WINS problems on a Windows 2000 server. That said, most of the approaches you’ll read about below should also work on an NT4 server. Note that you may only need to perform a couple of these steps to get WINS working again.
You should first try to restore a recent backup of WINS.mdb. You can do this either by restoring from a tape or, if you previously used the WINS tool to backup the database to another location, you can restore it using the same tool. Make sure you stop the WINS service before you begin, or else the Restore Database option will be grayed out when you right-click the WINS server. This is a neat, time-saving option, but only works if you backed up WINS from within the WINS console.
If restore attempts don’t work, you should attempt a database compaction, since 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 is 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 also 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:
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 to 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—otherwise 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 because it 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 then allow you to bring your WINS installation back online. (A full discussion of Winscl.exe is beyond the scope of this article, but you should refer to the Resource Kit and/or to Microsoft’s Knowledgebase for more information.) But remember, Winscl.exe is a resource hog and it can affect the availability of bandwidth. You should plan a adequate amount of time to run it.
The final approach is to stop the WINS service and then 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, and you’ll then need to check that all machines have re-registered 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 re-registrations 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 because with registration and authentication traffic being as they are—heaviest at the same times of the working day—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.
- Make sure your replication setup is sensible and makes the best use of available network resources.
- Test your WINS deployment plan and modify it, if needed.