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.