Top 16 DHCP Best Practices: The Ultimate Guide

by Robert Allen Updated: June 6, 2022

This is the ultimate guide to Windows DHCP best practices and tips.

If you have any best practices or tips please post them in the comments below.

In this guide, I’ll share the following DHCP best practices and tips.

Table of contents:

1. Don’t put DHCP on Your Domain Controller

2. Use DHCP Failover
3. Central vs Distributed DHCP Server
4. Avoid static IP assignments and use DHCP reservations
5. Exclude IPs from the DHCP scope
6. Learn PowerShell DHCP Commands
7. Subnetting and benefits of network segmentation
8. DHCP Lease Duration Tips
9. Use IP conflict detection only when it is needed
10. Run DHCP Best Practice Analyzer
11. Document IP addresses or us an IPAM
12. Set DHCP Server Options
13. Use DHCP Relay Agents
14. Prevent Rogue DHCP Servers
15. Backup DHCP Server
16. DHCP MAC Address Filtering
Don’t Put DHCP on Your Domain Controller
The general recommendation is to not run any additional roles on your domain
controller other than DNS. Your domain controller should be a domain
controller/DNS and that is it. It is common for small organizations to install
additional roles and 3rd party software on their domain controllers. It is
recommended to avoid this if you can.

What is the issue?

Installing additional services on your DC increases the attack surface, makes it

difficult to manage and can lead to performance issues.

Issue #1. Manage DC with multiple roles

Domain Controllers with multiple roles installed are difficult to manage. This can
often lead to instability and disruption of services.

For example, say you are having issues with DHCP or installed a security patch
that requires a reboot. Rebooting a server with Active Directory Domain Services
role on it could cause major disruption to your organization. This can affect
authentication, replication, group policy, and DNS. Your users will not be able to
access anything if DNS is down.
If you have multiple domain controllers and it’s properly configured then these
issues can be avoided but why risk it?

If DHCP was installed on its own server you could reboot the DCHP server with
no worries of affecting the services on the Domain Controller.

Issue #2. Security

1. The more software/services you install the bigger your attack survivance. If
DHCP is installed on the DC and a new vulnerability was discovered in the
DHCP service your DC server is now at risk.
2. Do you have guest wifi? How do you feel about these unmanaged devices
being connected to your DHCP/DC server? I’m not a fan of using an
internal DHCP server to provide IP addresses for the public. Then to add
that these public devices are also connecting to the domain controller….
yikes my security alarms are going off.
3. When DHCP is installed on a domain controller the DHCP service inherits
the security permissions of the DC computer account. This violates the
principle of least privilege. Now your DHCP server is running with
privileges it doesn’t need to perform a task which it was designed for. Yes,
this can be corrected but why add this risk.

Installing DHCP on its own member server will reduce the attack surface of your
DC.

Issue #3. Performance

Generally, I’ve seen DHCP servers run very efficiently and not require a lot of
system resources such as CPU or memory.

But…

Say you just learned about a new DHCP option such as conflict detection and
you turn it on for all scopes.
Uh oh… Now the CPU usage skyrockets and the domain services are slow, users
can’t log in and DNS requests are painfully slow.

Maybe you install an IPAM to keep tracking of available IP addresses and it takes
up CPU and memory… again taking away resources from the domain services.

I could go on and on… point being the more software/services you install on
your domain controller the more it can affect performance and lead to disruption
in services.

Summary

Your domain controller is one of the most critical services in a

Windows domain environment, it’s your baby and deserves its
on server. A Domain Controller is a Domain Controller is a
Domain Controller is a Domain Controller. Nothing else.

Use DHCP Failover

DHCP failover is a feature for ensuring the high availability of a DHCP server.
With DHCP failover two DHCP servers share DHCP information so that if one
goes down the other server can still provide DHCP leases to clients.

The DHCP failover option is built into the Windows server operating system. The
picture below shows the setup of two DHCP servers configured with load balance
failure mode. If one server fails the other server is still active and takes over all
DCHP requests.
There are two failover design options:

Hot standby design

