Which device should I use as DHCP server?

My condolences to you for having to deal with static IP addresses in a network that large. When students asked me "How big would a network have to be before you started using DHCP?" my answer was always "One client computer or more."

I love DHCP. It makes my life easier and makes for better documentation quality. I consider it a necessary infrastructure-level service on par with DNS.

Don't bother running DHCP from an embedded device. Typically you don't have "reservation" functionality (the ability to specify the MAC address of a device and an IP address that it should always receive) and the management interface will be poor.

If you're a more experienced Windows administrator, go with the Windows DHCP server. Someone posted here and mentioned that it is "cleaner" to use Windows DHCP if you have Active Directory. I have no idea what they mean, because the interaction with the Windows DHCP server and Active Directory is minimal. (Perhaps they're referring to dynamic DNS backed by Active Directory. There are some settings in the Windows DHCP server to control how clients interact with DDNS...)

If you're a more experienced *nix admin, run the ISC DHCP server on one of your *nix boxes, or spin up a new box specifically for DHCP.

One of the other posters talked about running "small DHCP servers". I don't know what they're talking about. With only 150 clients you're probably assigning everyone addresses from a single subnet and running multiple DHCP servers in a single subnet isn't typically a "winning" proposition. If you're concerned about availability make sure you have the DHCP server's configuration backed-up and have a procedure to bring up DHCP on another server using that config that you've tested. My strategy on Windows is to use the automatic DHCP configuration backup that the DHCP service generates as the basis for recovery to another Windows machine. I make sure that those files are covered by my backup and I know how to restore them to another machine in the event of failure (http://technet.microsoft.com/en-us/library/cc736344(WS.10).aspx). For an ISC DHCP server on *nix, I'd make sure that my dhcpd.conf is backed-up.

Whatever you use for a DHCP server, strongly consider using the "reservation" functionality to use the DHCP server configuration as your "authoritative" list of IP address assignments. For embedded devices that are capable of pulling DHCP (print servers, switches, APs, etc) I typically configure them for DHCP and create "reserved" IP addresses associated with their MAC addresses. If a device can't pull DHCP, or it doesn't make sense to configure a given device with DHCP (servers, for example), I still create a "reservation" (making a note in whatever comment field is available to indicate that it's actually a static address assignment) such that my DHCP configuration contains ALL my address assignments in a subnet. I've completely given up the old "spreadsheet of IP addresses" in favor of this method because, by definition, using the DHCP configuration as the IP address assignment documentation will cause the documentation to always be the most "up to date".

If you have Windows clients and Active Directory consider setting options to cause client computers to update their DNS record(s). By default a Microsoft DHCP server will instruct Windows 2000 and newer clients to update their "A" record in DNS. The DHCP server itself updates the PTR record. I'm not exactly sure why Microsoft set things up in this manner, but you can (through settings on the client controlled by either Group Policy or by changing them directly on each client) instruct clients to update both records themselves (or to update neither!). However you end up, you really want your DNS to be updated dynamically. You also want your DNS servers to "scavenge" and remove old stale DNS records. I can't say I know how to do that with BIND off the top of my head, but in Windows DNS the procedure is fairly straightforward (see http://technet.microsoft.com/en-us/library/cc757041(WS.10).aspx for details). You want this because you don't want your DNS to fill up with stale client records.

You'll like using DHCP. Treat it as a necessary infrastructure-level service, have a plan to handle failure, and make sure that your DNS infrastructure is ready for it and you'll have a great time. You'll quickly forget how you ever managed to deal with static IP addresses!

If you have AD I would advise running DHCP on one of the Windows boxes; it's just cleaner that way.

That's a pretty good number of workstations, kudos for being brave enough to endure that much with static IPs ;)

• Setup one of your Windows 2003 servers as the DHCP server.
• It would be a good idea to start thinking about Virtual LANs, specially since it sounds like you have the infrastructure for it (Managed switches, router/firewall), plus you'll definitely benefit from the added security if you have a wireless network. Also, you might need this capability to be able to properly separate groups of hosts into their own broadcast domain for security reasons.
  • Make sure you create a different VLAN for your wireless network, both for security and to leave room for future expansion (Don't know how many clients usually connect to your access points, but if you need to expand later and have more broad capability, you won't have to re-number - sometimes this is a hustle, depending on your configuration).
• I suggest using the less common 10.x.x.x network as 192.168.x.x is commonly used by consumer products (switches/wireless). It will save you a headache when one of your staff with laptops sets up a DHCP server on them with their 192.168 network.

Personally I'd recommend running it on a Linux/Unix server of some sort. If you go that route it really doesn't need to be a powerful machine (a desktop PC would have more than enough grunt), just one that's reliable enough not to fall over in a heap. If you do have to use old hardware, have another machine with DHCP turned off but ready to go as a cold spare and run an rsync script or something like that to keep the config accurate on the spare. If you have a virtualisation environment a Linux VM would do the job perfectly.

The architecture we've chosen is to have all our desktop machines on DHCP, but have DHCP issue them all the same address every time. This means addresses are effectively static, but we can re-organise the network as needed without having to visit the clients. This comes in handy for all sorts of things like changing name servers, changing WINS servers, changing the netBIOS settings of machines (broadcast v WINS etc.), or even moving entire departments to a new subnet. Over the years we've had to do all these things, and having DHCP has made them all so much easier. We have about 4K hosts, so to manage it we use a MySQL database to store the details of all our hosts, and run a simple script to generate the DHCP config from that database. From a physical point of view we have two servers, one on each of our two data centres, both generate their config from the same MySQL DB, but one is set to be authoritative, the other is not. That way, when both are up the primary is in charge, but if it goes down for some reason we have a hot backup which can then take over.

Bear in mind I come from a world without Active Directory - we run our entire Windows domain from Linux servers using SAMBA + OpenLDAP. Perhaps active directory would complicate things, but TBH, I can't see why it would - DHCP should just be DHCP.

If you mostly manage a Windows platform and/or know your Windows better than the alternatives, go for the Windows DHCP server.

It's just easier and more integrated into other Microsoft products like if you want to run Deployment Services it will automatically create the DHCP options for you during installation. Lots of little things like that and say easier integration with network security features in Windows Server makes the day much easier :)

Needless to say, if you feel more comfortable managing another platform, go for it.

DHCP is just there to give out network addresses. It is a minimal function. It all depends on whether you still want to have your IP addresses split by departments. You can have IP assignment done by MAC address but this will require a lot of manual labour.

It may be better to use multiple small DHCP servers - one for each department. You can use your 3X managed switches. One to handle each department or something. You just need to learn how to set them up to work together.

Also, it may be better to put your servers as static address assignments simply because you may still want some network services to be running, even if the DHCP servers are not working.

i'd do it on a unix box (preferably debian linux). that way i could maintain just a single list of "MAC address,IP address,hostname" in any format (plain text, mysql, whatever) and generate both DHCP and DNS configuration from that.

which is what i do at work - we have an in-house helpdesk/trouble-ticket system which also incorporates an asset manager. new machines are entered into it as they arrive with all relevant details (incl. mac address and ip address), stored in a mysql database. i wrote some perl scripts to extract that data and generate DHCP and DNS configs.

that makes our helpdesk/asset-mgmt database the single authoritative source of data about which IP addresses belong to which machines (and if you've ever worked on networks with multiple conflicting sources of such info, you'll understand just how important it is to have a single authoritative source)