Chapter 7 - Managing MS DHCP Servers

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Dynamic Host Configuration Protocol (DHCP) is an open, industry standard that is designed to reduce the complexity of Transmission Control Protocol/Internet Protocol (TCP/IP) network administration. DHCP specifies methods for simplified and dynamic configuration of computers on TCP/IP networks, and reduces the administrative burden of adding, moving, and configuring computers on TCP/IP networks.

DHCP is specified by Internet Engineering Task Force (IETF) Requests for Comments (RFCs) 1533, 1534, 1541, and 1542.

The information in this chapter is intended for network administrators and support personnel who need to manage and support Microsoft DHCP servers. This chapter includes the following topics:

Introduction to Dynamic Host Configuration Protocol (DHCP)
- Microsoft DHCP server
- DHCP clients
- DHCP/BOOTP relay agents
Planning for Microsoft DHCP server implementation
- Planning for small networks
- Planning for routed networks
- Planning for DHCP server and client traffic
- Setting local policies
- Partitioning the Microsoft DHCP server address pool
- Using Microsoft DHCP with Domain Name System (DNS) servers
Using DHCP Manager
Managing the DHCP server database
Troubleshooting DHCP services

Introduction to Dynamic Host Configuration Protocol

Every computer on a TCP/IP internetwork must be given a unique computer name and IP address. The IP address identifies both the computer and the subnetwork to which it is attached. When the computer is moved to a different subnetwork, the IP address must be changed to reflect the new subnetwork ID.

DHCP is designed to reduce the complexity of configuring computers for TCP/IP networks. RFC 1541 specifies two major components needed for DHCP services: a protocol for communicating TCP/IP configuration parameters between a DHCP server and a DHCP client, and a method for allocating IP addresses to the DHCP client.

Understanding IP Addresses

To receive and deliver packets successfully between computers, TCP/IP requires that three values be provided by the network administrator: an IP address, a subnet mask, and a default gateway (router).

IP Addresses

Every device attached to a TCP/IP network is identified by a unique IP address. (If a computer has multiple network adapters, each adapter will have its own IP address.) This address is typically represented in dotted-decimal notation—that is, with the decimal value of each octet (8 bits, or 1 byte) of the address separated by a period. The following is a sample IP address:

172.16.48.1

Important: Because IP addresses identify devices on a network, each device on the network must be assigned a unique IP address.

Network ID and Host ID

Although an IP address is a single value, it contains two pieces of information: the network ID and the host ID of your computer.

The network ID identifies the systems that are located on the same physical network. All systems on the same physical network must have the same network ID, and the network ID must be unique to the internetwork.
The host ID identifies a workstation, server, router, or other TCP/IP device within a network. The address for each device must be unique to the network ID.

