DHCP on Hyper-V: Scope Creation to Failover Configuration

In modern enterprise networks, manual IP address management is impractical, error-prone, and costly. As environments scale across on-premises, virtualized, and hybrid infrastructures, automated IP address allocation becomes essential.

In this hands-on lab, I set up, deployed, and documented a fully functional DHCP server running on a Windows Server Hyper-V virtual machine, covering everything from scope configuration to high-availability DHCP failover. This lab mirrors how enterprises reliably distribute and manage IP addressing across production networks

The lab demonstrates the core Windows DHCP workflow, but production DHCP also requires IP address management, relay design, security boundaries, monitoring, backup, change control, and tested recovery. Two VMs on the same Hyper-V host don't protect against host or storage failure.

What This Lab Covers

This tutorial walks through a full DHCP lifecycle, including:

• Installing and authorizing the DHCP Server role
• Creating and configuring a DHCP scope
• Assigning IP addresses to client virtual machines
• Validating leases at the client level
• Implementing DHCP Failover (Hot Standby) for high availability
• Verifying scope replication and service continuity

Why DHCP Matters for Organizations

The Dynamic Host Configuration Protocol (DHCP) provides centralized, automated IP address management and eliminates many operational risks associated with static configuration.

DHCP ensures:

• Zero manual IP configuration on clients
• Conflict-free IP address allocation
• Faster device provisioning
• Centralized control for network administrators
• Improved resilience when paired with failover

How DHCP Works: The DORA Process

At a protocol level, DHCP follows the DORA sequence:

1. Discover: Client broadcasts a DHCP Discover message
2. Offer: Server responds with an available IP address
3. Request: Client requests the offered address
4. Acknowledge: Server confirms and assigns the lease

Understanding this flow helps with troubleshooting and packet-level analysis.

Lab Environment Overview

• Hyper-V host
• Windows Server 2019 VM (DHCP Server)
• Optional secondary Windows Server VM (Failover partner)
• Windows 10 client VM

Before starting, ensure the DHCP servers use static addresses outside the dynamic pool, the lab virtual switch doesn't expose an unauthorized DHCP service to a production LAN, and only the intended DHCP servers can answer clients. On Hyper-V networks where untrusted VMs exist, consider DHCP Guard on non-DHCP VM adapters.

**Step-by-Step Implementation **

Part 1: Install and Authorize DHCP Server on Hyper-V

• I start the Windows Server VM in Hyper-V
• Open Server Manager
• Click Add Roles and Features
• Select Role-based or feature-based installation
• Choose your server from the list
• Under Server Roles, select DHCP Server
• Confirm dependencies and click “Add Features.” → Continue the wizard and Click Install

Post-Installation

• Click Complete DHCP Configuration
• Authorize the server (domain credentials required)
• Commit changes and close the wizard

✅ Result: DHCP Server role installed and authorized in Active Directory.

Part 2: Configure DHCP Scope and Address Pool

Create a New Scope

1. Open DHCP Manager
2. Expand your server node → Right-click IPv4
3. Select **New Scope... **to launch the wizard
4. Provide:

• Scope name (e.g., Lab-Scope)
• Description

Enter the IP address range, Example.

• I start IP: 192.168.100.10
• End IP: 192.168.100.100
• Subnet Mask: 255.255.255.0

Additional Configuration

• Exclusions: 192.168.100.1–9 (reserved for static devices)
• Lease Duration: 8 days (lab-appropriate)
• Options:
  • Default Gateway: 192.168.100.1
  • DNS Server: the internal AD-aware DNS server for domain clients
  • DNS domain name: the AD DS DNS suffix
  • WINS: leave unset unless a documented legacy NetBIOS application still requires it

Activate the scope when prompted.

Don't hand domain clients a public DNS resolver as an alternate. Public DNS doesn't host the AD SRV records required for domain discovery and authentication. Configure the internal DNS server to forward unresolved external queries instead.

Choose the lease duration from device behavior and operational requirements. Eight days is a common default, not automatically “lab appropriate.” Short leases increase DHCP traffic but return addresses more quickly; long leases reduce churn but retain abandoned addresses longer.

Part 3: Assign DHCP on a Client VM

Windows Client Configuration

1. Open Control Panel → Network and Sharing Center
2. Click Change adapter settings
3. Right-click the active adapter NIC → Properties
4. Select IPv4 → Properties
5. Enable:

• Obtain an IP address automatically
• Obtain DNS server address automatically

1. Apply and close all dialogs.

Verification

I run:

ipconfig /all

Confirm the client received the expected address, prefix, gateway, DNS servers, DNS suffix, lease times, and DHCP server identifier, not merely any IPv4 address.

