Managing the WINS Server Database

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 % SystemRoot %\System32\Wins, are described in Table 7.5.

Table 7.5 WINS Server Database Files

File

Description

J50.log and J50 xxxxx .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 %S ystemRoot %\System32\Wins after a crash.

caution-icon

Caution

The files J50.log, J50 xxxxx .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.

Backing Up the WINS Database

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.

Repairing a WINS Database

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 .

Using Replication to Restore Data

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

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.

Compacting the WINS Database

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 % SystemRoot %\ System32\Wins

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.

Scavenging the Database

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

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:

  • If the record in the local database is identical to the record pulled from the owner database, its time stamp is updated.

  • If the record in the local database has a lower version ID than the record pulled from the owner database, the pulled record is added to the local database and the original local record is marked for deletion.

  • If the records have the same version ID but a different name, the local record will be marked deleted and the pulled record will replace it.

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.