Submit a ticketCall us

WebinarUpcoming Webinar: How Help Desk and Remote Support Pays for Itself

Learn how help desk software can simplify ticketing management, allow you to track hardware and software assets, and accelerate the speed of IT support and service delivery. Gain insights on how remote support tools allow your IT team to maximize their efficiency and ticket resolution by expediting desktop troubleshooting, ultimately helping keep end-users happy and productive.

Register here.

Home > Success Center > IP Address Manager (IPAM) > IPAM - Knowledgebase Articles > 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: 999 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