WINS and DHCP Preventive Maintenance

By Darren Mar-Elia

Take steps now to keep your NT 4.0 network running smoothly

Article from Windows NT Magazine

If you are or ever were a user (i.e., victim) of Windows NT 3.5x's Windows Internet Naming Service (WINS) and Dynamic Host Configuration Protocol (DHCP), you know that regular maintenance tasks such as periodic jetpacking of the database and checking of log files and event logs are crucial to keeping these important infrastructure services functioning. Even if your firm uses the best networking practices, NT 3.5x's WINS and DHCP quirks probably periodically cause you stress.

Life is much better for administrators of NT 4.0's WINS and DHCP. Proper network maintenance can keep DHCP and WINS running fairly smoothly in NT 4.0, and Service Pack 4 (SP4) provides tools that help in the administration of these services. Several tools and practices can help you proactively manage WINS and DHCP within an NT 4.0 enterprise.

Jet Files

WINS and DHCP rely on Microsoft's Jet database engine to store information about their services. WINS stores the records that clients register and the records it replicates from other WINS servers in a Jet database, which is usually in %systemroot%\system32\wins. WINS servers keep important configuration options that relate to their replication partners and their name registration behavior in the HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \WINS Registry subkey.

DHCP uses a Jet database to keep track of which IP addresses the server has leased. DHCP relies heavily on the Registry for storage of scope definitions (the ranges of IP addresses DHCP can distribute) and reservations (the address assignments DHCP hard-codes using machines' media access control—MAC—addresses). DHCP stores its scope and configuration information in the HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet Services\DHCP-Server Registry key. The DHCP database is in %systemroot%\system32\dhcp. WINS and DHCP servers hold several files that relate to each service's database.

Wins.mdb or dhcp.mdb. The wins.mdb file is the main database file that holds records for WINS. Dhcp.mdb is the main database file that holds DHCP records.

J*.log. Within the DHCP or WINS directory, you'll find at least two J*.log files, which are transaction files for the database. When you change a WINS or DHCP database, the software writes your change to the current log file. You can verify this fact by viewing the WINS or DHCP database directory. The directory's files with the most recent modification dates are the log files; the database files reflect the date and time when the WINS or DHCP service last terminated gracefully (i.e., via a shutdown or termination of the service).

When you first install these services, you'll probably see a J50.log file. J50.log is the current transaction log for the database. Each log holds a maximum of 1MB. When the current log fills, the DHCP or WINS service copies it to a backup log. The software usually calls these backup logs J50xxxxx.log, in which xxxxx is a sequential hexadecimal number. DHCP usually generates more frequent log file backups than WINS generates, because DHCP generates a new series of logs (and backups) every time it backs up the DHCP database. By default, DHCP backs up its database hourly.

J*.chk. You use J*.chk to checkpoint the log (i.e., to keep track of which J*.log transactions DHCP or WINS has written to the database). J*.chk is useful when the database needs to back out of a set of transactions during a recovery, because the file keeps track of which transactions the software has committed since it last wrote to the database.

Res1.log and res2.log. These files are placeholders; they reserve space for future logs in case the WINS or DHCP disk partition becomes full. Res1.log and res2.log are usually each 1MB. They guarantee that you have enough space to create log files for DHCP and WINS to properly operate.

Dhcpsrvlog.xxx. When you select the DHCP configuration option that enables logging, DHCP creates a file in the database directory that details each client request for a new (or renewed) address and the server's response to the request. On DHCP servers without SP4, the log is one file named dhcpsrvlog. SP4 writes a different log file for each day of the week using the filename extension to designate the file's logging day (e.g., dhcpsrvlog.fri). Dhcpsrvlog files are simple text files that you can view in Notepad.

Care of the Jet Databases

DHCP and WINS Jet databases can be sources of much grief for NT administrators. As DHCP and WINS databases grow, they become less efficient at servicing requests and more susceptible to corruption. If a database becomes corrupted, the WINS or DHCP server simply stops servicing requests. You can usually find evidence of database corruption within NT's system event log, which you use Event Viewer to view. When a crucial event log error suggests that your database is corrupted, your choices for recovery are limited and probably painful.

WINS is especially problematic, because it is very active in medium to large environments. During business hours, WINS servers are always working with the database. If the servers aren't registering or renewing client computers' name registrations, they're replying to name queries. And every time users log on to a machine that uses WINS, the system registers their username with that machine in WINS. (Look for records in the form username[03h] in your WINS database to see these username registrations.) In addition, large NT infrastructures might contain several WINS servers that replicate their databases to one another. As a result of all this activity, WINS databases are subject to fragmentation. As WINS writes and rewrites records to the database, wins.mdb often becomes fragmented and actually grows in size as a result of the fragmentation. Over time, the database can become quite large if you don't care for it properly.

Fragmentation isn't as prevalent in DHCP databases because DHCP lease renewals tend to be much less frequent than WINS renewals and because the DHCP database doesn't replicate among multiple servers on the same network. DHCP leases typically don't change much over time, although the extent to which leases change varies, depending on the leases' duration.

In NT 3.5x, defragmentation of WINS and DHCP databases requires periodic manual use of NT's jetpack utility, a tool that defragments Jet databases. (For more information about jetpack, see "Implementing Enterprisewide WINS," November 1997.) NT 4.0 removed the manual jetpacking requirement by upgrading the Jet database formats to support online defragmentation. Under most circumstances, your WINS and DHCP databases will remain free from fragmentation. However, you can run jetpack manually on an NT 4.0 system if you need to.

Note that SP4 changes the format of the DHCP Jet database to increase database performance, but this change makes SP4 databases incompatible with Service Pack 3 (SP3) databases. If you move your DHCP database from one NT 4.0 server to another, make sure that both servers run SP4 or neither server runs SP4.

Best Practices for Maintaining WINS and DHCP

Although DHCP and WINS in NT 4.0 are much better about keeping themselves clean than they were in NT 3.5x, you need to perform some regular tasks to ensure that these important services remain operational. Companies that ignore these servers for long periods of time amaze me, because these services' functions are usually crucial to networks' infrastructure.

Monitor database size. Although NT 4.0's DHCP and WINS automatically jetpack themselves, their databases sometimes become corrupted, which prevents the jetpack utility from functioning properly. If you don't keep DHCP and WINS databases in check, they can grow to enormous sizes. A typical database for a midsize company (i.e., a company with about 1000 devices on its network) is in the 3MB to 4MB range. However, I have seen corrupted databases that are larger than 250MB. When a database reaches that size, it's often irreparable, and you have to restore it from backup. The easiest way to keep the database from growing too large is to write a simple batch script that periodically checks the size of wins.mdb or dhcp.mdb on all your WINS and DHCP servers. For example, you can use

dir \\<wins_server1>\c$\winnt\system32\wins\wins.mdb>> c:\logs\winssiz.log

to keep track of the size of your WINS database if your system partition is on your C drive and you have rights to c$, the administrative share. If you run this script from an administrative workstation that has rights to the file system on all your WINS servers, you can pipe the output to a text log file and analyze it periodically. I recommend running such a check about once a week. If you have multiple WINS servers replicating their databases with one another, you can run this script to test each server's database size. If the databases are not roughly the same size, you know your DHCP or WINS service has a problem.

Monitor space on the services' partition. An obvious next step in database maintenance is to make sure the disk partition on which your databases live has plenty of space for the databases to grow. If WINS or DHCP resides on the database's system partition and the partition begins to run out of space, you'll probably notice many problems before the partition is completely empty and your database has no more space. However, using Performance Monitor or a proactive systems management tool to track available space on your DHCP and WINS database partitions is a good idea.

Check WINS consistency. You can set up your WINS servers to periodically check their data's consistency with their replication partners' data. The purpose of this checking is to verify that replication is working correctly and that records are the same on every partner. A WINS server checks replicated data's consistency by comparing the version ID of every replicated record in its WINS database with the version ID of the corresponding record on the partner on which the record originated. To enable consistency checking, you need to manually add a Registry key and values, as the Microsoft article "New WINS Registry Entries In Windows NT 4.0" at https://support.microsoft.com/default.aspx?scid=kb;en-us;154410 describes. This operation is CPU-intensive, so you probably don't want your servers checking consistency during business hours.

Back up the database. Backing up all the DHCP and WINS files is always important. DHCP simplifies database backup management, because the DHCP service automatically backs up its database files hourly by default. DHCP uses these files when the service can't read the main database file, and you can use these files to recover the database. (For information about DHCP backup and recovery, see Mark Minasi, "DHCP Recovery," page 167.)

WINS backups require more work than DHCP backups require. To set WINS to back up its database, you must select a WINS server in WINS Administrator, then choose Server, Configuration. The WINS Server Configuration dialog box will appear, as Screen 1 shows. Click Advanced, and select the Backup On Termination check box. You can enter a path in the Database Backup Path text box to specify which directory WINS stores the backup files in. If you don't enter a path, WINS backs up the database and log files to %systemroot%\system32\wins\backup\wins_bak\new.

Screen 1

Note that WINS backs up the database only when the WINS service terminates gracefully (either through a manual shutdown of the service or as part of a system shutdown). Shutting down and restarting the WINS service periodically during off hours helps ensure that you always have a recent backup available.

Monitor event and DHCP logs. WINS and DHCP write their status information to NT's system event log. In addition, DHCP keeps the running dhcpsrvlog.xxx text log of its activities. Monitoring these logs periodically is a good idea, because critical errors often appear before problems cause the DHCP or WINS service to stop functioning. I recommend using a proactive log-capturing tool, such as NetIQ's AppManager or Mission Critical Software's SeNTry, to periodically poll your event logs for errors.

Back up the Registry. DHCP automatically backs up the HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \DHCPServer keys and values to the dhcpcfg file in the %systemroot%\system32\dhcp\backup directory. Dhcpcfg is a Registry hive that you can restore to your DHCP server's Registry if disaster strikes. Retaining the information in the Registry keys that dhcpcfg backs up is important, because DHCP stores your scope definitions in those keys. If a large DHCP server fails and administrators can't restore dhcpcfg, they might have to re-create hundreds, if not thousands, of Registry keys. (For more information about dhcpcfg, see Mark Minasi, "DHCP Recovery," page 167.)

WINS doesn't automatically back up its configuration-related Registry keys. WINS stores all the Registry entries that relate to a WINS server's operation in two important subkeys of HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet Services\WINS. First, WINS stores all of a WINS server's configuration options in the Parameters subkey. These server options, which you set through WINS Administrator's Server, Configuration menu, include the renewal, extinction, and verify intervals and the setting that defines whether WINS performs a backup on termination. The other important subkey of WINS is the Partners subkey, in which WINS stores information about the server's current replication partners. Within the Partners subkey, you'll see push and pull subkeys for each of the server's replication partners; you set update counts and time intervals for replication within these push and pull subkeys.

Because the WINS Registry information is fairly static on most servers, you don't need to back up the WINS Registry keys as frequently as the DHCP Registry keys. Unless your WINS server has many replication partners, re-creating these keys from scratch isn't terribly painful. As long as you document your configuration options on your WINS servers, recovery of a failed WINS server need not rely on a restored Registry. However, if you choose to back up these keys, use a simple tool such as regedit.exe to export the WINS key to a Registry file, which you can quickly import when you need to restore the server.

Tools for Performing Regular Maintenance

Jetpack is the only must-have tool I've found for DHCP database maintenance, but several tools in Microsoft Windows NT Server 4.0 Resource Kit and SP4 let you perform periodic maintenance tasks on your WINS servers. I recommend that you install the most recent supplement to the resource kit—Supplement Three as of this writing—on your WINS server.

WINSCHK. The WINSCHK resource kit tool performs multiple functions for checking the health of your WINS servers. You can type WINSCHK at a command prompt to see the available options.

The first option lets you periodically poll all your replicated WINS servers for a specific set of NetBIOS names. You can use WINSCHK to verify that crucial names are always available in your WINS database. For example, a domain's DOMAIN[1C] record is important for clients attempting to locate a domain controller for authentication. If a WINS server is missing this record, you might have problems. The first WINSCHK option takes two text files as input: servers.txt, which contains the IP address for a WINS server in your replicated environment, and names.txt, which contains the list of records you want to search for on each WINS server. WINSCHK looks for the names.txt entries on all servers that contain replicas of the WINS database on the server that servers.txt specifies. Names.txt entries need to have the following form:

<Name>*sixteenth-byte type

For example, to verify that the Master and Resource domains have the record 1C available, create a names.txt file that looks like

MASTER*1C

RESOURCE*1C

Note that you must capitalize the domain names.

The second WINSCHK option checks version consistency on your WINS servers. This option returns a table of record version numbers for each owner database that each replica knows about. The table gives you an at-a-glance view of whether replication is working properly.

The third option lets you monitor communications between your replicating WINS servers and warns you if your primary and secondary WINS servers are down at the same time. WINSCHK writes the results of the third option to a file called monitor.log.

WINSCHK's final option checks WINS partners' replication configuration. This option ensures that you have configured both push and pull replication and have set the Update Count value for each pair of replication partners. (For more information about the Update Count setting, see David Lafferty, "Setting Your WINS Strategy," October 1997.)

WINSCL. This powerful resource kit utility lets you do everything from deleting ranges of records from a WINS database to manually running a consistency check against a WINS server. (For more information about WINSCL, see Mark Minasi, "WINSCL," August 1998.) Supplement Three improves WINSCL and makes the tool less finicky about syntax. However, WINSCL is no longer as necessary as it was before SP4, because Microsoft incorporated the utility's biggest benefit—its ability to delete individual WINS records—into SP4's WINS Administrator tool.

WINS Administrator. WINS Administrator is your primary interface with the WINS database. In SP4, the tool lets you delete individual records or groups of records from a database and the database's replicas. When you select Mappings, Show Database in SP4's WINS Administrator, you'll see a new Delete Mapping button. If you select one or more records in the database and click Delete Mapping, you'll see a dialog box that asks whether you want to delete or tombstone the selected records. If you choose Delete, WINS deletes the records from the current database, regardless of which server originally replicated the record. If you select TombStone, WINS deletes the records from the WINS server and propagates that deletion order to all the server's replication partners. You must initiate the tombstone operation from the WINS server that originally registered the record. (For more information about WINS Administrator's new tombstoning feature, see Alistair G. Lowe-Norris, "Tombstones Mark the Coming of the End for WINS," page 99, and Mark Minasi, "Service Pack 4," page 87.)

A Little Work Up Front Goes a Long Way

A little bit of proactive monitoring and maintenance helps keep your WINS and DHCP infrastructures humming. If these services are important to your environment, spend the time necessary to get a handle on your databases before you hear about problems from users.

About the Author

Darren Mar-Elia dmarelia@earthlink.net has more than 10 years of experience in network and systems administration and design. He is responsible for Windows NT architecture in a firm for which he helped design a nationwide NT 4.0 deployment.

The above article is courtesy of Windows NT Magazine.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

International rights.