Windows Server / DHCP / Capacity

Investigating DHCP Scope Capacity and Address Exhaustion

Determine whether a capacity alert reflects genuine address pressure, complete exhaustion, stale lease evidence, or a monitoring mismatch. Move from the alert to authoritative scope evidence, interpret allocation carefully, state what remains unknown, and escalate before changing production DHCP.

Estimated Time

25–35 Minutes

Difficulty

Intermediate

Technologies

Windows Server / DHCP / PowerShell

Change Boundary

Evidence Collection Only

Capacity alert

Translate the percentage into an operational question.

A DHCP capacity alert usually means a monitoring system calculated that a scope crossed a utilization threshold. It does not, by itself, establish exhaustion, identify which addresses are consuming capacity, or prove that clients cannot obtain leases.

High utilization

Some capacity may remain

A scope can exceed a warning threshold while still reporting free addresses. Record the threshold, free count, scope state, evidence time, and whether clients are affected.

Complete exhaustion

No allocatable address is available

Confirm this with authoritative DHCP statistics captured at the same time as the symptom. A full scope still does not explain why addresses are consumed.

Monitoring mismatch

The calculation may use different inputs

The alert may target another server, scope, failover partner, or timestamp, or may calculate capacity without correctly accounting for exclusions, reservations, or lease states.

Investigation sequence: Capacity alert → scope evidence → allocation analysis → operational impact → verified conclusion → escalation boundary.

Requirements and authorization

Confirm the management boundary before querying DHCP.

Use Windows PowerShell on a supported Windows administrative system with the DHCP Server tools or RSAT DHCP components and the DhcpServer module available. PowerShell 7 may use compatible Windows modules on Windows, but these examples are validated against the Windows PowerShell behavior documented for the module.

Authorization is required

The account and computer must be authorized to read the target DHCP server. Organizational permissions, firewall policy, remoting requirements, and server hardening can restrict retrieval even though every command in this guide is read-only. Do not request broader access than the investigation requires.

Get-Module -ListAvailable -Name DhcpServer
Get-Command -Name Get-DhcpServerv4Scope, Get-DhcpServerv4ScopeStatistics,
    Get-DhcpServerv4Lease, Get-DhcpServerv4Reservation,
    Get-DhcpServerv4ExclusionRange, Get-DhcpServerv4OptionValue,
    Get-DhcpServerv4Failover, Get-DhcpServerv4Superscope

If the module or commands are unavailable, stop and use the approved tooling process. This tutorial does not install management components or alter access.

Investigation scope

Use one synthetic server and scope throughout the examples.

Replace these documentation-only values only after confirming the authorized DHCP server and affected scope. Do not substitute a client address for the scope identifier.

$dhcpServer = 'LAB-DHCP-01.example.test'
$scopeId = '192.0.2.0'

LAB-DHCP-01.example.test and 192.0.2.0/24 are synthetic documentation values. They do not identify a customer, tenant, server, or production network.

Scope evidence

Confirm boundaries, state, and lease duration first.

The start and end ranges define the inclusive address span configured for the scope. The total span is the end address minus the start address plus one. Exclusions are not offered, and reservations commit addresses to designated clients, so both reduce capacity available to general dynamic clients.

$scope = Get-DhcpServerv4Scope -ComputerName $dhcpServer -ScopeId $scopeId
$scope | Select-Object ScopeId, Name, State, StartRange, EndRange,
    SubnetMask, LeaseDuration

Start and end

Define the configured span

Count the range inclusively, then account for exclusions and reservations before describing capacity available to general dynamic clients.

Scope state

Separate availability from utilization

An inactive scope and an exhausted active scope are different operational conditions. Neither condition alone explains the cause.

Lease duration

Record policy without changing it

Lease duration affects how long assignments can remain valid. A shorter duration is not automatically the correct response to pressure.

Authoritative statistics

Compare percentage in use with the absolute free count.

Percentage and free-address count answer different questions. Capture them together and include failover-related statistics when the scope participates in a failover relationship.

$statistics = Get-DhcpServerv4ScopeStatistics -ComputerName $dhcpServer `
    -ScopeId $scopeId -Failover
$statistics | Select-Object ScopeId, Free, InUse, PercentageInUse,
    Reserved, Pending, SuperscopeName

Do not conclude from the percentage alone

High utilization does not automatically prove exhaustion. Confirm the absolute free count, current scope state, alert timestamp, authoritative DHCP timestamp, lease states, reservations, exclusions, and operational symptoms.

Lease allocation

Group lease states instead of exposing complete records.

Without -AllLeases, the lease cmdlet returns active leases for the scope. Use -AllLeases when the approved investigation requires active and nonactive states, then group the result so client names, identifiers, and individual addresses are not displayed unnecessarily.

$leaseStateTotals = Get-DhcpServerv4Lease -ComputerName $dhcpServer `
    -ScopeId $scopeId -AllLeases |
    Group-Object -Property AddressState |
    Sort-Object -Property Name |
    Select-Object Name, Count
