Recovering DHCP

Techniques and tools for repairing this crucial network service

Users logging on, file servers serving, applications running—music to the ears of administrators and network users. Isn't life great when the network is running smoothly? Life is so great that you can easily forget how quickly your utopian computing world can come crashing down when a crucial network service fails. In a matter of minutes, your smoothly functioning masterpiece of connectivity can dissolve into a living nightmare.

DHCP is one of a set of services (others include Active Directory—AD—and WINS) that every Windows 2000, Windows NT, and mixed-environment network uses to provide essential functions to network users and applications. Knowing DHCP's vulnerabilities and being familiar with recovery techniques and tools will help you quickly recover when DHCP isn't functioning properly. In many cases, successful recovery also depends on you taking some necessary preparatory steps. To be sure that you're prepared to administer CPR should DHCP ever need it, let's review DHCP recovery.

DHCP: A Blessing and a Curse
In NT 3.5, Microsoft introduced an implementation of a new IP address­assignment protocol called DHCP. (Internet Engineering Task Force—IETF—Request for Comments—RFC—1531 defines DHCP.) Since then, DHCP has won the hearts and minds of many Win2K and NT network administrators. DHCP eliminates the administrative burden of manually configuring TCP/IP on network workstations. In addition, DHCP lets you automatically assign IP addresses to clients and configure additional properties of clients' IP stacks, such as the default gateway, DNS and WINS servers, and the WINS node type.

Although DHCP has been an administrative boon, it also presents challenges. One of the biggest problems with DHCP is that it doesn't provide solid fault-tolerance features. Microsoft designed its DHCP services so that one server on each subnet provides DHCP services to the clients on that subnet. Network administrators must configure network routers to pass BOOTP or DHCP requests from clients on one subnet to a DHCP server on a different subnet. (The IETF defines BOOTP forwarding in RFC 1542.) In this scenario, a DHCP server can respond to a remote client's DHCP request only if you've configured the server to serve addresses that are appropriate for the remote client's subnet.

This setup isn't convenient or realistic for many organizations because it requires each server to hold nonoverlapping IP address scopes for multiple subnets. These addresses are effectively unusable because the server is holding them for remote clients' use. In privately addressed networks (e.g., those using the subnet mask 10.x.x.x, 192.168.x.x, or 172.16.x.x), this situation doesn't pose much of a problem because IP addresses are free and plentiful. However, this solution isn't ideal for you if you're using routable IP addresses that your ISP has assigned and you don't have many to spread among multiple DHCP servers or if you have a complex network that contains many IP subnets.

During the development of Win2K, Microsoft promised to provide new fault-tolerance features in Win2K's DHCP services. However, the company actually delivered these features only for DHCP servers running in a clustered configuration, which requires the significantly more expensive Win2K Advanced Server or Win2K Datacenter Server and cluster-compatible hardware. As a result, in Windows networks that don't run Win2K AS or Win2K Datacenter, each network subnet tends to depend strongly on one DHCP server.

Reviving DHCP Services
Unless your DHCP servers run in a clustered Win2K configuration, a failure of the DHCP service or the server hosting it will cause you some major headaches. (For information about how to add DHCP to a clustered server configuration, see "Related Articles.") If DHCP fails, clients that have existing DHCP leases will continue to function properly, but new clients that want to request an IP address or those that attempt to renew their DHCP lease with the server will be unable to do so. When your DHCP service is unavailable, you can use one of two revival remedies: restore the functionality of the existing service or move the DHCP service to another server.

Repairing DHCP services on the original server is the desirable option if the server is operable but the DHCP service is malfunctioning as a result of a corrupt DHCP database. The DHCP database, dhcp.mdb, is a Jet database that contains DHCP server configuration data about address scopes and active client leases. On Win2K and NT DHCP servers, most of the configuration data in this database is mirrored in the system registry in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDHCPServerConfiguration registry subkey.

Like any database, DHCP's configuration database can become damaged or acquire invalid data. A telltale sign of DHCP database corruption is the appearance of event ID 1014 error messages in a DHCP server's System event log. These messages' Source is DhcpServer, and their Description includes a reference to Jet database error code 510, 1022, or 1850. (For a list of Jet database error codes and their descriptions, see "Related Articles.") If your DHCP database is corrupt, you can restore a known good copy of the database or regenerate the database from the DHCP server registry subkey.

