There isn’t much documentation to be found on the Internet, and I’ll skip over the most likely cause – that someone has plugged a laptop configured with a static IP address into your DHCP-configured network.
Our case has been much more difficult to track down. We have DHCP redundancy achieved by having two DHCP/DNS servers (which are also our two Windows DCs) on our network. The standard way of getting redundant DHCP is to split your subnet in half and allow each server to assign addresses over its exclusive half of the subnet. Naturally you exclude the opposite server’s address range from being issuable.
Windows clients can deal satisfactorily with the subtleties of Windows DHCP, but you need to watch out for things like PXE and similar network boot systems which don’t follow the conventions because Windows isn’t running. I inspected an event log for a system that had recently experienced a large number of conflicts and found that the conflicting address was listed together with the MAC address of the conflicting system, but there was no record of that system in the DHCP server’s current lease pool. However, the same server had the conflicting system listed in its ARP table. The MAC address turned out to be the other DC which, being an Intel server, has a Lan Bios console that runs during the boot process and seeks an IP address from a DHCP server (similar to a PXE client). Evidently that address, which is of no effect once Windows Server is running, is still recorded and causes the conflict error messages to appear even though the address is no longer in use.
I’m hoping this is just a matter of reconfiguring the DHCP servers. I wouldn’t want to have to reserve addresses for every single PC in case we use PXE, let alone this one server.