Submit a ticketCall us

Solarwinds & Cisco Live! Barcelona
Join us from the 29th of January to the 2nd of February at Cisco Live 2018 in Barcelona, where we will continue to show how monitoring the network with SolarWinds will keep you ahead of the game. At our booth (WEP 1A), we will demonstrate how SolarWinds network solutions can help. As a bonus, we are also hosting a pre-event webinar - Blame the Network, Hybrid IT Edition with our SolarWinds Head Geek™, Patrick Hubbard on January 24th - GMT (UTC+0): 10:00 a.m. to 11:00 a.m. There's still time to RSVP.

Home > Success Center > IP Address Manager (IPAM) > Inaccurate IP results from replicating DHCP servers

Inaccurate IP results from replicating DHCP servers

Created by Matthew Lamb, last modified by MindTouch on Jun 23, 2016

Views: 914 Votes: 0 Revisions: 3



This article describes the issue that occurs if you add in 2 DHCP servers where one is a primary and the other is a replica using Windows 2012.


  • Scanning issues: IPAM version 2+
  • Conflict data: IPAM version 4.2+


IPAM does not support the scanning of replicating DHCP servers. It does not recognize that the DHCP servers are linked, nor that the scopes are replicating across - only that the 2nd server is its own entity and the scopes from it are duplicated scopes. Because of this, the DHCP scans do not sync or even run concurrently, leaving the DHCP information on one server can and will have the potential to mismatch the information on the other.


The mismatch of the scans and the scans themselves into non-duplicated subnets can cause issues ranging from SQL deadlocks on updating subnet and IP information as well as DHCP IP conflicts between the results of 1 DHCP server to the other. The former can cause subnet results to not be updated correctly and the latter can cause the IPAM_ConflictData table to grow exceedingly large with false positive information.


The other cause is that DHCP in Windows 2012 has some replicating issues as well as documented here:


  1. Remove the replicating DHCP server from IPAM as well as its scopes.
  2. Truncate the IPAM_ConflictData table if it becomes too large.


Last modified