Dynamic host configuration protocol (DHCP) is often taken for granted – we expect it to work; however there are a few items which need to be considered and this post is intended as a general discussion of DHCP best practice.

Most administrators will be familiar with the overall DHCP concept – basically a database of IP addresses allocated to clients dynamically, allowing centralised IP address management; however, most of the organisations I see still need to use static addresses for some devices (e.g. servers). Whilst there is nothing wrong with this and I would still suggest using fixed IP addresses for networking equipment and the DHCP server itself, reservations can be useful to reserve particular addresses for certain clients, based on their media access control (MAC) address. The main drawback of this approach is that if the NIC in the computer changes, so does the MAC, although reprogramming the MAC address is possible (as is setting up a new reservation).

If there are static addresses in use which fall within the an IP address range intended for DHCP, exclusions can be configured (much easier than configuring several scopes to cover the fragmented IP range). Exclusions can be configured for a single address, or for a range of IP addresses.

Lease duration is another area to consider (i.e. the amount of time before a client needs to renew its DHCP address) – if this is set too long, and there are a large number of mobile clients, there is a risk of running out of available IP addresses as these mobile clients join the network, lease an address and then leave again without releasing it; conversely, too short and there is a large amount of renewal traffic as the DHCP client attempts to renew its lease at the half life. For most environments, I find that an 80:20 rule can be applied – i.e. provide 20% more addresses than are expected to be in use at any one time (to cater for mobile clients) and set the lease time to 1 day but for a subnet with largely static PCs, then longer leases may be appropriate.

DHCP includes a number of pre-defined options that can be set on a client:

• Server options apply to all scopes on a server (e.g. 006 DNS servers, 015 DNS Domain Name).
• Scope options apply to a single scope (e.g. 003 Router).
• Class options can be applied to a specific type of device.
• Reservation options apply to specific reservations.

Occasionally it may be necessary to configure custom options – e.g. 060 for a pre-boot execution environment (PXE) client or 252 for web proxy auto-discovery (WPAD).

If there are multiple DHCP servers on a subnet, then the client will be allocated an address by the first one to answer – hence the reason for Windows 2000 and later DHCP servers supporting DHCP authorisation in Active Directory (hence preventing the use of rogue DHCP servers); however this will not affect non-AD DHCP servers (such as the one in Virtual Server, or on an ADSL router). When a client issues a DHCP request, all listening servers respond with an offer and the client will respond to the first answer received. Because DHCP requests are broadcast-based, they typically cannot traverse routers and so DHCP relaying must be configured to overcome this where clients are remote from the DHCP server.

To configure DHCP for redundancy, it is generally advised to configure two DHCP servers and to split the scope using a 50:50 or 80:20 ratio (50:50 works well where both DHCP servers are on the same site; 80:20 may be often appropriate where a remote site is providing redundancy for a local server) so, for example, if I want to allocate addresses on the network 192.168.1.0/24, I might reserve the top 10 or so addresses for static devices and create two scopes on two DHCP servers – one for 192.168.1.1-120 and the other for 192.168.1.121-240. This provides 240 potentially available addresses but if one server is unavailable then the other can answer. Of course, this scenario only provides for 120 clients (96 taking into account my earlier recommendations for dealing with mobile devices). It is also possible to cluster DHCP servers for redundancy.

Superscopes can be used to group several scopes into one for management purposes, but when I tried to implement these in a live environment, we found that they did not work well and had to revert to individual scopes for each subnet.

Since Windows 2000, the Microsoft DHCP server implementation has included DNS integration. Set on the scope properties, this allows three options for updating A and PTR records in DNS as IP addresses are leased to DHCP clients:

• Enable DNS dynamic updates, either always, or if requested (by Windows 2000 or later clients).
• Discard DNS records when the lease is deleted (i.e. clean up afterwards).
• Dynamically update DNS for legacy clients that do not request updates (e.g. Windows NT 4.0).

In terms of new features, Windows Server 2003 improves on Windows 2000 Server by allowing backup and restoration of the DHCP database from the DHCP console. It also provides for both user- and vendor-specified option classes. Potentially the greatest area of improvement is integration of DHCP commands within the netsh command shell.

Finally, DHCP servers use a JET database and may be busy. At a recent Microsoft TechNet UK event, John Howard recommended that every now and again, the service is stopped and jetpack.exe is used to perform database maintenance, improving performance (as described in Microsoft knowledge base article 145881).