This is probably not the best way to solve this problem but it worked. Here's what I did.
1) I added the following restriction to my Debian-based DHCP server and removed all of the fixed-address entries. This forces any clients in those IP ranges to move somewhere into the .41 - .199 range, otherwise when I turn on the Windows Server clients will receive leases with IPs in the .11 - .40 range that are already present on the network. I then let things sit long enough for any leases in that IP range to expire and have a new one issued.
subnet 192.168.61.0 netmask 255.255.255.0 {
option routers 192.168.61.1;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.61.255;
pool {
range 192.168.61.0 192.168.61.40;
deny all clients;
}
pool {
range 192.168.61.41 192.168.61.199;
}
}
I could not figure out a way to make the Windows Server DHCP implementation act as "authoritative"; the behavior I wanted is when clients with leases from the old Debian-based DHCP server sent their DHCPINFORM packets to the new Windows Server, I wanted those clients to receive a DHCPNAK and the go through the whole process again to get a lease, thus "re-populating" the addressing space from .11 and up.... regardless, continuing on.
2) I cheated by expanding the Exclusion range on the new Windows DHCP server to include 192.168.61.100 - 192.168.61.199. This will force any clients who were assigned an IP in that range by the Debian-based DHCP serve to have their DHCPINFORM denied and then issued a new lease at the "bottom" of the addressing space (.11 and greater).
3) At this point I simply turned the Debian DHCP server off, and the Windows Server on and let the expiry time sort things out. Because of the "deny all clients" line in my dhcpd.conf, there were no clients with "old leases" in the .11 - .40 addressing space that could cause an IP conflict, and because of the Exclusion of .100 - .199 ranges all DHCPINFORM requests were denied (at least I imagine that's what happened... I didn't bother looking at the transaction using a packet sniffer... I probably should of) and the addressing space was re-populated starting from the lower bound of .11.
"My best guess at the moment is a rogue wifi router in one of our dorm rooms on the 10.1.1.0/24 subnet with a bad gateway."
This happened in my office. The offending device turned out to be a rogue android device:
http://code.google.com/p/android/issues/detail?id=11236
If the android device gets the gateway's IP from another network via DHCP, it may join your network and start responding to ARP requests for the gateway IP with it's MAC. Your use of the common 10.1.1.0/24 network increases the probability of this rogue scenario.
I was able to check the ARP cache on an affected workstation on the network. There, I observed an ARP flux problem where the workstation would flip-flop between the correct MAC and a MAC address from some rogue device. When I looked up the suspicious MAC the workstation had for the gateway, it came back with a Samsung prefix. The astute user with the troubled workstation replied that he knew who had a Samsung device on our network. Turned out to be the CEO.
Best Answer
That's a bad idea. They won't try and renew the lease until it is expiring. Deleting the lease will cause other machines to be able to get that IP. What you want is either to run ipconfig /renew via psexec or to script the renew in PowerShell and run it remotely.
Alternatively, if the users reboot they should get the new configuration options.