When using hot standby mode one server is the active server and the other is a
standby. The active server is the primary server and handles all DHCP requests. If
the active server goes down the standby server takes over the DHCP requests.

This option is commonly used with the standby unit being at a physically
different location than the active.

Load balance design

In load balance mode both servers work in an active-active mode to handle
DHCP requests. The requests are load balanced and shared among the two
DHCP servers. If one of the servers loses contact with its failover partner it will
begin granting leases to all DHCP clients.

Summary

You will need to determine which failover design is best for your
environment. It’s a free built in option so take advantage of it
and make your DHCP servers are fault tolerate.
Sources:

DHCP Failover Architecture

Central vs Distributed DHCP Server

Do you have a large network with branch offices at multiple locations?

The question is do you install a DHCP server at these branch offices or have them
tunnel back to a centralized DHCP server?

Centralized DHCP Server

A centralized DHCP server is placed at a centralized location that the remote
offices connect to for DHCP. This is typically located at one of the main
datacenters.  In this design there are no local DHCP servers, all requests go back
to the centralized server.

Distributed DHCP Server

In a distributed DHCP model there are DHCP servers at the local branch office.
This model the clients get IP addresses from the local DHCP server.
So which option is best? 

This can be answered by one simple question?

Can the branch office work entirely by itself with no connection back to the data
center? If yes then it makes sense for there to be a local DHCP and DNS server.

If the branch office tunnels back to the data center for the internet, Active
Directory, DNS, and so on then there is no point in putting DHCP locally.

I work for a company that has offices throughout the state and I use a
centralized DHCP model. We have reliable fast connections so it makes sense for
us to use a centralized DHCP server.

One thing to consider is how many employees are at the branch office. If you
have a very large branch office with thousands of employees then having local
resources like Active Directory, DNS and DHCP can be helpful. That will be a lot
of traffic going across the WAN link and if the link goes down it would take all
those employees offline.

Summary

Choosing between centralized or distributed DHCP can often be

 answered with the following question “Can the branch office
work with no connection back to the data center. Size of the
remote office and connection speed back to the datacenter can
also be a factor.

Sources:

Multi-Site deployment topologies for DHCP Failover

Distributed vs centralized DHCP

Avoid static IP assignments and use DHCP

reservations
Assigning static IP addresses to computers, printers, phones, or any other end
user device is a pain.

Here is what happens when you statistically assign an IP address.

1. Helpdesk replaces the device not aware of the static IP

2. Now the device lost connection completely or partially
3. Helpdesk sends tickets to network team to fix the issue
4. The network team sends ticket back to helpdesk with the static IP
5. Helpdesk now has to go to the device and assign the IP

I’ve been in the above situation plenty of times and like I said it’s a pain. To avoid
all of this just use DHCP reservations instead of static IP assignments.

For anything that needs a fixed IP address, I use DHCP reservations. The one
exception is infrastructure devices like routers and switches, those that get static
IPs.

Screenshot of DHCP reservations for printers.

WIth DHCP reservations all you need to do is update the MAC address when
devices are replaced and the IP is auto assigned back to the device. It also
provides a quick view of everything that his been assigned an IP, instead of
manually tracking everything in a spreadsheet.

Exclude IPs from the DHCP scope

When creating a DHCP scope I recommend excluding a small range for static IP
assignments. Yes, I know in the previous tip I said don’t use static assignments
but you will need it for infrastructure equipment.

Your networks will have a default route that will be a router so you definitely
want that excluded from the DHCP pool. You may also run into other equipment
that requires a static IP so it’s good to have a small range of IPs excluded from
the DHCP pool for these devices. For example, I’ve seen various alarms and
security devices that need a static IP so I just provide an IP from the exclusion
range.

Here is a screenshot of a data VLAN used for workstations and laptops with the
exclusion of 10.2.10.1 to 10.2.10.10.

Learn PowerShell DHCP Commands

There is nothing wrong with using the DHCP console (dhcpmgmt.ms) but
PowerShell is awesome and simplifies many tasks. If you have a large network
with hundreds of DHCP scopes then using PowerShell is a huge time saver.

Here are a few commands to get you started.

Install DHCP Role

