DHCP Server Role — Scopes, Reservations, and Failover

What Is the DHCP Server Role?

Dynamic Host Configuration Protocol (DHCP) is the mechanism that hands a device an IP address, subnet mask, default gateway, and DNS servers automatically the moment it joins a network, instead of requiring someone to type that configuration in by hand on every laptop, printer, and server. On Windows Server, DHCP is installed as the DHCP Server role.

Think of a DHCP server as the front desk of a hotel with a fixed number of rooms. A guest checking in doesn’t get to pick any room number they like – the front desk hands out a room from the available pool, keeps track of who has which room and for how long, and takes it back when the guest checks out so the next arrival can use it. A DHCP scope is that pool of rooms; a lease is how long a guest gets to keep one before it’s up for renewal.

The exchange itself follows a well-known four-step handshake, commonly abbreviated DORA: the client broadcasts Discover looking for any DHCP server, a server responds with an Offer of a specific address, the client broadcasts a Request confirming it wants that offer (because more than one server may have replied), and the server finalizes it with an Acknowledgement, at which point the client can actually use the address.

Installing and Authorizing the Role

Install the role, then authorize it in Active Directory if the server lives in a domain – unauthorized DHCP servers are automatically prevented from leasing addresses on a domain network, so this step isn’t optional in that environment:

# Install the DHCP Server role and management tools (no reboot required)
Install-WindowsFeature DHCP -IncludeManagementTools

# Authorize the server in Active Directory (domain environments only -
# skip this in a workgroup/standalone deployment)
Add-DhcpServerInDC -DnsName DHCP1.corp.example.com -IPAddress 10.0.0.3

# Confirm the authorization took effect
Get-DhcpServerInDC

In the GUI, the same authorization step is a right-click on the server node in the DHCP console (Authorize), and an unauthorized server shows a red down-arrow icon until it resolves, which can take a few seconds to refresh.

Scopes, Reservations, and Exclusions

A scope is an administrative grouping of IP addresses for one subnet: a start and end address, a subnet mask, a lease duration, and whatever DHCP options (default gateway, DNS servers, and so on) clients on that subnet should receive. Each subnet gets exactly one scope with one continuous address range – if a subnet needs multiple non-contiguous ranges, that’s handled with exclusion ranges inside the single scope, not multiple scopes.

# Create a new scope for a /24 subnet
Add-DhcpServerv4Scope -Name "Corp-LAN" -StartRange 10.10.10.100 `
  -EndRange 10.10.10.200 -SubnetMask 255.255.255.0

# Set the DNS servers option (option 6) for that scope
Set-DhcpServerv4OptionValue -ScopeId 10.10.10.0 -OptionId 6 -Value "10.10.10.10","10.10.10.11"

# Exclude a range within the scope - e.g. addresses already used by
# statically-configured servers or network gear
Add-DhcpServerv4ExclusionRange -ScopeId 10.10.10.0 -StartRange 10.10.10.100 -EndRange 10.10.10.110

Scope options apply only to clients on that specific scope; server-level options (set the same way but without a -ScopeId, or via the Server Options node in the console) apply to every scope on the server unless a scope explicitly overrides them. This is how a site-wide DNS server setting can be configured once instead of on every subnet individually.

A reservation pins one specific IP address to one device’s MAC address permanently – the device still gets its address through DHCP, and still benefits from centralized management, but it never changes. Reservations exist for exactly the kind of device that needs a predictable address but doesn’t warrant hand-configuring a static IP outside DHCP entirely: printers, IP cameras, a small application server.

# Reserve a specific address for a printer's MAC address
Add-DhcpServerv4Reservation -ScopeId 10.10.10.0 -IPAddress 10.10.10.50 `
  -ClientId "F0-DE-F1-7A-00-5E" -Description "3rd floor printer"

DHCP Failover

A single DHCP server is a single point of failure – if it’s down, no new leases and no renewals happen on that subnet. DHCP failover, available since Windows Server 2012 R2, solves this by replicating scope configuration and the active lease database between two Windows DHCP servers so either one can serve the scope. The two servers form a failover relationship, always between exactly two servers (though a single server can have separate failover relationships with different partners for different scopes), and communicate over TCP port 647.

In hot standby mode, the standby server reserves a percentage of the active server’s free addresses for itself – 5% by default – so it has something to hand out to new clients the moment it has to take over, without waiting for the full scope to become available. If the active server comes back within the maximum client lead time (MCLT, one hour by default), leases the standby issued during the outage are still honored safely because neither server will reuse an address the other might still consider live within that window.

# Create a load-balance (active-active) failover relationship for two scopes
Add-DhcpServerv4Failover -ComputerName "dhcp1.corp.example.com" -Name "HQ-Failover" `
  -PartnerServer "dhcp2.corp.example.com" -ScopeId 10.10.10.0,10.10.20.0 `
  -LoadBalancePercent 50 -SharedSecret "change-this-secret"

# Create a hot-standby (active-passive) relationship instead - dhcp1 stays
# active, dhcp2 only takes over if dhcp1 stops responding
Add-DhcpServerv4Failover -ComputerName "dhcp1.corp.example.com" -Name "Branch-Failover" `
  -PartnerServer "dhcp2.corp.example.com" -ScopeId 10.10.30.0 -ServerRole Standby

# After changing a failover-enabled scope's settings, replicate the change
# to the partner explicitly - it does not happen automatically
Invoke-DhcpServerv4FailoverReplication -ComputerName "dhcp1.corp.example.com" -Name "HQ-Failover"

DHCP failover is DHCPv4-only; DHCPv6 and multicast scopes cannot be failover-enabled. Configuration changes to a failover-enabled scope always need an explicit replication step afterward, and that replication should always be initiated from the server holding the settings you actually want kept – replication overwrites the partner’s configuration with the source server’s, not the other way around.

Gotchas and Best Practices

An unauthorized rogue DHCP server on a domain network is a real, recurring incident, not a theoretical one. Someone plugs in a consumer router, a misconfigured lab VM, or a forgotten test server with DHCP enabled, and it starts answering DHCPDISCOVER broadcasts alongside – or instead of – the real server. Windows’ AD authorization requirement blocks this for domain-joined Windows DHCP servers specifically, but it does nothing against a non-Windows or non-domain-joined device doing the same thing; port security and DHCP snooping on switches are the actual defense against that broader case.

Failover is not the only redundancy option, and it isn’t always the right one. Before failover existed, the standard pattern was the 80/20 split-scope: two independent DHCP servers each hosting the same scope’s address range, one configured with roughly 80% of the addresses and exclusions covering the other’s 20%, so each server had spare capacity to cover for the other. Failover replaced this for most new deployments because it shares live lease state instead of just splitting the address pool blind, but the 80/20 pattern still shows up in older environments and is worth recognizing rather than assuming failover everywhere.

Troubleshooting Cheat Sheet

Final Thoughts

DHCP is one of those roles that’s genuinely simple at its core – hand out addresses from a defined pool – and almost all of its administrative surface area is really about handling exceptions to that pool cleanly: a device that needs a fixed address without full static configuration, an address range that’s already spoken for, or a second server ready to take over.

Get scope planning right up front – one continuous range per subnet, exclusions for anything statically configured, reservations for anything that needs predictability – and failover or split-scope redundancy becomes a straightforward addition rather than a retrofit.