Recovering DHCP

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_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Configuration 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%\system32\dhcp\backup\jet\new folder. (To modify the frequency of these backups, change the value of the BackupInterval parameter in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters subkey from the default setting of 60 minutes.)