Network Management

DHCP scopes have been imported with "[INVALID]" at the end of the scope name in IPAM

This article provides information and a resolution for the issue of IPAM DHCP scopes that have been imported with "[INVALID]" at the End of the Scope Name.

First published date

9/28/2026 4:09 PM

Last published date

9/28/2026 6:17 PM

Overview

IPAM keeps DHCP scopes and their linked IPAM subnets in sync through scheduled DHCP scans against the DHCP server. Two distinct conditions can produce the "[INVALID]" symptom:

  • Subnet/CIDR mismatch – "[INVALID]" is appended to a scope's name when the IP address or CIDR of the DHCP scope no longer matches the address/CIDR of the subnet it is linked to in IPAM (for example, after the subnet mask was changed on the DHCP server). IPAM cannot reconcile the mismatched scope-to-subnet mapping automatically, so the scope is flagged and the corresponding subnet is not exposed correctly in IPAM.

  • Failed/hung DHCP scan due to an unmanaged backing node – DHCP polling in IPAM depends on the Orion node object tied to the DHCP server. If that node is set to Unmanaged in Orion, the DHCP scope sync job fails (or hangs in a "waiting" state indefinitely) instead of returning a clear error. Because the scan cannot complete, scopes stop being refreshed and can be left showing "[INVALID]" or missing from IPAM entirely, with no explicit error surfaced to the user.

Product section

IP Address Manager

Cause

Subnet/CIDR mismatch

Failed/hung DHCP scan due to an unmanaged backing node

Resolution

  1. Back up the database before making any changes.

  2. Check the backing SolarWinds Platform node status for the affected DHCP server:

    • In the SolarWinds Platform, locate the node associated with the DHCP server and confirm whether it is Unmanaged.

    • If it is Unmanaged, re-manage the node, then remove and re-add the DHCP server in IPAM if scans continue to hang.

    • Re-run the DHCP scan. In the confirmed case, the scan completed successfully in about 30 minutes once the node was re-managed.

  3. If scopes still show "[INVALID]" after the node/scan is healthy (typically a subnet/CIDR mismatch):

    • In IPAM > DHCP Management, select the affected "[INVALID]" scope(s) and delete them.

    • In the confirmation popup, also select "Remove corresponding subnets" — this deletes the stale scope and its matching subnet from IPAM so they can be re-imported cleanly. (Confirm with the customer first, since any manually entered data on those subnets/IPs will need to be re-entered.)

    • Run a scan of the matching DHCP server(s) to re-import the deleted scopes.

    • After the scan completes, IPAM should show "One or more new scopes have been found…" — add the found scopes from the linked page, or via /orion/ipam/admin/admin.dhcpscopeorphans.aspx.

    • If "[INVALID]" persists, it usually means a subnet with a different CIDR still exists; re-scan the server (repoll, or select the server and choose Scan to force a poll) to pull the scopes back in.

  4. If a WMI-polled DHCP server (Windows DHCP) is involved, also verify:

    • The DHCP polling account is a member of the local DHCP Admins/DHCP Users group (an AD Admin account alone is not sufficient).

    • WMI connectivity works (test with wbemtest, connecting to namespace root\microsoft\windows\dhcp).

    • The Engine ID assigned to the DHCP server/subnets matches the polling engine actually responsible for it (a mismatched Engine ID was found to contribute to scopes not syncing in this case).