Recovering WINS

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:

1. If the record in the local database is identical to the record pulled from the owner database, the system updates the record's timestamp.
2. If the record in the local database has an earlier-version ID than the record pulled from the owner database, the system adds the pulled record to the local database and marks the original local record for deletion.

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_MACHINE\SYSTEM\ CurrentControlSet\Wins\Parameters 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.

   Previous  [1]  2  3  Next