Skip to content

DHCP Failover Real World Advice for Midsized Business


Machine LearningIt’s imperative in our seemingly always connected world that DHCP is continuously available to provide valid IP addresses for accessing the network and the Internet. Unfortunately, prescriptive guidance about DHCP has not been updated since the February 29, 2012 TechNet article of Step-by-Step: Configure DHCP for Failover.

To make matters worse, many people don’t read the important note:

The following instructions are for configuring a test lab using the minimum number of computers. Individual computers are needed to separate the services provided on the network and to clearly show the desired functionality. This configuration is neither designed to reflect best practices nor does it reflect a desired or recommended configuration for a production network. The configuration, including IP addresses and all other configuration parameters, is designed only to work on a separate test lab network.

You would think that Microsoft TechNet would be the definitive best practice approach, but generally these documents describe how to do a task and overall choices without much regard for where services should run or what are the best settings and why. The following points are explained in training for  Microsoft Certified Solutions Experts:

  1. Document DHCP Settings. Ideally, a table of DHCP settings including scope range, exclusions, and options should be documented within a consolidated System Plan.  Recorded configuration allows DHCP to be setup within 5 minutes versus potential hours of trial and error testing. This simple step makes large investments in clustering or exhaustive monitoring impractical.
  2. Two DHCP Servers. Just like you should always have two domain controllers, a second failover DHCP server should be maintained for midsized businesses.  If you only have one DHCP server and it fails, then no one can access either the network or the Internet. If you setup DHCP on existing domain controllers, then there is no added cost for setup and maintenance of separate servers or related hardware and software.
  3. DHCP Role on Domain Controllers. Technically, you can deploy DHCP on virtually any server that meets minimum hardware and Windows Server requirements. However, the DHCP role should be setup on domain controllers. Having separate DHCP services on member servers just provides additional points of failure and troubleshooting. If DHCP services cannot reach DNS on domain controllers, then you still cannot access the network or the Internet (even though you may have a valid IP address).
  4. Manual Configuration. Until recently, the bits for DHCP hadn’t significantly changed since Windows NT of the 1990’s. Concepts like Standby and Failover are relatively new. Standby to production is largely a mystery happening (if it happens at all) and failover is a similar misnomer. Unlike DNS, DHCP servers do not replicate settings and are generally unaware of other DHCP servers. For best availability and control, separate manual DHCP scopes should be setup on two domain controllers with the same scope range of addresses. To prevent IP address conflicts, the available address pool from each DHCP server should be excluded as described below.
  5. 50% Split Scope. Because DHCP examples are often taken from lab environments, odd split scope ratios like 80% / 20% are often erroneously repeated as best practice. The real concept is that half of your full address pool on each of the two DHCP servers should be ample to provide addresses for all devices on the network in the event one of your DHCP servers fails:
    • Scope 1: 10.381.1 – 10.38.1.254, subnet 255.255.255.0
      Exclusions: 10.38.1.1 – 10.38.1.20 (routers, servers, printers), 10.38.1.128 – 254 (Scope 2 addresses)
      Options: Router 10.38.1.1, DNS 10.38.1.2, 10.38.1.3, Domain example.com
    • Scope 2: 10.381.1 – 10.38.1.254, subnet 255.255.255.0
      Exclusions: 10.38.1.1 – 127 (Scope 1 addresses)
      Options: Router 10.38.1.1, DNS 10.38.1.2, 10.38.1.3, Domain example.com
  6. Backup and Restore. Remember that DHCP databases are in use and skipped during a backup. For basic configurations like above, you can setup DHCP manually with known settings faster than restoring from offsite backup. However, environments that use reservations should use the DHCP backup option to a file location included in the overall server backup when any scope changes are made. In the event of a DHCP Server failure, the DHCP role could then be added on a server and a DHCP restore performed.
  7. Authorize and Deactivate. One of the most common oversights with DHCP setup is neglecting to select the “Authorize” option so the service actively provides IP addresses to devices. Similarly, you should select Deactivate to remove the decommissioned DHCP server out of Active Directory and related errors in Event Viewer logs.

The information provided above is derived from a proven DHCP Standard Operating Procedure as part of our Delta methodology and has been audited and accepted in compliance industries for over 20 years. If you have questions or recommendations for updates, please comment below.

Enter your email address to follow this blog and receive notifications of new posts by email.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: