Windows Internet Name Service
Windows Internet Name Service |
|
With dynamic compaction and the WINS management console, WINS databases are much easier to maintain in Windows 2000, but they still require certain administrative practices and regular upkeep.
Perform Periodic Consistency Checking For Windows 2000, WINS consistency checking is available from the WINS management console. Use this feature periodically to check the WINS database for consistency.
Consistency checking consumes a great deal of network and computer system resources because the WINS server must replicate itself for each owner whose records are being checked for consistency. For this reason, check the consistency of WINS database records during times of low network traffic, such as at night or on weekends.
Perform Regular Offline Compaction Dynamic database compaction occurs on WINS servers as an automatic background process during idle time after a database update. This dynamic database compaction occurs while the database is in use; you do not need to stop the WINS server for dynamic compacting.
Although dynamic compacting greatly reduces the need for offline compaction, it does not fully eliminate the need for it. Offline compaction using the JETPACK utility reclaims more space than dynamic compaction and should be performed once a month for networks with 1,000 or more WINS clients. For smaller networks, manual compaction may be useful if only performed every few months.
Although manual compaction of the WINS server database is not as important for Windows 2000 Server as it was for earlier versions, it is still useful. You should perform monthly or weekly offline compaction for disk defragmentation and improved disk performance. Monitor any changes to the size of the server database file, Wins.mdb, which is located in the directory
Checking the file size of Wins.mdb both before and after compaction allows you to measure growth and reduction. This information helps you determine the actual benefits to using offline compaction. Based on this information, you can gauge how often to repeat offline compaction for measurable gains.
Perform Regular Backups to Ease Restoration In addition to tape backups of the WINS server computer, the WINS management console offers a backup option that allows you to restore a WINS database after the database file has been corrupted. For more information on restoring data after corruption or loss of the WINS server database, see "Restoring Data" in the "Troubleshooting" section of this chapter.
You can also restore the database through a replication partner. If the WINS data is current on the replication partner, you can use this data to update the failed server. Two registry entries control this feature, InitTimeReplication and InitTimePause. InitTimeReplication is in the following subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
\Wins\Partners\Pull and Push
The value of this entry is 1 by default, which causes WINS to replicate with the partner at the time specified in the key. The InitTimePause entry is stored in the following subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
\Wins\Parameters
It tells WINS to pause while the replication takes place.
Use the Scavenge Function The scavenge function is an automatic function of Windows 2000 WINS. It releases records old enough to be released, removes extinct records, and verifies records after the verification interval passes.
Using the default WINS configuration in Windows 2000, scavenge runs after WINS has been running for 72 hours, or half the renewal interval. If WINS is stopped and restarted before 72 hours have elapsed, the 72-hour window to the next scheduled scavenge is reset. If the WINS service is stopped on a daily basis, scavenging cannot take place.
To verify that scavenging is occurring, on the WINS server properties page, on the Advanced tab, select the Log Detailed Events to Event Log check box. This feature adds overhead processing, and should be used only when verifying the scavenging process. If scavenging is not taking place, establish a scavenge policy as part of your WINS database maintenance.
Avoid Using Static WINS Entries Static WINS entries require administrative action to assure their successful and intended use. However, static entries can be useful for specific purposes, such as protecting registration of names used by critically important servers.
For example, you can add a static entry to the WINS database to prevent other computers from registering the name of a critical server while that server is down. Reserving names in this manner prevents anyone from hijacking the server name (via DHCP) by registering another computer with the same name on the network. If the server is not responding at the time, a WINS server issuing a name challenge does not receive a response indicating that the name is in use, and the address is taken over by the new computer.
The biggest disadvantage of using static WINS entries is that it complicates administration of name and address changes in your network. For example, if either the IP address or the computer name of a static WINS entry changes, you might need to update other configurations, such as DHCP servers, DNS servers, end systems, LMHOSTS files, and so forth.
If you do use static WINS entries, use reservations to minimize the impact on DHCP. For each IP address used in static WINS mapping, use a corresponding client address reservation to reserve the IP address at the DHCP server. Also, if you do use static entries, carefully monitor and track the servers where these entries are added (the owning servers). Ideally, all static entries should only be entered on a single server. This makes later removal of these entries easier. For more information about address reservations, see "Dynamic Host Configuration Protocol" in this book.