DHCP reservations vs static IPs for printers, servers and IoT

Most address conflicts in small networks come from one ambiguity: a device has a “fixed” address, but nobody can say whether it is fixed on the device or fixed on the DHCP server. The printer on 10.10.1.50 was set by hand in 2019, the DHCP scope later grew to cover .50, and one Monday a laptop gets it. The fix is not a better spreadsheet column; it is a clear policy for which devices get a reservation, which get a true static, and where each kind lives in your address plan.

The two options, precisely

A static IP is configured on the device itself: address, mask, gateway and DNS typed into the NIC settings. The DHCP server knows nothing about it. It keeps working when DHCP is down, and it stays wrong forever if someone mistypes the gateway.

A DHCP reservation keeps the device on DHCP, but the server always hands it the same address, matched by MAC address or client identifier. Options such as DNS servers, gateway and NTP still come from the scope, so changing them later is one edit on the server rather than a visit to every device.

Neither is “better”. They fail differently, and that decides where each belongs.

A practical rule set

The dividing question: does this device need to be reachable while DHCP is broken, or is it part of what makes DHCP work? If yes, static. If no, a reservation gives you central control.

Lay out the scope so the two never overlap

Carve each subnet into zones and write them into your IPAM:

1. .1–.9 network infrastructure (static).
2. .10–.49 servers and other statics.
3. .50–.99 reservations, still outside the dynamic pool.
4. .100–.250 dynamic pool.

Keeping reservations out of the pool is not strictly required by every server, but it makes the record readable and avoids a common edge case: you create a reservation for an in-pool address that is already leased to a different client, and two devices argue over it until the old lease expires.

Creating reservations on Windows Server

The DhcpServer PowerShell module handles single reservations, bulk imports and lease conversions:

# one printer
Add-DhcpServerv4Reservation -ComputerName dhcp01 -ScopeId 10.10.1.0 `
  -IPAddress 10.10.1.60 -ClientId "F0-DE-F1-7A-00-5E" `
  -Name "prn-reception" -Description "MFP reception, ticket 4812"

# turn an existing lease into a reservation
Get-DhcpServerv4Lease -ComputerName dhcp01 -IPAddress 10.10.1.137 |
  Add-DhcpServerv4Reservation -ComputerName dhcp01

# bulk import: CSV columns ScopeId,IPAddress,Name,ClientId,Description
Import-Csv .\reservations.csv | Add-DhcpServerv4Reservation -ComputerName dhcp01

If you use DHCP failover, replicate the scope afterwards (Invoke-DhcpServerv4FailoverReplication) so the partner server has the same reservations.

Protect the static ranges with exclusions so the pool can never grow over them by accident:

Add-DhcpServerv4ExclusionRange -ComputerName dhcp01 -ScopeId 10.10.1.0 `
  -StartRange 10.10.1.1 -EndRange 10.10.1.49

Creating reservations in ISC Kea

Kea defines reservations inside the subnet. Each subnet4 entry needs a unique id:

"subnet4": [
  {
    "id": 10,
    "subnet": "10.10.1.0/24",
    "pools": [ { "pool": "10.10.1.100 - 10.10.1.250" } ],
    "reservations": [
      { "hw-address": "f0:de:f1:7a:00:5e", "ip-address": "10.10.1.60", "hostname": "prn-reception" },
      { "hw-address": "3c:52:82:11:22:33", "ip-address": "10.10.1.61", "hostname": "cam-lobby" }
    ]
  }
]

If every reservation in a subnet is outside the pool, Kea’s "reservations-out-of-pool": true lets the server skip some per-lease checks. Kea does not sanity-check that flag against your data, so only set it when the layout above is actually enforced.

Keeping the record and the server in agreement

A reservation that exists on the DHCP server but not in your IPAM is still an undocumented address. Pick one direction of truth: either the IPAM is edited first and changes are pushed to DHCP, or the DHCP server is authoritative and the IPAM imports from it. Tools such as SolarWinds IPAM and ManageEngine OpUtils can read Microsoft DHCP scopes directly; open-source options like phpIPAM usually need a script or periodic export. Whichever you choose, run a scheduled comparison and treat differences as tickets.

Common mistakes

• Static addresses inside the dynamic pool. The classic conflict. Always pair a static range with an exclusion.
• Reserving by the wrong identifier. Some devices send a client ID that isn’t the bare MAC; copy it from an existing lease rather than the label on the box.
• Randomized MACs. Modern phones and laptops use per-network private MACs, which breaks reservations. Don’t reserve end-user devices; if you must, disable the randomization for that SSID on the device.
• Changing a NIC without updating the reservation. A replaced motherboard or USB adapter means a new MAC and a new dynamic address.
• Forgetting the failover partner. One server has the reservation, the other doesn’t, and the device changes address after a failover.
• Documenting nowhere. A reservation’s description field is not an IPAM.

Next steps

To check that an address is really unused before you reserve it, follow finding genuinely free addresses in a subnet. For tools that keep DHCP and the record together, see the IPAM software category and SolarWinds IPAM vs ManageEngine OpUtils.