Windows Server / Intermediate: integration and workload lifecycle / Lesson 7

DHCP scopes, leases, options, and failover

Trace address assignment and client configuration without treating DHCP as application authorization. Separate pool capacity, exclusions, reservations, renewal, relay, and role-specific availability.

About 4 min readContent reviewed 2026-10-26

On this page

Lesson goals

Explain lease and option ownership.
Calculate a bounded synthetic pool correctly.
Distinguish DHCP failover from generic clustering.

A lease supplies configuration for a period

DHCP can provide an address and related settings such as subnet mask, router, DNS servers, and domain information under the configured contract. For IPv4, discovery, offer, request, and acknowledgement describe a common initial exchange, while renewal and rebinding have their own timing. A missing lease does not identify one universal cause, and an existing lease does not prove DNS or application access works. Record client identity, subnet/relay context, server, scope, lease state, options, and time from safe evidence. No packet exchange, lease request, or network action is performed in this course.

Capacity depends on distinct address sets

A scope’s range, exclusions, reservations, active leases, and conflicts must be interpreted without double counting. A reservation maps a client identifier under the product’s rules; it is not strong user authentication. The offline model starts with fifty documentation-range host numbers, excludes five, reserves another five, and records thirty-five active dynamic allocations, leaving five. It is an invented set calculation, not a DHCP export or a claim about Windows lease database behavior. Real planning also includes growth, lease duration, replacement overlap, and the required relay/server reachability. Do not shorten every lease blindly to repair an exhausted pool.

python Offline pool-set arithmetic

pool = set(range(100, 150))
excluded = set(range(100, 105))
reserved = set(range(105, 110))
active = set(range(110, 145))
free = pool - excluded - reserved - active
print(len(pool), len(free))

Expected output

50 5

The numbers refer to synthetic host positions only. No address is requested, reserved, leased, or changed.

A valid address with wrong options can still break the task

Wrong DNS, router, or suffix settings can make a client appear connected while internal discovery fails. Scope, server, reservation, and policy-based settings have documented precedence and context; inspect the actual delivered options rather than assuming the intended value won. Relay configuration and scope selection matter when broadcasts do not reach the server directly. The JSON record below separates address allocation from option correctness and application evidence. It is not a Windows configuration payload. Preserve the original client path and do not edit a shared scope merely because one unrelated machine succeeds with manually assigned settings.

json A synthetic DHCP diagnostic record

{
  "model": "lease-evidence-only",
  "client": "synthetic-client",
  "allocation": "modeled-valid",
  "verify_separately": [
    "DNS-option",
    "router-option",
    "suffix",
    "relay-and-scope",
    "application-task"
  ]
}

Expected output

address allocation alone does not establish complete client configuration

No scope, option, reservation, relay, service, or client setting is read or modified.

DHCP failover has its own protocol and scope

Windows DHCP failover provides supported IPv4 scope availability under its relationship and mode requirements; do not assume it covers every IPv6 or generic server role scenario. Lease replication and state transitions require deliberate design and monitoring. A partner relationship is not a backup or a proof that both network paths and directory prerequisites work. In domain-integrated environments, DHCP authorization is a separate control with limits; it does not make every rogue device on a network incapable of offering addresses. Review network protection and supported deployment rules, and keep directory administration in the sibling Active Directory course.

Verify new clients, renewal, and degraded service separately

A DHCP outage does not instantly invalidate every existing client lease; new acquisition and later renewal/rebinding can fail differently. A future authorized lab should test clean acquisition, delivered options, renewal, partner behavior, exhaustion, relay failure, and application discovery with synthetic clients. Preserve safe event and timing evidence without collecting private identifiers unnecessarily. This course starts no DHCP service, authorizes no server, edits no scope, renews no lease, and runs no Windows or network command. Its models cannot establish actual failover, lease persistence, directory authorization, or client connectivity. Report those boundaries honestly.

Common errors and fixes

A full-looking range is assumed to be fully available

Why it happens: Exclusions, reservations, leases, and conflicts are omitted.
How to fix it: Compare distinct address sets and actual scope state.
Prevent it next time: Plan growth and verify exhaustion with owned fixtures.

An assigned address is called working DNS

Why it happens: Allocation and delivered option correctness are conflated.
How to fix it: Inspect actual options and the client’s resolver path.
Prevent it next time: Test application discovery after lease acquisition.

A failover relationship is assumed to cover every network role

Why it happens: Service-specific availability is confused with generic clustering.
How to fix it: Review supported IPv4 scope and relationship semantics.
Prevent it next time: Keep role-specific failure tests and backup plans separate.

Check your understanding

1. Why does the model leave five addresses rather than fifteen?

Show worked solution

The fifty-element range loses five exclusions, five distinct reservations, and thirty-five active allocations. The sets are deliberately disjoint, so five remain. This does not prove a real DHCP pool state or reservation precedence; actual server evidence must interpret the configured scope and client identities.

2. Do all clients immediately lose connectivity when DHCP stops?