Install-WindowsFeature -IncludeManagementTools DHCP

Backup DHCP Server

Backup-DhcpServer -ComputerName "dhcp1.ad.activedirectorypro.com" -

Path "C:\Windows\system32\dhcp\backup"

View DHCP leases

Get-DhcpServerv4Scope | Get-DhcpServerv4Lease

Find DHCP Lease from MAC Address

Get-DhcpServerv4Scope |Get-DhcpServerv4Lease |where {$_.ClientId -like

“b4-b6-86-b4-**-**” }

Add DHCP Scope

Add-DHCPServerv4Scope -EndRange 10.2.1.254 -Name Vlan110 -

StartRange 10.2.1.1 -SubnetMask 255.255.255.0 -State Active

Get all active ipv4 scopes

 Get-DHCPServerv4Scope

Get all DHCP reservations for a scope

Get-DHCPServerv4Lease -ScopeId 10.2.1.0

Create a DHCP reservation

Get-DhcpServerv4Lease -ComputerName dhcpserver1 -IPAddress 10.2.1.8 |

Add-DhcpServerv4Reservation -ComputerName server1

That is just scratching the server of managing DHCP with PowerShell. I’ve added
a few links below to some additional resources for using Powershell.

Sources:
DhcpServer PowerShell cmdlet
Active Directory PowerShell Commands

Subnetting and benefits of network segmentation

I’m not going to deep dive into subnetting because there are plenty of resources
for that.

But… it helps to have some basic understanding of network when configuring

DHCP scopes.

You don’t want to have just one big DHCP pool for all your devices, you should
segment devices into separate networks. This also depends on the size of your
network, if you have a small network then network segmentation is not as
important.
Benefits of network segmentation

Security

By keeping devices on separate networks you have better control of the network.
Do your printers need access to the internet? Probably not. Do computers in the
finance department need to talk directly to computers in HR, absolutely NOT. By
separating devices into their own network you have much better control of their
access.

Limiting lateral movement in the network can really slow down attackers and
viruses. It is important to enable firewalls or access control lists at the network
level to limit lateral movement in your network.

Network performance

Putting everything on one big network will create a giant broadcast domain. This
can lead to all sorts of issues, like spanning tree loops, broadcast and multicast
storms. Segmenting your networks will break up the broadcast domains and
reduce possible performance issues.

Control visitor/guest access

You don’t want your guest network to have access to your secure network.
Separating this traffic to its own network allows you to filter this traffic and block
access to your internal network.  I also use the guest network for IOT type
devices that just need an internet connection.

Below is an example of how I segment network traffic.

Computers = 10.2.10.0/24 VLAN 110

Printers = 10.2.8.0/24 VLAN 108
Voice = 10.2.6.0/24 VLAN 106
Video Surveillance = 10.2.4.0/24 VLAN 104
Server = 10.2.2.0/24 = VLAN 102
Guest = 10.16.0.0/23 = VLAN 116
In addition to network segmentation try and keep your IP scheme simple, it really
simplifies managing DHCP scopes.

DHCP Lease Duration Tips

A DHCP lease is the time period a DHCP server assigns an IP address to a client.
The default DHCP lease time for DHCP scopes is 8 days.

Tip#1 increase lease time for fixed devices

For small networks, you can leave the lease time to the default setting of 8 hours.

For large networks, consider changing the DHCP scopes for fixed devices
(workstations) to 16 days. This can reduce DHCP related network traffic.
Workstations don’t move very often so they don’t need to go through the whole
DHCP dance as often to obtain an IP address.

Tip#2 reduce the lease time for guest/mobile devices

If you provide guest wifi these DHCP scopes can become exhausted of available
IPs very quickly. These devices most likely just need temporary access such as a
few hours. For these scopes consider adjusting the DHCP lease time to 1 hour. If
the device is still active it will renew but if the device disconnected it will free up
an IP address. This should help with available IPs on your guest scopes.

This can also be the case with mobile devices, this one can be tricky though with
more and more users having laptops. The default of 8 days may be sufficient but
if you know of mobile devices that move around a lot you may consider reducing
the lease time.
 Summary