$leaseStateTotals

Active

A current lease record exists

This supports allocation analysis, but it does not prove the client is physically present, reachable, authorized, or still using the address.

Offered, declined, or expired

State changes the interpretation

Nonactive records can explain why raw record counts differ from current use. Preserve the state and timestamp rather than labeling every record stale.

Counts only

Minimize sensitive output

Escalate with grouped totals unless an authorized reviewer needs a specific lease record to answer a defined question.

Reservations and exclusions

Account for addresses that are not generally allocatable.

Reservations dedicate addresses to known clients, while exclusions prevent DHCP from offering specified ranges. Count reservations and review exclusion boundaries without displaying client identifiers.

$reservationCount = @(
    Get-DhcpServerv4Reservation -ComputerName $dhcpServer -ScopeId $scopeId
).Count

$exclusions = Get-DhcpServerv4ExclusionRange -ComputerName $dhcpServer `
    -ScopeId $scopeId
$exclusions | Select-Object ScopeId, StartRange, EndRange

[pscustomobject]@{ ReservationCount = $reservationCount }

Do not assume that every reservation is actively leased or that every excluded address is incorrectly configured. These objects establish allocation boundaries; intent and ownership still require review.

Options, superscopes, and failover

Understand the wider DHCP relationship without changing it.

Scope options can identify the router, DNS servers, and domain information delivered to clients, but they do not measure capacity. Superscopes group scopes administratively, and failover changes how partner state and ownership should be interpreted.

Get-DhcpServerv4OptionValue -ComputerName $dhcpServer -ScopeId $scopeId `
    -OptionId 3, 6, 15 |
    Select-Object OptionId, Value

Get-DhcpServerv4Superscope -ComputerName $dhcpServer |
    Select-Object SuperscopeName, ScopeId

Get-DhcpServerv4Failover -ComputerName $dhcpServer -ScopeId $scopeId |
    Select-Object Name, PartnerServer, Mode, State, ScopeId

Multiple scopes

Investigate each scope separately

Capacity in one scope does not automatically satisfy clients on another subnet. Confirm the affected subnet, relay path, and scope identifier.

Superscope

Administrative grouping is not one flat pool

Identify associated scopes and subnet intent before combining totals or assuming that addresses can be used interchangeably.

Failover

Partner state affects interpretation

Compare relationship mode, state, partner, and failover-aware statistics. Do not treat one server's local perspective as the entire relationship.

Allocation analysis

Separate genuine demand from stale or mismatched evidence.

Evidence suggesting demand

Aligned growth and active use

Scope statistics show sustained growth at aligned timestamps, active lease totals rise with known device demand, free capacity falls, and server evidence agrees with monitoring.

Evidence suggesting stale records

Nonactive states dominate the discrepancy

Expired, declined, or offered records explain a raw lease count that exceeds authoritative in-use statistics. This is a reason to investigate, not permission to delete leases.

Evidence suggesting monitoring error

Inputs, target, or time do not match

The alert uses another scope, partner, timestamp, or calculation, or it treats exclusions and reservations differently from the DHCP server's authoritative statistics.

Synthetic evidence table

Correlate the alert with one minimized DHCP snapshot.

Every value below is invented and documentation-safe. The table illustrates evidence structure, not a production threshold or prescribed response.

EvidenceSynthetic valueInterpretation boundary
Scope stateActiveThe scope is enabled; this does not prove free capacity.
Configured range192.0.2.20–192.0.2.220201 addresses in the inclusive span before exclusions and reservations.
Percentage in use94%High utilization; not complete exhaustion by itself.
Free-address count11Addresses remain according to this server snapshot.
Lease-state totalsActive 171; Offered 1; Declined 2; Expired 4Records have different meanings; counts do not prove device presence.
Reservations12Reserved addresses are not generally allocatable to other clients.
Exclusions192.0.2.20–192.0.2.29Ten addresses are excluded from DHCP offers.
Lease duration8 daysPolicy evidence only; shortening it is not automatically appropriate.
Failover stateLoad balance; NormalPartner evidence is still needed before a relationship-wide conclusion.
Monitoring timestamp2026-08-22 14:00 UTCCompare with the alert's collection method and target.
DHCP evidence timestamp2026-08-22 14:07 UTCThe seven-minute difference limits direct comparison.