ipconfig /release
ipconfig /renew
ipconfig /all

Get-DhcpServerv4Lease `
    -ComputerName '<dhcp-server-fqdn>' `
    -ScopeId 192.168.100.0

Step-by-Step: DHCP Failover

Part 4: Configure DHCP Failover (High Availability)

To reduce IPv4 address-service disruption, configure DHCP failover between two Windows DHCP servers. Windows DHCP failover applies to DHCPv4 scopes, not DHCPv6 scopes.

Step 1: Prepare Both Servers

• Install and authorize DHCP on both Windows Server VMs

I use Server Manager → Add Roles and Features to install DHCP Open DHCP Console → right-click server → Authorize

Step 2: Create Failover Relationship

1. Open DHCP Manager
2. Right-click the scope → Configure Failover
3. Select the scope(s) to share
4. Enter the partner server hostname or IP

Choose Failover Mode

• Hot Standby - Primary active, secondary passive (Used in this lab)
• **Load Balance **(both servers active)

Configure Settings

• A strong shared secret for failover message authentication
• MCLT (Maximum Client Lead Time)
• Load balance percentage (if applicable) (default 50/50)

Finish the wizard.

Understand the modes before selecting one:

• Load balance is the default and lets both servers actively answer clients. It usually fits two partners at the same site.
• Hot standby keeps one partner primarily in reserve and often fits a remote-site/server design.
• MCLT controls temporary lease behavior and how quickly a surviving partner can take full responsibility; lowering it without understanding the recovery trade-off can make failover behavior worse.

The failover partners must communicate over TCP 647. Permit only the required traffic between the known server addresses.

Step 3: Verify Failover Configuration

• Expand **IPv4 → Scope **in DHCP Console
• Confirm status shows "Active"
• Ensure scope is replicated on the partner server

This confirms the relationship exists; it doesn't yet prove high availability.

Part 5: Test Failover and Recovery

I use a controlled maintenance window in the lab:

1. I record the relationship state, scope statistics, and an existing client lease.
2. I stop the DHCP Server service on the active partner or isolate it in a controlled way.
3. Renew an existing client and request a lease from a new client.
4. Observe the surviving server's failover state and lease behavior through the MCLT period.
5. Restore the partner, confirm communication returns to normal, and verify the scopes converge.
6. I review DHCP operational event logs on both servers.

Get-DhcpServerv4Failover -ComputerName '<dhcp1-fqdn>'
Get-DhcpServerv4ScopeStatistics -ComputerName '<dhcp1-fqdn>'
Get-DhcpServerv4ScopeStatistics -ComputerName '<dhcp2-fqdn>'

Failover initially copies the selected scope and active leases. Later scope-option or policy changes aren't guaranteed to appear on the partner automatically; initiate replication from the server containing the authoritative settings and verify the result. Replication overwrites the partner's corresponding settings, so confirm the source before starting it.

Troubleshooting Checklist

• Confirm both servers are authorized in AD DS and their clocks/DNS are healthy.
• Confirm the scope is active and has free addresses after exclusions and reservations.
• Ensure the same scope wasn't manually created on the partner before establishing failover.
• I check UDP 67/68 between clients/relay and servers, and TCP 647 between failover partners.
• For remote subnets, verify the router or relay forwards DHCP to both intended servers.
• I inspect Microsoft-Windows-DHCP Server Events/Operational and the failover relationship state.
• I use packet capture only after verifying configuration and logs.

Security and Operations

• Delegate DHCP administration rather than using Domain Admin for routine work.
• Back up DHCP configuration and document restoration procedures.
• Monitor pool utilization, declines, conflict detection, service state, failover state, and event logs.
• I use reservations only for documented cases; infrastructure servers should normally have planned static configuration.
• Integrate DHCP changes with IP address management so exclusions, reservations, DNS records, and physical allocations don't drift apart.

Lab Outcome

• Seamless IP address provisioning
• High availability through DHCP Failover
• Real-time client lease assignment
• Conflict-free IP management
• Enterprise-grade DHCP architecture in a virtualized environment

Key Takeaway

Even in highly automated and cloud-driven infrastructures, DHCP remains a foundational service.

A properly designed DHCP deployment ensures the following:

• Network stability
• Scalability
• Operational resilience
• Faster onboarding of systems and devices

This lab demonstrates how DHCP is deployed **the way enterprises do it: **structured, redundant, and reliable.

Continue with the domain-join guide to verify that DHCP clients receive the internal DNS settings required for AD DS. I review the secondary domain controller lab before placing DHCP and DNS dependencies on a single server.