A new laptop joins the office Wi-Fi but receives no usable connection. An existing employee reconnects and works normally. That pattern can look like a wireless fault even when the access point is healthy: the network may have no address left to lease to the new device.
DHCP assigns IP settings to clients for a limited time. A scope can fill because the office has grown, lease times are unsuitable, stale clients remain, reservations consume space, or an unexpected device population is using the subnet. This guide shows what to check before simply making the address range larger.
Confirm that address assignment is the failing stage
Record the affected network, location, device type and time. Check the device's IP address, default gateway and DNS settings. An address in the self-assigned 169.254.0.0/16 range on Windows is a strong clue that the client did not receive a normal IPv4 lease, but it does not by itself prove scope exhaustion.
Compare one affected device with a working device on the same staff network. If only the guest network works, or only one VLAN is affected, keep those boundaries in the investigation. Do not move a device onto a less restricted network as a permanent workaround.
Microsoft's DHCP troubleshooting guidance recommends checking that the server is running and authorised, leases are available in the correct scope, no unexpected BAD_ADDRESS entries exist, static addresses are excluded appropriately, server bindings are correct and only the intended service is listening on DHCP ports.
Read the scope before changing it
From the DHCP service or gateway that owns the affected subnet, capture these facts:
- scope network and mask;
- start and end of the dynamic pool;
- active leases, available addresses and utilisation trend;
- lease duration;
- exclusions and reservations;
- relay or helper configuration between VLANs;
- recent low-capacity, scope-full, conflict or service events.
Windows Server records specific DHCP events for low or exhausted ranges. Microsoft's current DHCP event reference includes scope-full and low-address warnings. Other firewall, router and cloud-managed network platforms expose equivalent utilisation or lease views, though their names differ.
A full scope can be real capacity pressure, but it can also be misleading. A rogue DHCP server may hand out the wrong settings; a failed relay may prevent requests from reaching a scope with plenty of room; duplicate static addresses can create conflicts; or a client may be placed in the wrong VLAN.
Account for every class of address
Build a simple inventory instead of counting employees. Include phones, tablets, printers, meeting-room systems, scanners, access points, cameras, building controllers, test devices and visitor devices. Many people bring more than one client, and privacy features can cause a device to use different hardware addresses over time.
Separate fixed infrastructure from the general dynamic pool. A printer with a manually configured address inside that pool can collide with a future lease unless it is excluded or handled through a reservation. Document each reservation's owner and purpose; abandoned reservations silently reduce usable capacity.
If the address problem is intermittent or isolated to one floor, ITZ's office network setup service can review DHCP, VLAN and switching dependencies together. Request a DHCP Capacity Review with the affected site, network name, approximate device count and a sanitised error description.
Choose the least disruptive correction
The correct change depends on the evidence.
- Stale or abandoned entries: investigate why they remain before removing them through the platform's supported process.
- Lease duration mismatched to turnover: adjust it carefully. Shorter leases can release guest addresses sooner but increase renewal traffic and do not fix poor segmentation.
- Unexpected clients: identify them and review access control rather than rewarding unmanaged growth with more space.
- Legitimate sustained growth: plan a larger subnet or additional VLAN with the router, firewall, DHCP, DNS, access-control and monitoring effects considered together.
- Relay or server fault: repair the request path or service instead of resizing a healthy scope.
Changing a subnet mask can affect gateways, access-control rules, static devices, VPN routes and monitoring. Treat it as a network change with a rollback plan, not a quick slider adjustment.
Validate with new and returning clients
After the approved change, test a new client and a returning client on each affected VLAN. Confirm that each receives an address from the intended range, the correct gateway and DNS servers, can reach permitted internal resources, and has the expected internet access. Verify that the isolated guest network remains isolated; the guest Wi-Fi isolation checklist covers that separate control.
Monitor free capacity after the change and during a representative busy period. A one-minute successful test does not establish that the pool will survive the next staff meeting, training day or visitor event.
Request a DHCP capacity review
Tell ITZ which site, SSID or wired network is affected; the approximate number and type of devices; the current subnet and available-address evidence if known; and whether the problem is constant or time-dependent. We can discuss a scope covering DHCP health, reservations, VLAN boundaries, capacity and controlled remediation.