Supported conclusion for this synthetic snapshot: High utilization with remaining capacity. Complete exhaustion is not confirmed. The monitoring calculation and failover partner view remain required next checks.

Conclusion model

Name the evidence state without prescribing a fix.

ConclusionMinimum supportBoundary
Confirmed exhaustionAuthoritative free count is zero at the relevant time and scope.The cause and approved response remain separate questions.
High utilization with remaining capacityThreshold exceeded while the authoritative free count is above zero.Do not describe the scope as exhausted.
Monitoring mismatchMonitor and server differ in target, inputs, timestamps, or calculation.Reconcile the measurement before planning a change.
Capacity reduced by reservations or exclusionsAuthoritative objects show addresses unavailable to general dynamic clients.Do not assume those boundaries are incorrect.
Evidence incompleteRequired scope, lease, relationship, timing, or symptom evidence is missing.State the unknown; do not fill it with an assumption.
Change planning requiredDemand and risk justify evaluating an environment-specific response.Separate written scope, ownership, testing, rollback, and approval are required.

Evidence limits

State what the snapshot proves and what it cannot prove.

Observation

DHCP reported specific values

The captured objects establish scope configuration, statistics, lease-state totals, reservations, exclusions, options, and relationship data returned by the queried server at collection time.

Possible interpretation

Demand or measurement may explain the alert

Aligned growth may suggest genuine demand; nonactive lease states or mismatched inputs may suggest stale or inaccurate monitoring.

Unknown

The cause and client impact remain open

A full scope does not identify why addresses are consumed. Lease counts do not prove every device is present, and scope data does not prove relay, VLAN, routing, DNS, or application health.

Required next check

Answer the narrow unresolved question

Align timestamps, confirm the affected scope and partner, correlate client symptoms, and compare authoritative server data with the monitoring formula.

Change requiring approval

Plan outside this investigation

Expanding the range, shortening lease duration, deleting leases, changing exclusions or reservations, modifying options or failover, or altering the subnet requires separate planning and authorization.

Privacy and ticket handling

Collect the minimum DHCP evidence needed.

DHCP data can expose client names, IP addresses, MAC addresses or client identifiers, reservations, server names, domain information, and network ranges.

Do not retain full live lease records unnecessarily

Prefer grouped state totals and targeted fields. Keep raw authorized evidence only in the approved case location, redact unrelated identifiers before escalation, record who collected it and when, and never paste live DHCP output into public channels or repositories.

Escalation and change planning

Preserve service stability while the evidence is reviewed.

Client impact

Escalate active allocation failures

Escalate when authorized evidence shows zero free capacity, clients cannot obtain leases, multiple scopes are affected, or an outage is active.

Ownership

Escalate unclear network intent

Stop when reservations, exclusions, relay paths, superscopes, failover ownership, subnet boundaries, or monitoring calculations are not understood.

Risk

Escalate before disruption

Deleting leases can disrupt legitimate clients. Expanding a range without subnet and routing review can create conflicts. Shortening lease duration can increase renewal traffic and is not an automatic fix.

This guide authorizes evidence collection only. Any production change requires an identified owner, impact analysis, subnet and routing review where applicable, failover review, testing, rollback planning, maintenance coordination, and explicit approval.

Related KrippyTech resources

Continue with the dependency that matches the evidence.

Local evidence

Inspect Windows network configuration

Capture active adapter, address, gateway, DNS-server, and network-profile evidence from the affected client.

Open Get-KTNetworkConfig tutorial

Domain dependencies

Investigate DNS and Active Directory

Correlate client DNS, locator records, domain discovery, replication, time, services, and logs.

Open domain-health investigation

DNS query

Use Test-KTDNS safely

Verify one resolver, record type, and normalized result without treating DNS alone as end-to-end health.

Open Test-KTDNS tutorial

Learning hub

Windows & Hybrid

Connect addressing evidence with Windows, DNS, Active Directory, server, and hybrid dependencies.

Open Windows & Hybrid

Method

MSP University

Use the understand, investigate, resolve, and verify sequence without jumping from alert to change.

Review the learning path

Tools

PowerShell Library

Review KrippyTech's published read-only troubleshooting tools and their verification guidance.

Open PowerShell Library

Official Microsoft references

Verify every DHCP command and scope concept.

DHCP scopes

Microsoft's scope, range, exclusion, reservation, option, and superscope planning guidance.

Read Microsoft Learn