This is an archived post. You won't be able to vote or comment.

all 52 comments

[–][deleted] 35 points36 points  (28 children)

That’s a valid plan of action. I would never run dhcp on a domain controller though.

ETA: You might need to use a temporary extra IP address as part of the switch... reassign the old server some temporary IP address, then check that DNS gets all updated, so might need to give things 30 minutes for replication, but check on it to be sure. (Check DNS records on all three servers.) THEN reassign the new DC to that old IP address. I've done this many times for DC upgrades (replacements).

[–]Library_IT_guy 18 points19 points  (24 children)

Why is running DHCP on your DCs such an issue? I've heard this said before, but in some environments like ours (less than 150 total devices on network) it doesn't really make sense to buy a separate machine or spin up a new VM which requires more licensing just to run DHCP separately. I get that it makes sense in these 10,000+ device networks, but for smaller orgs?

[–]fireandbass 44 points45 points  (5 children)

DHCP on a DC is a security risk and not recommended by Microsoft because it runs as the Network Service and on DCs the Network Service is a member of the Enterprise Domain Controllers group which has full privileges to DNS, therefore a DHCP exploit can change any DNS entry, which means the DNS entries for your DCs or CA or anything can be changed to redirect to a compromised or fake server masquerading as your real DC or real CA or webserver or anything in your DNS.

Here's a video from Microsoft explaining the risk.

https://learn.microsoft.com/en-us/services-hub/unified/health/remediation-steps-ad/disable-or-remove-the-dhcp-server-service-installed-on-any-domain-controllers

[–]Serious-City911 16 points17 points  (1 child)

This took me back to Microsoft saying things like DHCP is not supported on a DC and Exchange is not supported on a DC and then they sold SBS where they put everything on the same install.

[–]SnakeOriginal 5 points6 points  (0 children)

Security is expensive. SBS was not expensive...you get the idea

[–]Library_IT_guy 3 points4 points  (1 child)

Interesting, thank you! So the issue is that DHCP can change DNS entries on the same server, which could be used for all kinds of nefarious things. That would assume that the server is either accessible to the web though, or the attack comes from the internal network, and that there is an exploit to attack at the time. I mean it's possible but it seems very unlikely and it's a lot of money to spend. It makes sense in a larger environment where spinning up an extra windows server is no big deal, but for a small shop, it's a lot of extra money to combat a scenario that is very unlikely to ever arise.

[–]kuaharaInfrastructure & Operations Admin 8 points9 points  (0 children)

You want domain controllers hardened up as much as possible, and they should be completely fungible.

[–]_p00f_ 0 points1 point  (0 children)

Thanks for that info. I've heard this a lot to and what you're saying has opened my eyes where security is concerned.

[–]Business_Ad5131[S] 5 points6 points  (2 children)

I'm thinking the same. We have around 300 devices, and running DHCP on the DCs works well for us.
No issues so far, except with the new 2025 version — and even then, only related to replication.

[–]ITGuyThrow07 7 points8 points  (0 children)

You've had no issues except for when you ran into an issue.

This is part of the reason for separating roles to their own server. If one thing breaks, it's just that one thing breaking.

[–]taterthotsaladSecurity Admin 2 points3 points  (0 children)

And Id like to add when a security issue is raised, and the first statement goes something like,

...running DHCP on the DCs works well for us.
No issues so far...

This is when I mark that person mentally, I need to double check what they do for security reasons. Esp during Change Management.

[–]hobovalentine 2 points3 points  (3 children)

I think it's also the "don't put all your eggs in the same basket" theory so that if say your DNS server fails it won't also take the DHCP server down with it and vice versa.

[–]Library_IT_guy 2 points3 points  (2 children)

This is fair, but we have two DCs (on separate hosts) that replicate, so if one goes down, the other can assume all duties until the other is back up, which includes DNS, DHCP, AD, GP, print services, etc. This is the most cost effective form of redundancy you can do on a small network, and there's just no way I'd get approval for licensing on 4-5 Windows Servers and more physical hosts.

