We have a hell of a messy DHCP table. I'm on a mission to resolve this, but I was wandering the beltway to approach it without affecting the existing users.

The following background information may also help. I've just added a new 2008 domain controller which has taken on all the FSMO roles. DHCP remains on the 2003 domain controller. Our internal IP range is, which of course causes problems when users remote in when their home IP range is the same. We have less than 200 devices, but I'd like to know more about possibly separating end devices vs. servers, etc.

  • 3
    my head hurtz just thinking about this one, so much wrong not enough time. – tony roth Aug 21 '12 at 14:35
  • 3
    "What should my DHCP configuration be" is really not a good fit for the Stack Exchange format, nor is it remotely answerable with the amount of information provided. But yeah, get rid of the 192.168 address space; this isn't a home network in your basement. Also, servers getting address by DHCP? Ick. – HopelessN00b Aug 21 '12 at 14:44

First, who looks at the DHCP Lease table? Why?

If you want to change your subnet:

  1. Pick the new subnet range. I'd recommend something a bit larger so you can avoid repeating this problem in the future (possibly forever). I'd pick
  2. Change all the statically assigned IP's to the new subnet. So all servers, printers, network devices get a IP (no reason to change their actual IP, just the subnet mask).
  3. Create a new Scope for the DHCP clients. I'd recommend something like to (same /21 subnet mask as before; that's Delete the old scope once you've verified that the new one is working correctly.
  4. ...
  5. Profit!

Note: I picked the /21 subnet size because it can accommodate about 2,000 devices; which is basically more than you'd ever want in a single broadcast domain. You can use a different size if you want, but be sure there's a decent reason backing up that decision.

As opposed to Joel's answer: I'd highly recommend against changing out of the range, as it's going to be a major headache with that many server/clients/devices. It's certainly possible, but I can almost guarantee downtime and/or mistakes; even with a very extended maintenance window to do the changeover. Also, you'll eventually run into other networks that use the same internal range. If you're going to switch out of 192.168.1.x you might as well switch to the least used internal range of 172.16.x.x; even the 10/8 range is quite heavily used.


Migrate dhcp to the new domain controller pronto. Active Directory needs to be the DNS server in it's domains, and one way it keeps it's DNS records updated is by also being the DHCP server, and updating A records when it hands out addresses.

To make the migration with as little pain as possible, try shortening lease times on the old dhcp server to something less than a day and then waiting for a complete cycle of the old duration, so that when you make the migration change everyone will update and grab a new address from the new dhcp server over-night.

Use this as a good chance to update to a less-used range. Something like would be fine. Yes, I know this means changing static IPs, and service entries for your domain controller and just about everything else. It'll be worth it.

You can't really separate devices vs servers. You could make an additional vlan, but ultimately devices need connectivity to the servers, and so gains are minimal. My recommendation here is to have your dhcp server either use reservations for your servers all near the front (or back) of your scope, or have an exclusion so that dhcp is not handing out addresses from a range in the front or back of the scope at all.

At 200 devices, you're to the point where you might want to think about a different subnet mask, to give you a little breathing room in address space. With the explosion in wireless, there's no telling when you'll suddenly need to support a large number of additional devices on your network. Instead of (/24), you can use something like (/23) to give you twice as many available addresses, but still keep everything on the same network.

  • 1
    "and the way it knows to keep it's DNS records updated is by also being the DHCP server" This is plain wrong. If you're having DHCP update the A records (which is bad practice, since it opens you to zone poisoning) you can run DHCP on a non-DC assuming the DHCP server is a member of the DHCPUpdateProxy group. You should have DNS configured to only accept secure updates from known clients if you care about security. The clients will register their own A records (this is the default behavior of a domain-joined PC) and DHCP will still happily hand out addresses without updating DNS. – MDMarra Aug 21 '12 at 14:50
  • Just to be crystal clear, there is no reason that DHCP must ever be run on a DC for any circumstance. In fact, it's not a good idea to do it for a handful of boring security reasons. Having DHCP update your ADI zones is bad but even if you must do that for some odd reason, there's still no requirement that DHCP be run on the DC. It's common to see DHCP on a DC in smaller deployments, but there is absolutely no requirement for this regardless of DNS zone update policy and it should be avoided if at all possible. – MDMarra Aug 21 '12 at 14:55
  • @MDMarra Understand. Somewhere along the way I picked up some bad info. – Joel Coel Aug 21 '12 at 14:57

Not the answer you're looking for? Browse other questions tagged or ask your own question.