ZDNet UK

CBS INTERACTIVE UK BUSINESS SITES:
atlarge.com
BNET UK
silicon.com
SmartPlanet.com
ZDNet.co.uk

You are here: ZDNet.co.uk > News > Communications

Network management Toolkit

Recover from a crashed WINS server

Peter Parsons Tech Republic

Published: 07 May 2003 08:59 BST

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.