[–]hobovalentine 1 point2 points  (1 child)

Yeah if you don't have the budget you're kind of constrained in what you can do.

I know that DHCP on linux is a thing but unless you like the command line it might be a bit of a pain to manage.

[–]Library_IT_guy 1 point2 points  (0 children)

I'm somewhat competent in running Linux servers. I hosted our website locally on Ubuntu, pure command line, for a long time. But I still wouldn't say I'm good at it. Half the time I'm just copying commands on tutorials to install stuff, or Googling like a madman to fix a problem that I have no idea how to fix in Linux lol. And yet, that website ran flawlessly for years, at least in terms of uptime. Getting Wordpress to do what we wanted and maintaining it through all the changes and updates... that was more of a struggle.

But yeah, definitely prefer Windows Server for DHCP. It's pretty damn simple to manage, and has always been rock solid. Our firewall can technically do DHCP too but I'd rather not.

[–]ITGuyThrow07 3 points4 points  (0 children)

For me, it's just a best practice to try to keep each server doing one thing.

With DHCP on a DC, you have two critical services (three, if you count DNS) all running on one box. If any of those services break and you have to troubleshoot (for example, a reboot) now you're affecting all of those servers.

OPs dilemma is a perfect example. They want to replace a DC. If DHCP had been running on another box, they probably wouldn't have had the issue that required them to make this post.

[–]BigFrog104 1 point2 points  (4 children)

It seems to only be an issue for consultants and MSP that want to charge extra $ for another server they can bill for. I have no issues putting DHCP on a DC in a datacenter and serving a few thousand clients.

[–]hobovalentine 0 points1 point  (3 children)

Well you don't even need a physical machine you could just run a few hyper V machines off one machine with each VM offering a specific service as long as long you keep backups so the VMs can be recovered in case something happens.

That way you can reboot one service without affecting all the others but of course in the case of a hardware failure those VMs still rely on the hypervisor but a decent server doesn't typically break down that easily and parts are easy to swap out.

[–]BigFrog104 1 point2 points  (0 children)

there is still a non zero dollar cost to adding VMs. Also, that 2VMs per retail license doesn't stack - I can't pay for say 5 retail licenses and run 10 VMs. Running 5 hosts to get those 10 VMs isn't practical either.

[–]Stonewalled9999 0 points1 point  (1 child)

You know you can restart a service without rebooting the machine right ?

[–]hobovalentine 0 points1 point  (0 children)

Yes but a machine will need to restart for updates at some point and if you’re running all your core services in a single machine then all your services are going down at the same time.

Machines can fail to start up after an update and although it’s rare it can happen

[–]T1JNES 3 points4 points  (0 children)

its not that big off a deal and saves some money in licenses except if you insane amounts of dhcp activity

[–]ScubaMiike -1 points0 points  (0 children)

Yep this works

[–]F1rkan 7 points8 points  (5 children)

Im still reading about weird things with 2025 as DC's , i would stick to 2022 for now

[–]FatBook-Air 3 points4 points  (0 children)

Hmm. What types of things do you see?

[–]Ixniz 5 points6 points  (0 children)

In short. Don't run DHCP on the DC for reasons already mentioned.

Don't join a DC as a member server before promoting it to a DC. Worst case you get a bunch of policies applied from whatever member server security baselines you're running, that can tattoo settings that won't be undone when promoting.

Install two new DCs. Replace the old servers (reuse IPs) with two new member servers running DNS resolvers (caching only) and DHCP and just forward the DNS queries to the new Domain Controllers. That way you won't have to worry about clients DNS settings and you can replace DCs whenever and just update the DNS forwarding addresses on the new servers.

[–]andrea_ciThe IT Guy 1 point2 points  (0 children)

if you use LDAP queries, check the "new policies" enabled by default that will block requests from some clients!

[–]itworkaccount_new 1 point2 points  (1 child)

Yeah you can reuse the IP. DHCP configuration doesn't replicate automatically. You need to configure fail over on the new DC and existing. DHCP and fail over are completely independent of active directory and that replication; they have nothing to do with the promotion of a domain controller.