If you have DHCP scopes that serve specific devices such as

workstations only then consider adjusting the DHCP lease times.

Use IP conflict detection only when it is needed

When two devices on the same LAN have the same IP address an IP address
conflict occurs. This leads to one or both of the devices having issues
communicating on the network.

The DHCP server has an option to help reduce IP conflicts. The conflict detection
option on the DHCP server will first check if an IP is in use before assigning it to a
device.

By default, this is disabled on all DHCP scopes.

Microsoft’s recommendation is to use this only when it is needed. DO NOT

enable this for every scope. If you stay away from static IP assignments then you
probably will never need to turn this on.

If you do turn this on set the detection attempts to 1 or 2.

Sources:

Microsoft DHCP Best Practices

Run DHCP Best Practice Analyzer

Microsoft’s best practice analyzer is a tool that checks the DHCP configuration
against Microsoft guidelines. The best practice analyzer is built into Windows
Server and is available on the server management tool.

Steps to run the tool.

Step 1: Open Server Manager

Step 2: Click on DHCP

Step 3: Start a BPA scan

The results will display when the scan is complete

The BPA scanner should help discover any basic misconfigurations. Review your
results and make any changes you feel are necessary for your environment.

Document IP addresses or us an IPAM

Document your IP scheme, VLANs, and static IP assignments.

For small networks, an excel spreadsheet may be sufficient.

For larger networks, I recommend an IP address management tool. For years I

used an excel spreadsheet and as the network grew the spreadsheet became a
nightmare. I eventually moved all the spreadsheets to SolarWinds IPAM and no
longer worry about IP management. SolarWinds IPAM takes care of everything
for me and best of all I can quickly search the entire database.
IPAM Benefits

Automatic IP address tracking

Can integrate with DHCP/DNS to track dhcp scope usage
Alerting and reporting of scope usage
Search IP addresses, comments, hostnames, etc. It is so nice being able to
quickly search by a keyword to see what a device’s IP address it.

SolarWinds has a free version of their IPAM, it can track up to 254 addresses. The
paid version allows you to manage all IP addresses.

Download a FREE copy here

Set DHCP Server Options

DHCP scope options allow you to auto configure additional TCP/IP settings on
the client devices.

DHCP options can be configured at two different levels, at the server or per each
DHCP scope.

I prefer at each scope, it’s more work but I may have scopes such as guest wifi
that I don’t want using the internal DNS. Sometimes VOIP phones need special
options to configure and I don’t want that at the server level.

The most common options used are:

003 Router

006 DNS servers

015 DNS Domain Name

Take advantage of the scope options so you can auto configure the IP settings
on all devices.

DHCP Relay Agents

If you have a centralized DHCP server with multiple networks then you will need
to use a DHCP relay agent.

DHCP messages are broadcasted and routers do not forward broadcast packets.
To fix this issue you can enable the DHCP relay agent function on your
router/switch to allow the DHCP broadcast packets to reach the device.

You will need to check with your router documentation for the commands to
enable the relay agent.

Sources:

Cisco Configyure DHCP Relay Agent 

HP Configure DHCP Relay

Prevent Rogue DHCP Servers

Have you ever had a user or someone in your own IT department plug a
switch/router into an available port on the wall? Then the helpdesk phone starts
blowing up because users can’t connect to the internet or other resources.

Rogue DHCP servers are a headache. In addition, they can be a security risk and
used for various attacks.

The best way to block rogue DHCP servers is at the network switch. This can be
done with an option called DHCP snooping or 802.1x port based network access.

DHCP Snooping
DHCP snooping is a layer 2 switch feature that blocks unauthorized (rogue)
DHCP servers from dishing out IP addresses to devices.

DHCP works by categorizing switchports as either trusted or untrusted ports. A

trusted port allows DHCP messages an untrusted port blocks DHCP messages.

You want your devices (computers, printers, phones) on an untrusted port so a

rogue DHCP server cannot be plugged in.

802.1x port based network access

802.1x is an IEEE standard for port based network access control. It is a
mechanism that can require devices to authenticate before providing them
network access.

It’s not only good for rogue DHCP servers but for controlling network access to
anything.

