Context
A new client cannot obtain an address while existing clients still communicate. The DHCP service may be running normally, but the relevant scope may lack an available address. A scope groups the address range and options for a subnet; its usable capacity depends on more than the first and last address displayed in a console.
Prepare the affected client subnet, relay path, DHCP servers and failover relationship where used. Use a designated test client and retain lease evidence privately because records contain device identifiers. Do not delete active leases as an exploratory capacity fix; clients may continue using those addresses until their own state changes.
Identify the correct address pool
- Confirm the client reaches the intended scope. Review its network placement, relay information and server-side evidence. A capacity graph for another subnet is irrelevant even if it is on the same DHCP server. Check whether scope state or a policy directs this client group into a different allocation path.
- Run
Get-DhcpServerv4ScopeStatisticsfor the verified scope and server through approved management access. Include failover-aware statistics where applicable. Record a timestamp and compare free/in-use information with the configured range, exclusions and reservations. A broad range can contain much less generally assignable capacity than expected. - Inspect selected records with
Get-DhcpServerv4Lease, using the intended scope and supported state options. Look for unusual client growth, expired records and declined or bad-address evidence where present. Summarize counts and patterns rather than publishing a complete MAC-address inventory. Different record states require different interpretations. - Review lease duration and device churn with the network owner. Short-lived visitors, virtual machines or changing client identifiers can alter demand. A shorter lease can improve turnover in some designs but also increases renewal activity; it is not a universal cure for insufficient addresses or a wrong relay mapping.
An illustrative apparent spare range
In an illustrative office network, the console shows a large configured range, but most of it is excluded for a migration that already finished. New clients exhaust the smaller usable pool. Clearing active leases would create churn without adding addresses. The team reconciles the exclusion inventory and confirms address ownership before making a targeted pool change.
| Observation | Evidence to check | Likely boundary |
|---|---|---|
| Existing clients work, new clients fail | Free scope capacity and offer evidence | Allocation shortage is plausible |
| Server has space, scope does not | Exact client subnet and scope | Wrong capacity scope |
| Unexpected lease growth | Client identifiers and deployment events | Device churn or demand change |
| Failover peers disagree | Relationship state and scoped statistics | Allocation context needs review |
Correct and verify allocation
Choose a demonstrated correction: restore the intended relay/scope mapping, resolve obsolete exclusions through the address owner or provision a valid subnet-capacity change. Expanding a pool requires checking network design and other static users; an apparently unused address is not proof it is unassigned.
Verify a fresh lease on the test client, including address, mask, gateway and DNS options. Confirm renewal and ordinary application connectivity. Inspect server evidence for the successful allocation and ensure no address-conflict symptoms appear. A lease alone does not prove the client received the correct network options.
Maintain a capacity SOP
Monitor usable free addresses by scope and trend demand during normal peaks. Record exclusions, reservation owners, lease rationale and failover responsibilities. Include safe client testing and escalation in the runbook. Clouvenix Windows administration can help keep DHCP capacity and address ownership aligned.