A computer connected to a TCP/IP network uses the network ID and host ID to determine which packets it should receive or ignore and to determine the scope of its transmissions. (Only computers with the same network ID accept each other's IP-level broadcast messages.)

Note: Networks that connect to the public Internet must obtain an official network ID from the Internet Network Information Center (InterNIC) to guarantee the uniqueness of the IP network ID. For more information, visit the InterNIC home page on the Internet at https://www.internic.net/

After receiving a network ID, the local network administrator must assign unique host IDs for computers within the local network. Although private networks not connected to the Internet can use their own network identifier, obtaining a valid network ID from InterNIC allows a private network to connect to the Internet in the future without reassigning addresses.

The Internet community has defined address classes to accommodate networks of varying sizes. The address class can be discerned from the first octet of an IP address. Table 7.1 summarizes the relationship between the first octet of a given address and its network ID and host ID fields. It also identifies the total number of network IDs and host IDs for each address class that participates in the Internet addressing scheme. The example in Table 7.1 uses w.x.y.z to designate the bytes of the IP address.

Table 7.1 IP Address Classes

Class	w values 1 , 2	Network ID	Host ID	Available networks	Available hosts per network
A	1–126	w	x.y.z	126	16,777,214
B	128–191	w.x	y.z	16,384	65,534
C	192–223	w.x.y	z	2,097,151	254

1 Inclusive range for the first octet in the IP address.

2 The address 127 is reserved for loopback testing and interprocess communication on the local computer; it is not a valid network address. Addresses 224 and above are reserved for special protocols (Internet Group Management Protocol multicast and others), and cannot be used as host addresses.

Subnet Masks

Subnet masks are 32-bit values that allow the recipient of IP packets to distinguish the network ID portion of the IP address from the host ID. Subnet masks are created by assigning 1s to network ID bits and 0s to host ID bits. The 32-bit value is then converted to dotted-decimal notation, as shown in Table 7.2.

Table 7.2 Default Subnet Masks for Standard IP Address Classes

Address class	Bits for subnet mask	Subnet mask
Class A	11111111 00000000 00000000 00000000	255.0.0.0
Class B	11111111 11111111 00000000 00000000	255.255.0.0
Class C	11111111 11111111 11111111 00000000	255.255.255.0

For example, when the IP address is 172.16.16.1 and the subnet mask is 255.255.0.0, the network ID is 172.16 and the host ID is 16.1.

Because the class of a host is easily determined, configuring a host with a subnet mask might seem redundant. But subnet masks are also used to further segment an assigned network ID among several local networks. Sometimes only portions of an octet need to be segmented, using only a few bits to specify subnet IDs.

Important: To prevent addressing and routing problems, all computers on a logical network must use the same subnet mask and network ID.

Microsoft DHCP Server

Microsoft DHCP server provides a reliable and flexible alternative to manual TCP/IP configuration. Microsoft DHCP server includes a graphical administrative tool—DHCP Manager—that allows you to define DHCP client configurations, and a database for managing assignment of client IP addresses and other optional TCP/IP configuration parameters.

You can use Microsoft DHCP server to automatically and dynamically assign TCP/IP configuration parameters to computers that start on the network. TCP/IP configuration parameters that can be dynamically assigned by a Microsoft DHCP server include:

IP addresses for each network adapter card in a computer.
Subnet masks that identify the portion of an IP address that is the physical segment (subnet) network identifier.
Default gateway (router) that connects the subnet to other network segments.
Additional configuration parameters that can be optionally assigned to DHCP clients, such as domain name.

A Microsoft DHCP server database is automatically created when the Microsoft DHCP server is installed on a computer running Windows NT Server and the TCP/IP protocol. You add data to the DHCP server database by defining DHCP scopes and DHCP options when using DHCP Manager.

DHCP Scopes

A DHCP scope is an administrative grouping that identifies the configuration parameters for all DHCP clients grouped together on a physical subnet. The scope must be defined before DHCP clients can use the DHCP server for dynamic TCP/IP configuration.

To create a DHCP scope, you must use DHCP Manager to enter the following required information:

Scope name assigned by the administrator when the scope is created
Unique subnet mask used to identify the subnet to which an IP address belongs
Range of IP addresses contained within the scope
Time interval (known as lease duration) that specifies how long a DHCP client can use an assigned IP address before it must renew its configuration with the DHCP server

Note: Each subnet can have only one scope with a single continuous range of IP addresses. To use several address ranges within a scope, create a continuous range that encompasses all of the address ranges; then manually exclude the addresses that fall between the specific address ranges. See the section "Using DHCP Manager" later in this chapter for additional information.

In addition to the required DHCP scope information, you can define individual scope options by using DHCP Manager. The following table lists additional scope options:

Table 7.3 Additional Scope Options

Option	Description
Deactivate	You can release an IP address if a computer is removed from a network.
Renewal	You can change the renewal period for IP-address leases. By installation default, DHCP clients begin the renewal process when 50 percent of the IP address lease time has expired.
Reserve	You can reserve a specific IP address for a DHCP client, such as an Internet Information Server or WINS server. An IP address can also be reserved if a computer on the network is not DHCP-enabled. Also, for TCP/IP security, computers designated as network firewalls are configured with reserved IP addresses.

DHCP Options

Other options, known as DHCP options, can also be configured on the DHCP server by using DHCP Manager. In addition to defining the required DHCP Scope configuration parameters, you can use Microsoft DHCP server to automatically assign advanced TCP/IP configuration options, such as a Windows Internet Name Service (WINS) server and a Domain Name System (DNS) server, to DHCP clients. To do this, you select one or more DHCP options when using DHCP Manager.

Microsoft DHCP options can be selected and assigned to a selected scope or to all scopes by clicking either Scope or Global on the DHCP Options menu. When using DHCP options, keep in mind the following guidelines:

Active global options always apply unless overridden by Scope options or by manual configuration of a DHCP client.
Active options for a scope apply to all computers in that scope, unless overridden by manual configuration of a DHCP client.

Microsoft DHCP server provides the ability to configure many standard DHCP options as defined by RFC 1541. The following table lists the standard DHCP options available when using Microsoft DHCP server.

Note: You can use Microsoft DHCP server to set any of the options described in this table. However, Windows-based and Windows NT-based DHCP clients support only the options whose code and option name are listed in bold type. (If you use Microsoft DHCP server to administer third-party DHCP clients, you can use any option listed in this table that is supported on the third-party DHCP client.)

Table 7.4 Default DHCP Options as Defined by RFC 1541

Code	Option name	Meaning
0	Pad	Causes subsequent fields to align on word boundaries.
255	End	Indicates end of options in the DHCP packet.
1	Subnet mask	Specifies the subnet mask of the client subnet. This option is defined in the DHCP Manager Create Scope or Scope Properties dialog box. It cannot be set directly in the DHCP Options dialog box.
2	Time offset	Specifies the Universal Coordinated Time (UCT) offset in seconds.
3	Router	Specifies a list of IP addresses for routers on the client's subnet.*
4	Time server	Specifies a list of IP addresses for time servers available to the client.*
5	Name servers	Specifies a list of IP addresses for name servers available to the client.*
6	DNS servers	Specifies a list of IP addresses for DNS name servers available to the client.* Multihomed computers can have only one list per computer, not one per adapter card.
7	Log servers	Specifies a list of IP addresses for MIT_LCS User Datagram Protocol (UDP) log servers available to the client.*
8	Cookie servers	Specifies a list of IP addresses for RFC 865 cookie servers available to the client.*
9	LPR servers	Specifies a list of IP addresses for RFC 1179 line-printer servers available to the client.*
10	Impress servers	Specifies a list of IP addresses for Imagen Impress servers available to the client.*
11	Resource Location servers	Specifies a list of RFC 887 Resource Location servers available to the client.*
12	Host name	Specifies the host name of up to 63 characters for the client. The name must start with a letter, end with a letter or digit, and have as interior characters only letters, numbers, and hyphens. The name can be qualified with the local DNS domain name.
13	Boot file size	Specifies the size of the default boot image file for the client, in 512-octet blocks.
14	Merit dump file	Specifies the file and directory where the client's core image is dumped if a crash occurs.
15	Domain name	Specifies the DNS domain name that the client should use for DNS host name resolution.
16	Swap server	Specifies the IP address of the client's swap server.
17	Root path	Specifies the ASCII path for the client's root disk.
18	Extensions path	Specifies a file that can be retrieved by using Trivial File Transfer Protocol (TFTP). This file contains information interpreted the same as the vendor-extension field in the BOOTP response, except that the file length is unconstrained and references to Tag 18 in the file are ignored.
19	IP layer forwarding	Enables or disables forwarding of IP packet for this client. 1 enables forwarding; 0 disables it.
20	Nonlocal source routing	Enables or disables forwarding of datagrams with nonlocal source routes. 1 enables forwarding; 0 disables it.
21	Policy filter masks	Specifies policy filters that consist of a list of pairs of IP addresses and masks specifying destination/mask pairs for filtering nonlocal source routes. Any source - routed datagram whose next-hop address does not match a filter will be discarded by the client.
22	Max DG reassembly size	Specifies the maximum size datagram that the client can reassemble. The minimum value is 576.
23	Default time-to-live	Specifies the default time-to-live (TTL) that the client uses on outgoing datagrams. The value for the octet is a number between 1 and 255.
24	Path MTU aging timeout	Specifies the timeout in seconds for aging Path Maximum Transmission Unit (MTU) values (discovered by the mechanism defined in RFC 1191).
25	Path MTU plateau table	Specifies a table of MTU sizes to use when performing Path MTU Discovered as defined in RFC 1191. The table is sorted by size from smallest to largest. The minimum MTU value is 68.
26	MTU option	Specifies the MTU discovery size for this interface. The minimum MTU value is 68.
27	All subnets are local	Specifies whether the client assumes that all subnets of the client's internetwork use the same MTU as the local subnet where the client is connected. 1 indicates that all subnets share the same MTU; 0 indicates that the client should assume some subnets might have smaller MTUs.
28	Broadcast address	Specifies the broadcast address used on the client's subnet.
29	Perform mask discovery	Specifies whether the client should use Internet Control Message Protocol (ICMP) for subnet mask discovery. 1 indicates that the client should perform mask discovery; 0 indicates that the client should not.
30	Mask supplier	Specifies whether the client should respond to subnet mask requests using ICMP. 1 indicates that the client should respond; 0 indicates that the client should not respond.
31	Perform router discovery	Specifies whether the client should solicit routers using the router discovery method specified in RFC 1256. 1 indicates that the client should perform router discovery; 0 indicates that the client should not use it.
32	Router solicitation address	Specifies the IP address to which the client submits router solicitation requests.
33	Static route	Specifies a list of IP address pairs that indicate the static routes the client should install in its routing cache. Any multiple routes to the same destination are listed in descending order or priority. The routes are destination/router address pairs. (The default route of 0.0.0.0 is an illegal destination for a static route.)
34	Trailer encapsulation	Specifies whether the client should negotiate use of trailers (RFC 983) when using the Address Resolution Protocol (ARP). 1 indicates that the client should attempt to use trailers; 0 indicates that the client should not use trailers.
35	ARP cache timeout	Specifies the timeout in seconds for ARP cache entries.
36	Ethernet encapsulation	Specifies whether the client should use Ethernet (as specified by RFC 894) or IEEE 802.3 (RFC 1042) encapsulation if the interface is Ethernet. 1 indicates that the client should use RFC 1042 encapsulation; 0 indicates that the client should use RFC 894 encapsulation.
37	Default time-to-live	Specifies the default TTL that the client should use when sending TCP segments. The minimum value of the octet is 1.
38	Keepalive interval	Specifies the interval in seconds that the client TCP should wait before sending a keepalive message on a TCP connection. A value of 0 indicates that the client should not send keepalive messages on connections unless specifically requested by an application.
39	Keepalive garbage	Specifies whether the client should send TCP keepalive messages with an octet of garbage data for compatibility with older implementations. 1 indicates that a garbage octet should be sent; 0 indicates that it should not be sent.
40	NIS domain name	Specifies the name of the Network Information Service (NIS) domain as an ASCII string.
41	NIS servers	Specifies a list of IP addresses for NIS servers available to the client.*
42	NTP servers	Specifies a list of IP addresses for Network Time Protocol (NTP) servers available to the client.1
43	Vendor-specific information	Binary information used by clients and servers to exchange vendor-specific information. Servers not equipped to interpret the information ignore it. Clients that don't receive the information attempt to operate without it.
44	WINS/NBNS servers	Specifies a list of IP addresses for NetBIOS name servers (NBNS).*
45	NetBIOS over TCP/IP NBDD	Specifies a list of IP addresses for NetBIOS datagram distribution servers (NBDD).*
46	WINS/NBT node type	Allows configurable NetBIOS over TCP/IP (NetBT) clients to be configured as described in RFC 1001/1002, where 1 = b-node, 2 = p-node, 4 = m-node, and 8 = h-node. On multihomed computers, the node type is assigned to the entire computer, not to individual adapter cards.
47	NetBIOS scope ID	Specifies a text string that is the NetBIOS over TCP/IP Scope ID for the client, as specified in RFC 1001/1002. On multihomed computers, the scope ID is assigned to the entire computer, not to individual adapter cards.
48	X Window system font	Specifies a list of IP addresses for X Window font servers available to the client.1
49	X Window system display	Specifies a list of IP addresses for X Window System Display Manager servers available to the client.*
51	Lease time	Specifies the time in seconds from address assignment until the client's lease on the address expires. Lease time is specified in the DHCP Manager Create Scope or Scope Properties dialog box. It cannot be set directly in the DHCP Options dialog box.
58	Renewal (T1) time value	Specifies the time in seconds from address assignment until the client enters the renewing state. Renewal time is a function of the lease time option, which is specified in the DHCP Manager Create Scope or Scope Properties dialog box. It cannot be set directly in the DHCP Options dialog box.
59	Rebinding (T2) time value	Specifies the time in seconds from address assignment until the client enters the rebinding state. Rebinding time is a function of the lease time option, which is specified in the DHCP Manager Create Scope or Scope Properties dialog box. It cannot be set directly in the DHCP Options dialog box.
64	NIS + Domain Name	Network Information Service (previously known as Yellow Pages) domain name.
65	NIS + Servers	Network Information Service (previously known as Yellow Pages) server name.
66	Boot Server Host Name	Identifies a Trivial File Transfer Protocol (TFTP) server.
67	Bootfile Name	Identifies the file that is to be used as the bootfile.
68	Mobile IP Home Agents	Can be used to list (in order of preference) IP addresses that identify mobile IP home agents.

* List is specified in order of preference.

Boldface type indicates those options that Windows-based and Windows NT-based clients support

The Microsoft DHCP network packet allocates 312 bytes for DHCP options. This is more than enough space for most option configurations. With some DHCP servers and clients, you can allocate unused space in the DHCP packet to additional options. This feature, called option overlay, is not supported by Microsoft DHCP server or client. If you attempt to use more than 312 bytes, some options settings will be lost. In that case, you should delete any unused or low-priority options.

Tip If you are using Microsoft DHCP server to configure computers that should use the services of a WINS server, be sure to use option #44, WINS Servers, and option #46, Node Type. These DHCP options automatically configure the DHCP client as an h-node computer that directly contacts WINS servers for name registration and name query instead of using broadcasts (b-node.)

You can also add custom parameters to be included with DHCP client configuration information and change values or other elements of the predefined DHCP options, as needed.

DHCP Clients

To configure a computer running Windows NT Server or Windows NT Workstation as a DHCP client, select the Obtain an IP address from a DHCP server check box on the IP Address tab of the Microsoft TCP/IP Properties page. A DHCP server can also be used to configure computers running under following operating systems:

Windows 95
Windows for Workgroups version 3.11 with the Microsoft 32-bit TCP/IP VxD installed
Microsoft – Network Client version 3.0 for MS-DOS with the real-mode TCP/IP driver installed
LAN Manager version 2.2c

Table 7.5 describes the basic TCP/IP configuration parameters that a DHCP server must provide to DHCP clients.

Table 7.5 Required TCP/IP Configuration Parameters for DHCP Clients

Basic TCP/IP configuration parameters	Description
IP address	Every device attached to a TCP/IP network is identified by a unique IP address. (If the computer has multiple network adapter cards, it will require multiple IP addresses.) The IP address is a numeric identifier comprised of four 8-bit octets separated by periods. (This number is generally shown in dotted-decimal notation, for example, 172.16.32.1) The IP address is actually two parts: the first part represents a network ID and the second part represents a host (computer) ID.
Subnet mask	Used to identify the part of the unique IP address that is the network identifier and the part that is the host identifier. Subnet masks are created by assigning 1s to network ID bits and 0s to the host ID bits of the IP address.
Default gateway	The computer (router) connected to the local subnet and other subnets that is used to pass IP packets from one subnet to another. (A default gateway is required only when the client is located on a routed TCP/IP network.)

Initial DHCP Client Configuration

When a DHCP client computer is started on a TCP/IP network, it communicates with a DHCP server to get its TCP/IP configuration information. The following table describes the DHCP message types exchanged between client and server.

Table 7.6 DHCP Message Types

Message type	Description
Dhcpdiscover	The first time a DHCP client computer attempts to start on the network, it requests IP address information from a DHCP server by broadcasting a Dhcpdiscover packet. The source IP address in the packet is 0.0.0.0 because the client does not yet have an IP address.
Dhcpoffer	When the DHCP server receives the request, it selects an unleased IP address from the range of available IP addresses and offers it to the DHCP client. In most cases, the DHCP server also returns additional TCP/IP configuration information, such as the subnet mask and default gateway in a Dhcpoffer packet. More than one DHCP server can respond with a Dhcpoffer packet, and the client accepts the first Dhcpoffer it receives.
Dhcprequest	When a DHCP client receives a Dhcpoffer packet, it responds by broadcasting a Dhcprequest packet that contains the offered IP address.
Dhcpdecline	A message from the DHCP client to the server indicating that the offered configuration parameters are invalid.
Dhcpack	The DHCP server acknowledges the client Dhcprequest for the IP address by sending a Dhcpack packet.
Dhcpnack	If the IP address cannot be used by the client because it is no longer valid or is now used by another computer, the DHCP server will respond with a Dhcpnack packet.
Dhcprelease	A message from the DHCP client to the server that releases the IP address and cancels any remaining lease.

When the DHCP server receives the request from the DHCP client computer, it dynamically assigns an IP address to the requesting computer from the range of valid IP addresses contained within the DHCP scope. The DHCP server allocates the IP address with a lease that defines how long the IP address is usable by the client computer. The DHCP server can also establish other configuration parameters, such as subnet mask and DNS and WINS server identification, for the client computer.

If the DHCP client has previously been assigned an IP address by the DHCP server or by manual configuration, the client sends a Dhcprequest packet. The following figure illustrates this process.

Figure 7.1: DHCP Client and Server Interaction During System Startup

Figure 7.1: DHCP Client and Server Interaction During System Startup

Note: The client accepts the first offer it receives, regardless of whether the offer came from a DHCP server on the local subnet or from a DHCP server on a different subnet.

When a client accepts an IP address, and any other configuration information offered by the DHCP server, the client saves the configuration in the following Registry keys:

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services:
Network interface specific: <adapter>\parameters\Tcpip
General: Dhcp\parameters\options\*

IP addressing information is leased to a client until the client manually releases the address, or until the DHCP server cancels the lease and makes the address available to other computers on the network.

If a client does not receive a Dhcpoffer packet from a DHCP server, it will broadcast a request four times, at 2- ,4- ,8- , and 16-second intervals (plus a random amount between 0 and 1,000 milliseconds). If the client does not receive a response after four attempts, it will cease trying and retry again in five minutes. In the case where the DHCP server is unavailable or there is no available IP addressing information to lease to a client computer, the client is unable to bind to TCP/IP.

Restarting a DHCP Client

When a client computer restarts and logs on to the network, it broadcasts a Dhcprequest packet instead of a Dhcpdiscover packet. The Dhcprequest packet contains a request for the previously assigned IP address. The DHCP server will attempt to allow the client to retain the same IP address, and will respond with a Dhcpack packet. If the IP address cannot be used by the client because it is no longer valid, or is now used by another computer, the DHCP server will respond with a Dhcpnack packet. The client that receives a Dhcpnack response must restart the configuration process by sending a Dhcpdiscover request.

DHCP/BOOTP Relay Agents

TCP/IP networks are interconnected by routers that connect network segments (subnets) and pass IP packets between the subnets. As mentioned earlier, one of the major components of the DHCP specification is the DHCP protocol for communications between DHCP servers and clients.

A DHCP server can provide IP addresses to clients in multiple subnets if the router that connects the subnets is an RFC 1542-compliant router. RFC 1542 specifies the DHCP/BOOTP relay agent. If the router cannot function as a relay agent, each subnet that has DHCP clients requires a DHCP server.

A relay agent is a program used to pass specific types of IP packets between subnets. A DHCP/BOOTP relay agent is simply a hardware or software program that can pass DHCP/BOOTP messages (packets) from one subnet to another subnet according to the RFC 1542 specification.

Planning for DHCP Implementation

This section describes how to develop strategies for implementing DHCP servers in small LANs or large routed networks. Most network administrators implementing DHCP will also be planning a strategy for implementing WINS servers. The planning tasks described here also apply to WINS servers. In fact, the administrator will probably want to plan DHCP and WINS implementation in tandem.

Note: If you use DHCP servers, you must use WINS servers so that the dynamic IP addressing of DHCP clients can be dynamically updated in name- to- IP- address mappings.

Before you install Microsoft DHCP servers on your network, consider the following recommendations:

The general guideline for determining how many DHCP servers are needed in a network is that one online DHCP server and one backup DHCP server (a hot standby) can support 10,000 clients. However, when deciding how many DHCP servers you will need, consider the location of routers on the network and whether you will want a DHCP server in each subnet.
To determine where to install the DHCP servers, use the physical characteristics of your LAN or WAN infrastructure and not the logical groupings defined in the Windows NT domain concepts. When subnets are connected by RFC 1542-compliant routers, DHCP servers are not required on every subnet on the network. Note that DHCP servers can be administered remotely from a computer running under Windows NT Server that is DHCP- or WINS-enabled.

Compile a list of requirements including:
- Client support (numbers and kinds of systems to be supported)
- Interoperability with existing systems (including your requirements for mission-critical accounting, personnel, and similar information systems)
- Hardware support and related software compatibility (including routers, switches, and servers)
- Network monitoring software, including Simple Network Management Protocol (SNMP) and other tools
Isolate the areas of the network where processes must continue uninterrupted, and then target these areas for the last stages of implementation.
Review the geographic and physical structure of the network to determine the best plan for defining logical subnets as segments of the intranet.
Define the components in the new system that require testing, and then develop a phased plan for testing and adding components.

For example, the plan could define the order for types of computers to be phased in (including Windows NT servers and workstations, Microsoft RAS servers and clients, Windows for Workgroups computers, and MS-DOS clients).
Create a pilot project for testing.
Create a second test phase, including tuning the DHCP (and WINS) server-client configuration for efficiency.

This task can include determining strategies for backup servers and for partitioning the address pool at each server to be provided to local versus remote clients.
Document all architecture and administration issues for network administrators.

Planning for Small Networks

In a small LAN that does not include routers and subnetting, a single DHCP server could be used to service all DHCP clients as illustrated in the following figure.

Figure 7.2: A Single Local Network Using Automatic TCP/IP Configuration with DHCP

Figure 7.2: A Single Local Network Using Automatic TCP/IP Configuration with DHCP

Before installing the DHCP server you will need to identify:

The hardware and storage requirements for the DHCP server.
Which computers can immediately be configured as DHCP clients for dynamic TCP/IP configuration and which computers should be manually configured with static TCP/IP configuration parameters including static IP addresses.
The DHCP option types and their values to be predefined for the DHCP clients.

Planning for DHCP in Routed Networks

A router is a TCP/IP gateway computer that has two or more network adapter cards (NICs). Each adapter is connected to a different physical network (a subnet). A router device provides services that are determined by the hardware and software configuration of the computer that serves as the router.

Routers that implement the DHCP/BOOTP relay agent as specified by RFC 1542 can be used to route traffic between DHCP servers and clients located on different subnets. The relay agent on the router forwards requests from local DHCP clients to the remote DHCP server and subsequently relays the DHCP server responses back to the DHCP clients. The following figure illustrates an example of a routed network with DHCP server and DHCP clients.

Figure 7.3: An Internetwork Using Automatic TCP/IP Configuration with DHCP

Windows NT Server version 4.0 includes Multi-Protocol Router (MPR), which is a software router that can be configured on a general purpose computer to provide DHCP/BOOTP relay agent support. MPR includes:

BOOTP relay agent for DHCP
Routing Information Protocol (RIP) for TCP/IP
Routing Information Protocol for IPX

Note: Windows NT supports DHCP but does not support BOOTP. You can use Microsoft DHCP server on the same network with clients and servers running BOOTP. The Windows NT-based DHCP servers simply ignore any BOOTP client packets that they may receive from the network. You must make sure, however, that the BOOTP server and the DHCP server do not manage leases for the same IP addresses. The best way to ensure that there is no overlap in managed addresses is to define the scope of the DHCP server as the entire address range that is managed by both the DHCP server and the BOOTP server, and then exclude the address range that is managed by the BOOTP server. As BOOTP clients are dropped or upgraded to DHCP, the exclusion range can be adjusted accordingly.

Additional planning issues for a large enterprise network are:

Ensuring the compatibility of hardware and software routers with DHCP.
Planning the physical subnetting of the network and relative placement of DHCP servers. This includes planning for placement of DHCP (and WINS) servers among subnets in a way that reduces b-node broadcasts across routers.
Specifying the DHCP option types and their values to be predefined per scope for the DHCP clients. This might include planning for scopes based on the needs of particular groups of users. For example, for a marketing group that uses portable computers docked at different stations, or for a unit that frequently moves computers to different locations, shorter lease durations can be defined for the related scopes. This way, frequently changed IP addresses can be freed for reuse.

As one example of planning for a large enterprise network, the segmenting of the WAN into logical subnets could match the physical structure of the internetwork. Then one IP subnet can serve as the backbone, and off this backbone each physical subnet would maintain a separate IP subnet address.

In this case, for each subnet a single computer running Windows NT Server could be configured as both the DHCP and WINS server. Each server would administer a defined number of IP addresses with a specific subnet mask, and would also be defined as the default gateway. Because the server is also acting as the WINS server, it can respond to name resolution requests from all systems on its subnet.

These DHCP and WINS servers can in turn be backup servers for each other. The administrator can partition the address pool for each server to provide addresses to remote clients.

There is no limit to the maximum number of clients that can be served by a single DHCP server. However, your network can have practical constraints based on the IP address class, and server configuration issues such as disk capacity and CPU speed.

Planning for DHCP Traffic

DHCP client and server TCP/IP configuration traffic does not use significant network bandwidth during normal periods of usage. However, there are two phases of DHCP client configuration that do generate some network traffic load. These phases are:

IP Address Lease
IP Address Renewal

IP Address Lease

When a new client initializes TCP/IP for the first time (and is configured as a DHCP client), its first step is to acquire an IP address using DHCP. This process results in a conversation between the DHCP client and server consisting of four packets, the first of which is the client computer broadcasting a Dhcpdiscover packet in an attempt to locate a DHCP server.

DHCP Discover

The Dhcpdiscover frame will be either 342 or 590 bytes total. (Older versions of Windows for Workgroups TCP/IP stack, TCP/IP-32 3.11a, as well as Windows NT 3.5, used 590-byte frames.) The first 14 bytes constitute the Ethernet header portion of the packet. The first distinguishing characteristic is the destination address, which is the Ethernet broadcast address of 255.255.255.255. The client computer has no knowledge of where any DHCP servers reside, and so it initiates a broadcast which is an Ethernet Type 0800 frame (IP).

The next 20 bytes are the IP header portion of the packet. The interesting things to note are the source and destination addresses. The source address is 0.0.0.0; because the client does not yet have a valid IP address, it initializes with an address of 0.0.0.0. The destination address is 255.255.255.255, which is the IP network broadcast address. As with the Ethernet header, the client does not know the location or address of any DHCP servers, and so it initiates an IP broadcast.

DHCP is a UDP-based protocol, and so the next 8 bytes are the UDP header. The UDP source and destination ports are both BOOTP (68 and 67, respectively). DHCP is an extension of the BOOTP protocol, and thus uses its ports for messaging.

The remainder of the frame contains the Dhcpdiscover packet components. The majority of the remaining fields are either zeros or blank, because the client has no knowledge of any IP addresses or parameters. Upon examining the DHCP Option Field section, you will notice the Client Identifier, which is its MAC address, and its Host name. These are added to the frame in the event that a DHCP server may have a reserved address for the client which is identified by its MAC address.

The host will broadcast up to four Dhcpdiscover messages in an attempt to find a DHCP server. If, after four attempts, a server cannot be located, the computer will cease trying, and then attempt to locate a DHCP server every five minutes until it is successful.

DHCP Offer

Once a DHCP server has received the Discover packet, and determined that it can accommodate the client's request, it responds with a Dhcpoffer message. The Dhcpoffer frame is 342 bytes total. The first 14 bytes constitute the Ethernet header portion of the packet. The first distinguishing characteristic is the destination address, which is the Ethernet broadcast address of 255.255.255.255. The server responds to the client with a broadcast which is an Ethernet Type 0800 frame (IP).

The next 20 bytes are the IP header portion of the packet. The interesting things to note are the source and destination addresses. The source address is that of the DHCP server, and the destination address is 255.255.255.255, which is the IP network broadcast address. As with the Ethernet header, the client responds with an IP broadcast.

DHCP is a UDP-based protocol, and so the next 8 bytes are the UDP header. The UDP source and destination ports are both BOOTP (67 and 68, respectively).

The remainder of the frame (300 bytes) contains the Dhcpoffer packet components. The new items configured are Your IP address, which is set to the proposed address for the client, and proposals for the IP address lease time (including renewal periods). The DHCP server's IP address is also listed here.

DHCP Request

The Dhcprequest frame will be either 342 or 590 bytes total, depending on the size of the Dhcpdiscover message. The first 14 bytes constitute the Ethernet header portion of the packet. The first distinguishing characteristic is the destination address, which is the Ethernet broadcast address of 255.255.255.255. The client computer knows the address of the server it is accepting its address from, but responds with a broadcast to let all DHCP servers know that it has selected an address from a specific server. It is an Ethernet Type 0800 frame (IP).

The next 20 bytes are the IP header portion of the packet. The interesting things to note are the source and destination addresses. The source address is 0.0.0.0; because the client does not yet have a valid IP address, it initializes with an address of 0.0.0.0. The destination address is 255.255.255.255, which is the IP network broadcast address. As with the Ethernet header, the client initiates an IP broadcast to let all DHCP servers accept the frame, and learn that it has accepted an offer.

DHCP is a UDP-based protocol, and so the next 8 bytes are the UDP header. The UDP source and destination ports are both BOOTP (68 and 67, respectively).

The remainder of the frame contains the Dhcprequest packet components. The majority of the remaining fields are either zeros or blank, because the client has no knowledge of any IP addresses or parameters. Upon examining the DHCP Option Field section, you will notice the Requested address, which is the IP address the client is requesting, and a Server Identifier (IP address of the server the request is being made of). These are added to the frame so that other DHCP servers are notified that the client has accepted an offer from a specific server, and they can offer the address they offered to this client to another DHCP client.

DHCP ACK

Once a DHCP server has received the Request packet, it responds with a Dhcpack message. The Dhcpack frame is 342 bytes total. The first 14 bytes constitute the Ethernet header portion of the packet. The first distinguishing characteristic is the destination address, which is the Ethernet broadcast address of 255.255.255.255. The server responds to the client with a broadcast. It is an Ethernet Type 0800 frame (IP).

DHCP is a UDP-based protocol, and so the next 8 bytes are the UDP header. The UDP source and destination ports are both BOOTP (67 and 68, respectively).

The remainder of the frame contains the Dhcpack packet components. Your IP address, which is set to the proposed address for the client, is still configured, and parameters, such as IP Lease Time, and renewal and rebinding times, as well as other DHCP options, such as Router, NetBIOS Name Server address, NetBIOS Node Type, and so on, are listed in the Option Field portion of the frame. This portion will be variable, depending on the options requested from the client and those returned by the server.

IP Address Renewal

Whenever a DHCP client starts, it must renew its IP address with its DHCP server. When renewing an IP address using DHCP, the conversation is a simple one consisting of the last two packets of the IP address lease phase. The client computer will request a renewal of its current IP address with a Dhcprequest packet and, if successful, the DHCP server responds with a Dhcpack packet.

The only difference between the Dhcprequest and Dhcpack packets for a renewal and those of the acquisition is that the conversation is directed, and not broadcast, because the client and server already know about each other. Additionally, any new DHCP options, such as Domain Name Server address, that have been configured since the client acquired the IP address lease, are now sent to the client computer.

DHCP clients also renew their IP address lease at one-half of the TTL, which is a configurable length. At this time, the client issues a Dhcprequest packet to its DHCP server, and the server will respond with a Dhcpack, if the address is still valid for the client.

The DHCP client will retry its renewal attempt one time. If unsuccessful, it will try again at the next renewal period.

Summary of DHCP Traffic

To recap, the entire process of acquiring an IP address lease through DHCP takes a total of four packets, varying between 342 and 590 bytes in size. This process, on a clean network (no other network traffic using bandwidth), takes less than 1 second (about 300 milliseconds).

DHCP conversations generally occur in the following instances:

When a DHCP client initializes for the first time (all four frames).
When an automatic renewal, which is only done every one-half lease life (three days by default, so every 18 hours), takes two packets (Dhcprequest and Dhcpack) and approximately 200 milliseconds.
When a client is moved to a new subnet (Dhcprequest, Dhcpnack, then the four frames as if it is a new client).
When a DHCP client replaces its network adapter card (all four frames).
Whenever a client manually refreshes or releases its address by using the ipconfig utility.

This process should not have a significant effect on network traffic, even if multiple DHCP clients are acquiring or renewing addresses simultaneously.

Planning Guideline for DHCP Traffic

DHCP does not normally have a big impact on network traffic. If you wish to reduce the amount of traffic generated by DHCP, it is possible to adjust the lease duration for IP address leases. This is done using DHCP Manager, and adjusting Lease Duration in the Scope Properties dialog box.

As noted earlier, the default lease duration is three days, which would cause each client to attempt to renew their lease every 18 hours from the time the client acquired the address. A lease renewal is only two packets, with a maximum totoal size of 932 bytes.

Setting Local Policies

This section provides some suggestions for setting lease options, dividing the free address pool among DHCP servers, and preventing DNS naming problems.

Managing DHCP Addressing Policy

Allocation of IP addresses for distribution by DHCP servers can be done dynamically or manually. These methods use the same DHCP client-server protocol, but the network administrator manages them differently at the DHCP server end.

Dynamic Allocation of IP Addresses

Dynamic allocation enables a client to be assigned an IP address from the free address pool. The lease for the address has a lease duration (expiration date), before which the client must renew the lease to continue using that address. Depending on the local lease policies defined by the administrator, dynamically allocated addresses can be returned to the free address pool if the client computer is not being used, if it is moved to another subnet, or if its lease expires. Any IP addresses that are returned to the free address pool can be reused by the DHCP server when allocating an IP address to a new client. Usually, the local policy ensures that the same IP address is assigned to a client each time that it starts.

After the renewal time of the lease duration has passed, the DHCP client enters the renewing state. The client sends a request message to the DHCP server that provided its configuration information. If the request for a lease extension fits the local lease policy, the DHCP server sends an acknowledgment that contains the new lease and configuration parameters. The client then updates its configuration values and returns to the bound state.

When the DHCP client is in the renewing state, it must release its address immediately in the rare event that the DHCP server sends a negative acknowledgment. The DHCP server sends this message to inform a client that it has incorrect configuration information, forcing it to release its current address and acquire new information.

If the DHCP client cannot successfully renew its lease, the client enters a rebinding state. At this stage, the client sends a request message to all DHCP servers in its range, attempting to renew its lease. Any server that can extend the lease sends an acknowledgment containing the extended lease and updated configuration information. If the lease expires or if a DHCP server responds with a negative acknowledgment, the client must release its current configuration, and then return to the initializing state. (This happens automatically, for example, for a computer that is moved from one subnet to another.)

If the DHCP client uses more than one network adapter to connect to multiple networks, this protocol is followed for each adapter that the user wants to configure for TCP/IP. Windows NT allows multihomed systems to selectively configure any combination of the system's interfaces. You can use the ipconfig utility to view the local IP configuration for a client computer.

When a DHCP-enabled computer is restarted, it sends a message to the DHCP server with its current configuration information. The DHCP server either confirms this configuration or sends a negative reply so that the client must begin the initializing stage again. System startup might, therefore, result in a new IP address for a client computer, but neither the user nor the network administrator has to take any action in the configuration process.

Before loading TCP/IP with an address acquired from the DHCP server, DHCP clients check for an IP address conflict by sending an Address Resolution Protocol (ARP) request containing the address. If a conflict is found, TCP/IP does not start, and then the user receives an error message. The conflicting address should be removed from the list of active leases or it should be excluded until the conflict is identified and resolved.

Managing Lease Options

To define appropriate values for lease duration, consider the frequency of the following events for your network:

Changes to DHCP options and default values
Network interface failures
Computer removals for any purpose
Subnet changes by users because of office moves, laptop computers docked at different workstations, and so on

All of these types of events cause IP addresses to be released by the client or cause the leases to expire at the DHCP server. Consequently, the IP address is returned to the free address pool to be reused.

If many changes occur on your internetwork, you should assign short lease times, such as two weeks. This way, the addresses assigned to systems that leave the subnet can be reassigned quickly to new DHCP client computers requesting TCP/IP configuration information.

Another important factor to consider is the ratio between connected computers and available IP addresses. For example, the demand for reusing addresses is low on a network where 40 systems share a class C address (with 254 available addresses). A long lease time, such as two months, would be appropriate in such a situation. However, if 230 computers share the same address pool, demand for available addresses is much greater, and so a lease time of a few days or weeks is more appropriate.

Notice, however, that short lease durations require that the DHCP server be available when the client seeks to renew the lease. Backup servers are especially important when short lease durations are specified.

Although infinite leases are allowed, they should be used with great caution. Even in a relatively stable environment, there is a certain amount of turnover among clients. At a minimum, portable computers might be added and removed, desktop computers might be moved from one office to another, and network adapter cards might be replaced. If a client with an infinite lease is removed from the network, the DHCP server is not notified, and then the IP address cannot be reused. A better option is a very long lease duration, such as six months. A long lease duration ensures that addresses are ultimately recovered.

Partitioning the Address Pool

You will probably decide to install more than one DHCP server, so that the failure of any individual server will not prevent DHCP clients from starting. However, DHCP does not provide a way for DHCP servers to cooperate in ensuring that assigned addresses are unique. Therefore, you must divide the available address pool among the DHCP servers to prevent duplicate address assignment.

A typical scenario is where a local DHCP server maintains TCP/IP configuration information for two subnets. For each DHCP server, the network administrator allocates 70 percent of the IP address pool for local clients and 30 percent for clients from the remote subnet, and then configures a relay agent to deliver requests between the subnets.

This scenario allows the local DHCP server to respond to requests from local DHCP clients most of the time. The remote DHCP server will assign addresses to clients on the other subnet only when the local server is not available or is out of addresses. This same method of partitioning among subnets can be used in a multiple subnet scenario to ensure the availability of a responding server when a DHCP client requests configuration information.

Using DHCP with DNS Servers

Domain Name System (DNS) servers can be used to provide names for network resources. However, there is no current IETF specification for dynamically updating DNS servers such as when a DHCP client is dynamically configured with an IP address and other TCP/IP configuration parameters. Therefore, DNS naming conflicts can occur if you are using a DHCP server for dynamic assignment of client IP addresses.

This problem primarily affects systems that extend internetworking services to local network users. For example, a server acting as an anonymous FTP server or as an electronic mail gateway might require users to contact it using DNS names. In such cases, clients should have reserved leases with an unlimited duration.

For workstations in environments that do not require the computers to register in the DNS name space, DHCP dynamic allocation can be used without problems.

Using DHCP Manager

When you install Microsoft DHCP server, the graphical user-interface, DHCP Manager, is automatically installed and added to the Administrative Tools (Common) programs group. You use DHCP Manager to configure and monitor remote and local DHCP servers.

You can use DHCP Manager to view and change parameters for Microsoft DHCP servers on the network for which you have administrator privileges. DHCP Manager Help is organized to provide information for each of the specific administration and configuration tasks that you need to perform to manage DHCP servers. See DHCP Manager Help for specific tasks details.

To start DHCP Manager

Click Start, point to Programs, point to Administrative Tools (Common), and then click DHCP Manager.

Managing the DHCP Server Database

The DHCP server database under Windows NT Server version 4.0 uses the performance-enhanced Exchange Server storage engine version 4.0. When you install Microsoft DHCP server, the files shown in the following table are automatically created in the \systemroot\System32\Dhcp directory.

Table 7.7 Microsoft DHCP Server Database Files

File	Description
Dhcp.mdb	The DHCP server database file.
Dhcp.tmp	A temporary file used by the DHCP database as a swap file during database index maintenance operations. This file may remain in the \systemroot\System32\Dhcp directory after a crash.
J50.log and J50#####.log	A log of all database transactions. This file is used by the DHCP database to recover data if necessary.
J50.chk	A checkpoint file.

Important: The J50.log file, J50#####.log file, Dhcp.mdb file, and Dhcp.tmp file should not be removed or tampered with in any manner.

As previously discussed, the DHCP server database is a dynamic database that is updated as DHCP clients are assigned, or release, their TCP/IP configuration parameters. Because the DHCP database is not a distributed database like the WINS server database, maintenance of the DHCP server database is less complex.

The DHCP database and related Registry entries are backed up automatically at a specific interval (15 minutes by installation default). This installation default can be changed by changing the value of the Registry parameter BackupInterval in the Registry key:

SYSTEM\current\currentcontrolset\services\DHCPServer\Parameters

Troubleshooting DHCP Server

The following error conditions indicate potential problems with the DHCP server:

The administrator can't connect for a DHCP server by using DHCP Manager. The message that appears might be "The RPC server is unavailable."
DHCP clients cannot renew the leases for their IP addresses. The message that appears on the client computer is "The DHCP client could not renew the IP address lease."
The DHCP Client service or Microsoft DHCP Server service might be stopped and cannot be restarted.

The first troubleshooting task is to make sure that the DHCP services are running. Open Services in Control Panel to verify that the DHCP services are running. "Started" should appear in the Status column for the DHCP Client service and "Started" should appear in the Status column for the Microsoft DHCP Server service. If the appropriate service is not started, start the service.

In rare circumstances, a DHCP server cannot start or a STOP error might occur. If the DHCP server is stopped, complete the following procedure to restart it.

To restart a DHCP server that is stopped

Turn off the power to the server, and then wait about one minute.
Turn on the power, start Windows NT Server, and then log on under an account with Administrator rights.
At the command prompt, type net start dhcpserver, and then press ENTER.

Note: Use Event Viewer in the Administrative tools to find the possible source of problems with DHCP services.

Using IPCONFIG

Ipconfig is a TCP/IP utility that you can use at the command prompt. You can use the ipconfig command to get information about the configured TCP/IP parameters on local or remote computers on the network.

For more information on how to use the ipconfig command, see the topic "TCP/IP Procedures Help" in Control Panel Help.

Upgrading the DHCP Database to Windows NT Server Version 4.0

When upgrading a Windows NT Server version 3.51 (or earlier) release to Windows NT 4.0, the DHCP database must be converted to the new database format. This is required because the services now use an improved database engine that is faster and that compacts automatically to prevent fragmentation and consequent growth of the database. The database conversion procedure happens automatically as part of an upgrade installation.

Database Conversion Procedure

When the DHCP service first starts after an upgrade to Windows NT 4.0, it detects that the database needs to be converted. It then starts a conversion process, Jetconv.exe. (If Jetconv.exe has already been started by another service, a second Jetconv.exe process is not started.) Prior to conversion, the user is notified that the conversion process is about to start and is asked for confirmation. If the user clicks OK, the DHCP service terminates and the conversion begins. Jetconv.exe converts the databases of all the installed services (DHCP and if installed WINS and RPL) to the new Windows NT 4.0 database format.

After the DHCP database is converted successfully, the DHCP Server service is automatically restarted.

Before starting the conversion process, note the following guidelines:

Prior to upgrading to Windows NT Server 4.0, bring the Windows NT 3.51 databases for the DHCP server to a consistent state. Do this by terminating the services, either by using Service in Control Panel or by using the net stop service command. This is recommended because it prevents the Jetconv.exe conversion from failing due to an inconsistent Windows NT 3.51 database.
The conversion requires approximately the same amount of free disk space as the size of the original database and log files. You should have at least 5 MB free for the log files for each database.
The conversion process preserves the original database and log files in a subdirectory named 351db under the same directory where the original database and log files were located. On the DHCP server, this is the systemroot\System32\dhcp\351db\ directory. The administrator can later remove these files to reclaim the disk space.

The database conversion can take anywhere from a minute to an hour depending on the size of the database. The user must not try to restart the services while the databases are being converted. To check the status of the conversion, the user should watch the Application Event Log of the Jetconv.exe process by using Event Viewer.

In case this automatic procedure of converting databases fails for some reason (as can be determined from the event logs), the database that couldn't be converted can be converted manually using winntdir\system32\upg351db.exe. At the command line, type upg351db -? for instructions.

Note the following information:

You cannot convert the new database back to the previous database format.
The converted database will not work with Windows NT 3.51 or earlier services.
The new database engine uses log files named by using the prefix J50.

Restoring the DHCP Database

If you determine that the DHCP services are running on both the client and server computers but the error conditions described earlier under "Troubleshooting DHCP Server" persist, then the DHCP database is not available or has become corrupted. If a DHCP server fails for any reason, you can restore the database from a backup copy.

To restore a DHCP database

Before starting, make a copy of the DHCP server database files.
In the \systemroot\System32\Dhcp directory, delete the J50.log, J50#####.log, and Dhcp.tmp files.
Copy an uncorrupted backup version of the Dhcp.mdb to the \systemroot\System32\Dhcp directory.
Restart the Microsoft DHCP Server service.

Restarting and Rebuilding a Stopped DHCP Server

In rare circumstances, the DHCP server may not start or a STOP error might occur. If the DHCP server is stopped, use the following procedure to restart it.

To restart a DHCP server that is stopped

Turn off the power to the server and wait at least 15 seconds.
Turn on the power, start Windows NT Server, and then log on under an account with Administrator rights.
At the command prompt, type the net start dhcp command, and then press ENTER.

If the hardware for the DHCP server is malfunctioning or other problems prevent you from running Windows NT, you must rebuild the DHCP database on another computer.

To rebuild a DHCP server

If you can start the original DHCP server by using the net start DHCP command, use a copy command to make backup copies of the files in the \systemroot\System32\Dhcp directory. If you cannot start the computer at all, you must use the last backup version of the DHCP database files.
Install Windows NT Server and Microsoft TCP/IP to create a new DHCP server using the same hard-drive location and \systemroot directory.

That is, if the original server stored the DHCP files on C:\Winnt\System32\Dhcp, then the new DHCP server must use this same path to the DHCP files.
Make sure the Microsoft DHCP Server service on the new server is stopped, and then use the Registry Editor to restore the DHCP keys from backup files.
Copy the DHCP backup files to the \systemroot\System32\Dhcp directory.
Restart the new, rebuilt DHCP server.

Moving the DHCP Server Database

You may find a situation where you need to move a DHCP database to another computer. To do this, use the following procedure.

To move a DHCP database

Stop the Microsoft DHCP Server on the current computer.
Copy the \System32\Dhcp directory to the new computer that has been configured as a DHCP server.

Make sure the new directory is under exactly the same drive letter and path as on the old computer.

If you must copy the files to a different directory, copy Dhcp.mdb, but do not copy the .log of .chk files.
Start the Microsoft DHCP Server on the new computer.

The service automatically starts using the .mdb and .log files copied from the old computer.

When you check DHCP Manager, the scope still exists because the Registry holds the information on the address range of the scope, including a bitmap of the addresses in use. You need to reconcile the DHCP database to add database entries for the existing leases in the address bitmask. As clients renew, they are matched with these leases, and eventually the database is once again complete.

To reconcile the DHCP database

On the Scope menu, click Active Leases.
In the Active Leases dialog box, click Reconcile.

Although it is not required, you can force DHCP clients to renew their leases in order to update the DHCP database as quickly as possible. To do so, type ipconfig/renew at the command prompt.

Compacting the DHCP Server Database

Windows NT Server 4.0 is designed to automatically compact the DHCP database and normally you should not need to run this procedure. However, if you are using Windows NT Server versions 3.51 or earlier, after DHCP has been running for a while, the database might need to be compacted to improve DHCP performance. You should compact the DHCP database whenever it approaches 30 MB.

You can use the Jetpack.exe utility provided with Windows NT Server version 3.5 and 3.51 to compact a DHCP database. Jetpack.exe is a command-line utility that is run in the Windows NT Server command window. The utility is found in the \%Systemroot\System32 directory.

The Jetpack.exe syntax is:

Jetpack.exe <database name> <temp database name>

For example:

   > CD %SYSTEMROOT%\SYSTEM32\DHCP
   > JETPACK DHCP.MDB TMP.MDB

In the preceding example, Tmp.mdb is a temporary database that is used by Jetpack.exe. Dhcp.mdb is the DHCP server database file.

When Jetpack.exe is started, it performs the following tasks:

Copies database information to a temporary database file called Tmp.mdb.
Deletes the original database file, Dhcp.mdb.
Renames the temporary database file to the original filename.

To compact the DHCP database

In Control Panel, double-click Services.
Under Service, click Microsoft DHCP Server.
Click Stop, and then click Close. (Alternatively, you can type net stop DHCP at the command prompt.)
At the command prompt, run the Jetpack.exe program as previously described.
Restart the DHCP Server service by using the Services dialog box.