Restoring the database from a known good copy is the easier option if a recent backup is available. By default, Win2K and NT 4.0's DHCP services automatically create a backup copy of the DHCP database once per hour in the server's %systemroot%system32dhcpbackupjetew folder. (To modify the frequency of these backups, change the value of the BackupInterval parameter in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDHCPServerParameters subkey from the default setting of 60 minutes.)

After you locate the backup copy of your DHCP database, take the following steps to restore the corrupt database:

The Microsoft article "How to Move a DHCP Database to Another Windows NT Server" (http://support.microsoft.com/support/kb/articles/q130/6/42.asp) recommends using the file-copy method rather than the DhcpExim utility when moving a database from an NT 4.0 system to a Win2K system. Don't follow this recommendation. For seamless cross-platform DHCP management and data migration, use the DhcpExim utility.

Regeneration Recovery
What can you do if you don't have a good backup of the DHCP configuration database? In that case, take the following steps to generate a new database from information stored in the registry:

This process causes DHCP to use the configuration information in the registry to regenerate the database.

After you complete this process, if you discover that your DHCP address-scope and address-reservation information is missing, you might need to take additional steps to complete the database recovery. In such cases, use the following procedure to restore a backup of the DHCP registry configuration data:

After you regenerate a DHCP database, the Win2K Microsoft Management Console (MMC) DHCP snap-in or the NT 4.0 DHCP Manager shows the IP address scopes but doesn't show any active client leases, which brings us to the final step in the database regeneration method: reconciling active leases. This procedure verifies client leases currently recorded in the database (none at this point) against those recorded in the registry. You must perform this process for each scope on the DHCP server.

To reconcile leases for a particular scope on an NT 4.0 DHCP server, select the scope, then select ScopeActive Leases from the menu. In the resulting dialog box, click Reconcile, then click OK. For Win2K servers, in the left pane of the DHCP snap-in, right-click the scope for which you want to reconcile leases and select Reconcile from the drop-down menu, as Figure 1 shows. You must repeat this procedure for each scope on the server.

Avoid Conflicts
Regardless of which procedure you use to restore your DHCP database and DHCP services, a good practice at this point is to enable DHCP's IP address conflict­detection feature. This feature, which is present in Win2K and NT 4.0 Service Pack 2 (SP2) and later, uses a ping test to verify that an IP address isn't already in use before the DHCP server assigns the address to a DHCP client. After a restore operation, a DHCP server might not be up-to-date and can give out addresses that are already in use, so verify that this feature is enabled before you put the server back in service.

To verify that the conflict-detection feature is enabled on Win2K DHCP servers, right-click the server name in the left pane of the DHCP snap-in, select Properties, then click the Advanced tab. On this tab, set the Conflict Detections Attempt value to any integer greater than zero. The value you set tells the server to make that many ping attempts to the IP address before allocating the address to a client.

On NT 4.0 DHCP servers, select Properties from the DHCP Manager utility's Server menu. You'll find the Conflict Detection Attempts setting on the resulting dialog box's General tab.

Preparing for DHCP Disaster
In addition to knowing the techniques for recovering failed DHCP services, you can take a few preparatory steps that will make recovery easier. First, periodically run Jetpack on DHCP databases to compact them and verify their integrity. Second, regularly use the DhcpExim utility to export and back up the configuration of each of your DHCP servers, then store this data in a separate location (i.e., not on the server you're backing up). Third, if appropriate, edit the registry to increase the frequency of automatic DHCP database backups. Fourth, consider using Win2K and NT's built-in replication features or a third-party utility to replicate the DHCP database to other locations on the network. Finally, if you're running a clustered environment, consider implementing DHCP as a clustered service.

These steps, in addition to familiarity with DHCP recovery techniques, will ease the recovery process in the event of a failure. In a later article, I'll help you round out your recovery knowledge with a discussion about disaster prevention and recovery features for WINS and AD.