Estimated Time
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.
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.
| Evidence | Synthetic value | Interpretation boundary |
|---|---|---|
| Scope state | Active | The scope is enabled; this does not prove free capacity. |
| Configured range | 192.0.2.20–192.0.2.220 | 201 addresses in the inclusive span before exclusions and reservations. |
| Percentage in use | 94% | High utilization; not complete exhaustion by itself. |
| Free-address count | 11 | Addresses remain according to this server snapshot. |
| Lease-state totals | Active 171; Offered 1; Declined 2; Expired 4 | Records have different meanings; counts do not prove device presence. |
| Reservations | 12 | Reserved addresses are not generally allocatable to other clients. |
| Exclusions | 192.0.2.20–192.0.2.29 | Ten addresses are excluded from DHCP offers. |
| Lease duration | 8 days | Policy evidence only; shortening it is not automatically appropriate. |
| Failover state | Load balance; Normal | Partner evidence is still needed before a relationship-wide conclusion. |
| Monitoring timestamp | 2026-08-22 14:00 UTC | Compare with the alert's collection method and target. |
| DHCP evidence timestamp | 2026-08-22 14:07 UTC | The 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.
| Conclusion | Minimum support | Boundary |
|---|---|---|
| Confirmed exhaustion | Authoritative free count is zero at the relevant time and scope. | The cause and approved response remain separate questions. |
| High utilization with remaining capacity | Threshold exceeded while the authoritative free count is above zero. | Do not describe the scope as exhausted. |
| Monitoring mismatch | Monitor and server differ in target, inputs, timestamps, or calculation. | Reconcile the measurement before planning a change. |
| Capacity reduced by reservations or exclusions | Authoritative objects show addresses unavailable to general dynamic clients. | Do not assume those boundaries are incorrect. |
| Evidence incomplete | Required scope, lease, relationship, timing, or symptom evidence is missing. | State the unknown; do not fill it with an assumption. |
| Change planning required | Demand 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 tutorialDomain dependencies
Investigate DNS and Active Directory
Correlate client DNS, locator records, domain discovery, replication, time, services, and logs.
Open domain-health investigationDNS 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 tutorialLearning hub
Windows & Hybrid
Connect addressing evidence with Windows, DNS, Active Directory, server, and hybrid dependencies.
Open Windows & HybridMethod
MSP University
Use the understand, investigate, resolve, and verify sequence without jumping from alert to change.
Review the learning pathTools
PowerShell Library
Review KrippyTech's published read-only troubleshooting tools and their verification guidance.
Open PowerShell LibraryOfficial Microsoft references
Verify every DHCP command and scope concept.
DhcpServer module
Microsoft's cmdlet inventory for DHCP Server management.
Read Microsoft LearnDHCP scopes
Microsoft's scope, range, exclusion, reservation, option, and superscope planning guidance.
Read Microsoft LearnGet-DhcpServerv4Scope
Retrieves IPv4 scope configuration.
Read Microsoft LearnGet-DhcpServerv4ScopeStatistics
Retrieves scope statistics and optional failover-related values.
Read Microsoft LearnGet-DhcpServerv4Lease
Retrieves active or all lease states for a specified scope.
Read Microsoft LearnGet-DhcpServerv4Reservation
Retrieves reservations by scope, address, or client identifier.
Read Microsoft LearnGet-DhcpServerv4ExclusionRange
Retrieves excluded ranges for specified scope identifiers.
Read Microsoft LearnGet-DhcpServerv4OptionValue
Retrieves IPv4 option values at server, scope, or reservation level.
Read Microsoft LearnGet-DhcpServerv4Failover
Retrieves failover relationships by name or scope identifier.
Read Microsoft LearnGet-DhcpServerv4Superscope
Retrieves superscope configuration and associated scopes.
Read Microsoft Learn