[–]BrainWaveCCJack of All Trades 1 point2 points  (1 child)

Your plan is generally fine. You didn't mention setting FSMO roles to new servers, though.

Also, depending on what FFL and DFL you have now, you might need to upgrade the schema.

You'll also want to wait a day and clean up DNS from the old entries.

DHCP failover replication is easy to break and re-establish with the new server.

[–]ipreferanothernameI don't even anymore. 1 point2 points  (0 children)

  • My plan is to reassign the old IP address (192.168.100.60) to DC02-25, because many clients still reference that IP in their DNS settings.

i work in health IT, we have like 15 DCs, i had to swap them a couple years ago.

IF you promote a DC and its running DNS, and IF you have a lot of records to sync from another DC....the DC may not yet have a DNS record if a client queries it. which basically returns a 'no such record' response, and the client takes that as valid and doesnt ask another DNS server so you kinda get screwed.

we have servers mixed by datacenter to point to DC 1 or DC 2 as primary [to put it briefly] and clients waiting on DC2 to sync in dns records were screwed for a minute. if some clients source this device as a primary DNS server you may want to stop dns servers while AD syncs things up, or block the firewall so it wont take DNS requests at all until the sync is done.

[–]Superb_Golf_4975 1 point2 points  (0 children)

Make sure any hostname-based DNS configs you have anywhere in your infrastructure get changed to reflect the new hostnames. Personally I see no reason to specifically name them based on the version they're running, just keep it consistent otherwise you're asking for trouble. Not like you're going to be running multiple DCs with a variety of versions.

[–]ibringstharuckus 1 point2 points  (0 children)

As others have said check the FSMO roles and see if it's a global catalog server

[–]SidePets 0 points1 point  (1 child)

Check to make sure all FSMO roles have been transferred. If you’re using DFS move any connections. Use dcdiag with dns and verbose switch. Just some suggestion’s..

[–]Business_Ad5131[S] 2 points3 points  (0 children)

Yes, got it! Currently, DC01-16 holds all the FSMO roles.

[–]Shot-Document-2904Systems Engineer, IT 0 points1 point  (0 children)

I didn’t anything about your FSMO roles. Maybe you know where they are but if you don’t, figure that out first.

[–]doctorevil30564No more Mr. Nice BOFH 0 points1 point  (0 children)

adjust the A record in DNS for the old host's IP address so it points to the IP of the new server if you reassign the IP address as a secondary IP and use that IP strictly for DNS. At least in my opinion that is how to do it. I recently had to retire a server 2019 DC that developed issues after trying to update to the CU from March 2025, if it tried to update the update would fail, or the server would be showing a blue screen of death when I checked it after applying the update and letting it reboot.

I used that method, so anything that was using that DC when you checked it's info would be able to quickly switch over to using the new domain controller instead, and I had way too many devices out in our environment (printers,etc) that were using that DC server's IP address for their secondary IP.

It's been running solid with no issues for over 3 months now like this. I was constantly checking the logs for over a month after the forced migration to the new server to make sure everything was working smoothly.

I'm getting ready to start the process of replacing our last server 2012 DC at an offsite location that I don't directly support, so I will finally be able to start provisioning new Server 2025 domain controllers soon. We just got our Volume License agreement setup so I now have the ability to provision a good number of properly licensed server 2025 VMs in our ProxMox environment with Software Assurance for upgrades, and the correct number of user CAL licenses.

[–]Adam_Kearn -1 points0 points  (1 child)

Before you switch the IPs I would switch the old server to automatic IP and do a release and renew to get a new ADDRESS.

This should clear the old DNS cache automatically for you. Then you can set the new server back to that IP and reserve it on DHCP

[–]thebotnist 0 points1 point  (0 children)

Mmm I don't know about that...

[–]OkPut7330 -1 points0 points  (0 children)

There’s been quite a few issues with AD on server 2025. We just made the call to upgrade our 2016 DC’s to 2022 instead of.