Windows Internet Name Service
Windows Internet Name Service |
|
The Windows 2000 WINS database uses the performance-enhanced Extensible Storage Engine, an updated version of the generic storage engine that serves both Microsoft Exchange 5.5 servers and Windows 2000 servers. This database imposes no limit to the number of records that a WINS server can replicate or store. The size of the database depends on the number of WINS clients on the network, but it is not directly proportional to the number of active client entries. As inactive entries proliferate, the WINS database grows, and many WINS client entries become obsolete. Eventually, these entries clutter the database.
To recover the unused space, the WINS database is compacted. In Windows 2000, WINS server database compaction occurs as an automatic background process during idle time after a database update. Because the database compaction is also dynamic, you do not need to stop the WINS server to compact the database; this is also known as online compaction. However, while WINS performs regular online compaction, this reduces but does not eliminate the need for offline compaction. The WINS service will still need to be stopped periodically for offline compaction. For more information, see "Managing the WINS Server Database" later in this chapter.
The database files, stored in the directory
Table 7.5 WINS Server Database Files
| File | Description |
|---|---|
| J50.log and J50xxxxx.log | A log of all transactions done with the database. This file is used by WINS to recover data if necessary. |
| J50.chk | A checkpoint file, used when the WINS database starts up to determine whether the last shutdown was clean and all databases are consistent. If not, the checkpoint file helps determine from what log file to begin recovery. |
| Wins.mdb | The WINS server database file, which contains two tables, an IP address–to–owner ID mapping table, and a name–to–IP address mapping table. |
| Winstmp.mdb | A temporary file created by the WINS service. The database uses it as a swap file during index maintenance operations. It might remain in the directory |
Caution
The files J50.log, J50xxxxx.log, Wins.mdb, and Winstmp.mdb should not be removed or tampered with in any manner.
The WINS management console provides the tools you need to maintain, view, back up, and restore the WINS server database. For example, you use the WINS management console to back up the WINS server database files.
The WINS management console provides backup tools so that you can back up the WINS database. After you specify a backup directory for the database, WINS performs complete database backups every three hours, by installation default. For specific instructions on how to back up and restore the WINS database, see the Windows 2000 Server Help. You should also periodically back up the registry entries for the WINS server.
If your WINS database becomes corrupted, you can use various options to renew its integrity. In cases in which the corruption is limited to a specific set of records, you can repair them by selectively increasing or decreasing the starting version number used by the WINS server that owns the affected records. If you choose this method, you can adjust the starting version used by the server to force replication of uncorrupted WINS records, which removes the affected records from other WINS servers.
If the corruption can't be repaired, you can delete the WINS database and entirely restore it from a backup (assuming that one exists). You can use the WINS backup feature in the WINS management console to make backup copies of the WINS database.
Sometimes you can repair WINS database corruption by increasing the highest version number of the local WINS server database; to do this, you must increase the value specified in the Starting Version Count box in the WINS server preferences. Then, the next time WINS restarts, the specified WINS server updates its local version number for any records it owns.
Increasing the value of the starting version number on the owning WINS server forces replication for all records owned by the specified WINS server to other remote partner WINS servers during the next replication cycle.
Note that you can set the value of the starting version number only to a value higher than the existing highest version number used by any locally owned records on the selected server. If there are no locally owned WINS records for the server, you can only set the starting version number to a higher number than the current starting version number count. Once a higher value is set, you cannot lower the value without first deleting the local WINS database and reinstalling WINS on the server computer.
Also, values entered and used for Starting Version Count are interpreted as hexadecimal numbers. WINS might adjust the value you specify to a higher value to ensure that database records are quickly replicated to other WINS servers. The maximum value that the WINS management console accepts as a valid starting number is a hexadecimal value of FFFFFFFF.
If the time to WINS convergence is low (that is, changes are replicated among the WINS servers quickly), the preferred method of restoring a local WINS server database is to use a replication partner to restore data after corruption. This method is most effective if the WINS data is mostly up to date on the replication partner.
The easiest way to restore a local server database is to replicate data back from a replication partner. Two registry entries control this feature: InitTimeReplication and InitTimePause. InitTimeReplication is an entry in the following subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
\Wins\Partners\Pull and Push
The value of this entry is 1 by default and causes WINS to replicate with the partner at initialization time. InitTimePause is an entry in the WINS Parameters subkey that tells WINS to pause while the replication takes place. These entries are discussed in this section.
Name: InitTimeReplication
Data Type: REG_DWORD
Description: If the value of InitTimeReplication is set to 1, the default value, the WINS server pulls replicas of new database entries from its partners when the system is initialized or when a replication-related parameter changes; if the value is 0, replication occurs only as often as specified by the value set for Replication interval in the Replication Partner Properties dialog box (shown in Figure 7.10).
Name: InitTimePause
Data Type: REG_DWORD
Description: The value set here determines whether WINS starts in a paused state and remains in that state until its first replication is complete. If the value of InitTimePause is 1, WINS starts in a paused state; if the value is 0, the default value, WINS does not start in a paused state. In the paused state, WINS does not accept any name registrations, releases, or queries. WINS remains in the paused state until it has replicated with its partners or until its first replication attempt has failed. Note that if the value of InitTimePause is set to 1, then InitTimeReplication (in the Pull partners subkey) should be set to 1 or be deleted from the registry.
In Windows 2000 Server, the WINS service performs dynamic Jet compaction of the WINS database while the server is online. This reduces the need to use Jetpack.exe for offline compaction. Therefore, this procedure might not be as critical now as it was in the past for WINS and DHCP servers running earlier versions of Windows NT Server.
Windows 2000 Server includes the Jetpack.exe utility so that it can be used to compact the WINS and other Jet databases (such as DHCP) when those databases are offline. Microsoft recommends you use Jetpack.exe to compact a Jet database periodically whenever the database grows beyond 30 megabytes or more in size.
Use the Jetpack.exe command-line tool to perform offline compaction. The correct syntax for Jetpack.exe is:
jetpack <database name> <name of the temporary database>
Suppose that you have a temporary database with the file name Tmp.mdb, and the WINS database has the file name Wins.mdb. To compact the database in this example, you enter the following commands:
cd
net stop wins
jetpack wins.mdb tmp.mdb
net start wins
Jetpack compacts the WINS database; first it copies database information to the temporary database file, Tmp.mdb, then it deletes the original WINS database file, Wins.mdb. Finally, it renames the temporary database file to the original file name, Wins.mdb.
Like any database, the WINS server database becomes littered with junk entries over time and must periodically be cleaned and backed up. Scavenging the WINS server database takes care of this. It is usually performed at the same time as regular backups.
Scavenging updates the name state of WINS database entries, clearing the local WINS server database of released entries. It also clears away entries replicated from a remote WINS server that were not removed from the local WINS database when they were removed from the remote database. This scavenging process occurs automatically over intervals defined by the relationship between the renewal and extinction intervals defined in the Configuration dialog box. You can also find this dialog box on the Name Record tab of the Server Properties page, and the configuration page is shown in Figure 7.8.
Table 7.6 describes the effects of scavenging on WINS database entries.
Table 7.6 State of WINS Database Entries Before and After Scavenging
| State before scavenging | State after scavenging |
|---|---|
| Owned active name for which the renewal interval has not expired | Unchanged |
| Owned active name for which the renewal interval has expired | Marked released |
| Owned release name for which the extinction interval has not expired | Unchanged |
| Owned released name for which the extinction interval has expired | Marked extinct |
| Owned extinct name for which the extinction timeout has not expired | Unchanged |
| Owned extinct name for which the extinction timeout has expired | Deleted |
| Replica of extinct name for which the extinction timeout has expired | Deleted |
| Replica of active name for which the verification interval has not expired | Unchanged |
| Replica of active name for which the verification interval has expired | Revalidated |
| Replica of extinct or deleted name | Deleted |
Scavenging maintains the correct state information in the database by examining each record the WINS server owns, comparing its time stamp to the current time, then changing the state of those records whose state has expired (changing a record's state from active to released, for example).
Scavenging occurs on a preset schedule. The scavenging timer starts when the server starts up and is equal to half the renewal interval. Because of this, the WINS service should not be stopped or restarted before half the renewal interval has passed, or scavenging will not occur. Scavenging first occurs after half of the renewal interval has elapsed. During the first scavenging, all scavenging actions are performed except one: the deletion of the tombstones. Tombstones are not deleted until at least three days have elapsed since startup of the server, to allow sufficient time for their replication. Scavenging recurs at one-half the renewal interval (or can be initiated manually).
Scavenging follows the algorithm shown in Figure 7.7.
Get records owned by self
If Current Time > Time Stamp
Change State
Active -> Released
Released -> Tombstone
Tombstone -> Delete from database
Get replica Tombstones
If Current Time > Time Stamp
Delete record from database
Get Active replicas
If Current Time > Time Stamp
Verify with owner that record still exists
If exists
Time Stamp = Current Time + Verification Interval
Else
Delete record from database
Figure 7.7 WINS Scavenging Algorithm
The results of this scavenging algorithm are also detailed in Table 7.6.
Consistency checking helps maintain database integrity among WINS servers in a large network. When consistency checking is initiated using the WINS management console, WINS pulls all of the records directly from each owning server in its database, including any servers for which it has stored local records that are not among its replication partners.
All records pulled from remote databases are compared to records in the local database using the following checks for consistency:
Note that if a WINS database is extremely large, the consistency checking process might be network-intensive. In Windows 2000, consistency checking can be performed using the WINS management console, by checking the Enable Periodic Database Consistency Checking box on the Name Record tab of the server properties page.