Next, we have DHCP high availability.
Historically, in Windows Server, we've had two options for putting
redundancy in place to ensure that if our DHCP server is offline,
we don't have a denial of service.
It's a terrible situation because, you know,
you have your client devices that are leased, and you can adjust the
lease durations. And there is a pattern that's built into Windows
Server DHCP in terms of the lease. Once it reaches 50%, then the
client will request an update.
So, hopefully it's a rare occurrence where this would be a big problem.
But at the same time, you want to avoid always the single point of
failure, having a single server and relying on a single machine for
a service so universal and important.
So, one common pattern would be to use Windows Server failover
clustering and to have the DHCP server role in that cluster such
that if the primary for the DHCP server were to be unavailable
either in a planned or unplanned way, we could switch over to another node.
So that's still a good solution for DHCP if you have the
shared storage and the infrastructure to do it.
Another way for businesses that may not have the resources to
do failover clustering is to do split scopes. And this, in my
opinion, is much less optimal.
It's where you decide on a percentage. Let's say you've got a /24 scope,
which would be, what? 254 addresses. You might have your what you hope is your
primary server serving 70% of those IP addresses, and then you'd stand up
another authorized DHCP server elsewhere in your environment, and it would
distribute addresses from the same range.
It's just that it would be non overlapping.
This really dramatically ramps up your management overhead.
But at least it does have the benefit that if one of the two
servers were to go offline,
you would have a server still delivering the goods as it were.
So those were the historical options. They're both still available today.
However, we now have DHCP failover.
This wasn't invented in Windows Server 2022,
but it still exists as a feature in Windows Server 2022.
And basically, what you've got here is a failover
relationship between two servers.
You can only do this between two DHCP servers where your primary DHCP server
replicates IPv4 scope data to its configured partner server.
Now, the wording here is very intentional.
There is a one‑to‑one primary to secondary replication
that doesn't overwrite on the secondary server, and I'll
mention that again in a moment.
Also, notice I'm mentioning IPv4. DHCP failover doesn't work.
It's not available for IPv6, so this is going to provide high
availability only for Internet Protocol version 4 scopes.
Now those two servers in the replication relationship
need to have persistent connectivity,
particularly on TCP port 647. There are two modes of operation here for DHCP
failover, depending upon your use case. There's hot standby in which the backup
DHCP server is silent unless it's called into action.
That is to say unless it detects a communication failure with the primary,
then it will spring into action after an administrator configured interval.
The second option is load balancing where you want both
servers actively distributing leases.
This in my experience can be a bit problematic due to what I see.
And this is the world, according to Tim here,
please understand. What I see is inconsistent synchronization. I've seen
problems or maybe, frankly, it's by design, I can't imagine why it would be,
where, for example, the leases on your primary partner synchronize to the
secondary automatically, but any options that you adjust or make. So that
brings up the fact that the actual replication is supposed to be automatic,
but winds up in practice being at least partly manual. And it's bidirectional
in terms of you can initiate replication from either partner, but you need to
be careful because the source server's settings and configurations will be
authoritative, and they will overwrite what's on the partner.
Now what I've seen in the wild is administrators create PowerShell scripts to
do periodic synchronization, especially of those settings and reservations, to
make sure that both DHCP servers are current.
Now I haven't explicitly mentioned authorization, but recall
that in Active Directory domain services,
your DHCP servers need to be authorized before they'll
actually start distributing traffic.
This is to directly mitigate the issue of an unauthorized DHCP server in your environment.