802.1x is typically configured at the switch level and requires a client and
authentication server.

Backup DHCP Server

Your DHCP servers are critical to providing IP settings to your clients. In the event
of a system crash you need to recover this server as soon as possible.

Did you know by default, Windows will back up the DHCP configuration every 60
minutes to this folder %SystemRoot%System32\DHCP\backup.

This is great but does you no good if the server crashes and you can’t access the
folder.

If you don’t have any offsite replication in place then you would need to copy
the backup folder to another location on a regular schedule.

This can be done with a script that copies the folder to another location or uses
PowerShell to specify a remote location.

Backup-DhcpServer -ComputerName “DC01” -Path “C:\DHCPBackup”

You can read more on this in my article Backup and Restore Windows DHCP
Server

DHCP MAC Address Filtering

The DHCP MAC address filtering feature allows you to block or allow IP address
assignment based on MAC addresses.

This is useful if you want to have a DHCP scope provide IP addresses to an

explicit list of devices. It’s also useful if you have unwanted devices on a VLAN
getting an IP address.

For example, you have users putting BYOD devices on your secure VLAN. You
could add these devices to the deny filter. The DHCP MAC filtering is a quick and
simple way to control access to the network. If you have the time and resources
the better option is to use 802.1x.

Conclusion
I’ve been using these tips for years when managing DHCP servers. When
configured correctly DHCP can be a set and forget server with little or no issues. I
hope you find these tips useful and please post any DHCP tips or best practices
you have in the comments below.

Best Practices

Recommended Tool: Permissions Analyzer for

Active Directory
This FREE tool lets you get instant visibility into user and group permissions and
allows you to quickly check user or group permissions for files, network, and
folder shares.

You can analyze user permissions based on an individual user or group

membership.

This is a Free tool, download your copy here.

12 thoughts on “Top 16 DHCP Best Practices: The Ultimate
Guide”

Le Thanh Tung

Thanks. Very nice article

Reply

Robert Allen

Thanks Le

Reply

Marcus

Thanks a lot! Some interesting spots

Reply

Ehsan
Hi Thanks for nice post can you also show how to configure fail over
DHCP server in the network.

Reply

Danny

Hi Robert,

Thanks for putting this together. Very informative. I have a question

regarding timestamps. Our ownership group wants us to write a script
that captures the exact time that a dhcp address was issued to a client
and then write that timestamp to a log. The previous requirement was
just a monthly DHCP lease export which was easy to do, but now they
want to know specifically when the address was issued. Thoughts? I
appreciate any insight you may have.

Thanks,

Danny

Reply

Neha

Nice article very helpful

Reply
 Robert Allen

Thanks for the feedback

Reply

GG

Hi, does you know if another alternative exist for Solarwinds IPAM to
manage IP, delegate DHCP roles, etc. ?

We already test IPAM and we found it’s not very stable or so useful
application than we would want.

Reply

Robert Allen

Check out phpIPAM or ManageEngine opUtils

Reply

Patrick Bervoets
Thanks for the article.

What would you say is the best practice? Give a fixed or a (reserved)
dhcp-address to an ADDS that is neither a DHCP or a DNS?

It is indeed a pain if you have to go over all your devices to update the
dns reference. And in the near future I’ll have to completely alter my
addressing scheme.

Thanks

Reply

Robert Allen

Fixed.

You don’t want critical assets to depend on a DHCP server for an IP

address. Something could go wrong with DHCP and give it a different IP
or no IP.

Reply

John Hughes

My thoughts exactly, very nice article.

What is your recommendation for handling the random MAC address

from mobile devices. Can DHCP Policies be used based on MAC address
 second nibble (x2, x6, xA, xE). it could work if there was a single character
wild card indication,

Something like “?[26AEae]:*” as a MAC policy to adjust the lease time to

say 1 day.

Thank You

Reply

Leave a Comment

Name *

Email *

Website

Post Comment
Resources
Blog

Products

Account Portal

Company
Home

About

Contact

Connect

© 2022 Active Directory Pro. All Rights Reserved | Terms and Conditions | Privacy Policy