this demonstration, we're going to work with DHCP,
Dynamic Host Configuration Protocol, in Windows Server.
I'm on a Windows Server 2022 box named localmem1.contosolocal.int.
You can see in the upper right corner in my BG info output.
We're also going to do DHCP failover.
I don't want to forget about that.
I'm going to do a Get‑WindowsFeature dhcp to make sure
that the server role is installed.
Now if it weren't,
we could do an Install‑WindowsFeature and then just do an
IncludeManagementTools and throw on a Restart and we're good to go.
I always like to show PowerShell wherever possible.
Let's also do an ipconfig all,
and we can see that my subnet range that my servers are on is 192.168.1/24.
Our default gateway is 254, our DNS server is 1.
We're going to need that as we build out our DHCP scope.
All right,
so let me minimize my PowerShell console and bring up my admin console.
I've got a custom MMC console with a bunch of
snap‑ins that I'm going to need here, especially DHCP.
I'm going to right‑click the node and Add Server,
and I'm going to bring in localdc1.
Now don't be alarmed the fact that when you look down in the list,
this authorized, it's showing old IP addresses.
I'm not sure why that update hasn't yet come through,
but I did in fact change localdc1's IP address to 192.168.1.1.
It's just for some reason the MMC console continues to list the
old 10.1.10 address I was using the other day.
All right, so I'm going to expand localdc1.
I'm going to set this up as our primary DHCP server and then
we're going to configure localmem as our standby,
hot standby.
So let me expand IPv4.
Recall that DHCP failover doesn't work with IPv6 anyway,
so we're going to stay with IPv4.
And I'm going to right‑click and create a new scope.
I'm going to call the scope by the subnet name, that's how I normally do it.
And then we're going to start this as 192.168.1.100, 192.168.1.199.
So there will be 100 addresses with a standard 24‑bit class C mask.
Now what we could do is add our scope that includes my static addresses,
because my servers are my first few addresses in the block,
so I could have started at 1 and then just added my server IPs as exclusions.
This is a way to account for those.
That's particularly important with IP address management, actually.
But for today, I'll leave that alone.
I'm just de facto excluded those static IPs from the scope definition.
The default lease duration in Windows Server is 8 days,
and there's a metric after 50% of the lease period,
the client will request a renewal, etc, etc,
and that comes into play even more with the lead time on
DHCP failover that we'll see eventually.
I'm not going to configure options here.
I'm going to click Next and Finish.
And we can set up options at the server or scope level
depending upon how global the option is.
For the server option,
why don't we right‑click and we'll add in a reference to our DNS server.
This would be applicable to all scopes it seems to me.
So, I'm going to do by IP address, I'm going to resolve my 192.168.1.1.
Let's click Add and have the console tap out to my network
and see if we can find it, which it did.
So that option is going to pertain to all scopes.
Then for our scope‑specific option,
let's add in our default gateway, and we'll do that via IP address
192.168.1.254. We'll click Add. And you can get more granular yet. If we
right‑click the IPv4 node, we have user classes and vendor classes. Vendor
classes in particular might be useful if you want to deliver TCP/IP
options to devices from a particular vendor or servers or client machines
that match a certain query.
We don't need to get into the weeds here, just know that
those classes are the most granular way to assign a TCP/IP
configuration. And lastly,
this notion of policies, DHCP policies, this is just
essentially I describe it as an overlay that makes it easier to
create those different class definitions,
etc. That's all that is.
All right,
let's see. Reservations, just so you can see how that
works, let's create a static reservation.
And this, again, is a case where Windows Server IPAM can really help.
Let's say we needed to create a reservation for a network printer and
we want it to have 150 as its IP address.
We're going to need a media access control hardware address for the NIC,
the network interface, on that machine, and then we
can support BOOTP, DHCP, or both.
But, of course, the question that you would have as an administrator is
how do I know that 150 is not used? Now I know in the real world you do
ping if you're allowing ping on your LAN.
IPAM can be really helpful as you saw with that find
and allocate an IP address wizard.
Really useful.
So let's click Add and then Close. So now we've got a reservation.
All right, now the scope is coming in as it normally does by
default in an un‑activated state, and that's good.
It's up to us to activate the scope to actually put it into effect.
Now let's switch over to my client machine.
This is a Windows 10 domain workstation, and I just did some work up here.
You can see the workstation was configured for a static
address, so I switched it over to DHCP, ran an ipconfig renew, and had a problem.
Let me do a cls and see if we got a configuration yet. Yeah, looks like we did.
So we were distributed the first address in that range, and
we can see that our DHCP server is 1.
We also picked up our DNS server and gateway if I didn't already say
that. Back to localmem1. Let's get back to work here.
I think we're ready to configure failover, so why don't we go to ‑‑‑well,
actually, there's a couple other things I wanted to drive by.
Sorry about interrupting myself there.
If we right‑click the DHCP node, besides adding multiple servers to the
console, this is a convenient place to manage authorized servers.
So this is where you can authorize unauthorized Windows Server
DHCP servers to make sure that you've got no rogue servers and
only authorized ones in your environment.
We can set up the failover here at the IPv4 node or
we can come to a particular scope.
Actually, I'm going to right‑click the server and go to Configure
Failover, and this will open up a step‑by‑step wizard interface
in which we're asked, first of all,
which scopes do we want to failover. Now I just have the one, and
notice that the check is set to Select all, but you can be specific in
terms of creating your failover relationships.
There's limits to how many failover relationship
servers you can have, and so on.
You can check the Microsoft Docs for that.
Let me click Next.
So if we're starting with localdc, we're going to add localmem1 as our partner.
I'm not going to reuse existing, so we'll click Next. We give
the relationship a name, and it defaults to the server name, so
in my case localdc1, localmem1.
Now we're going to want to be really careful in how we set up our options.
I'm going to set for Mode,
not Load balance where we could do say a 50/50 split, but I'm going
to do a Hot standby because I want everybody in my environment to
use localdc1 unless it's unavailable.
So when we set Hot standby, then the role of the Partner Server is Standby
and you specify a percentage of IP addresses in the scope that you want to
reserve on the primary. So the standby definitely will have some available to
distribute in the event of a failover.
You can do some simple pre‑shared key authentication between your
replication partners using this Enable Message Authentication and putting in
a shared secret. I'm going to disable that. And that brings us to State
Switchover Interval and Maximum Client Lead Time.
Now, if I leave State Switchover Interval unchecked,
then I'm going to have to manually failover the primary server and put it
in a partner down status. A way to automate that is to set your state
switchover interval. And it defaults to 60.
I'm going to put it down to 1 minute to make it easier
in this demo so I don't have to wait.
And what switchover interval does is after this duration, that failed server,
the server that's lost contact, will be marked as down. And then we can layer
in the maximum client lead time, and this is going to be the duration on top of
the state switchover interval where the secondary server waits before it
formally takes over handing out addresses.
Now, you're going to see that when we take localdc1 down,
the localmem will immediately see connection interrupted and it will step in
and start working with DHCP at that point, but it will not be a permanent I'm
taking over the scope assignment, it's more or less temp. And that's another
occasion where maximum client lead time can be useful because that secondary
server will hand out new leases, not with the 8‑day duration that I set for the
scope, but your maximum client lead time because hopefully it's going to be a
transient communication failure and we're going to need to go back or want to
go back to our primary server once the primary server is back online.
So let me click Next, and that's all we need to do here.
So let's click Finish, and it looks like all of our options here are successful.
And so from now on, any leases are going to be
propagated to the secondary server, even new ones.
So if I expand, we can see our Scope shows up, and if we
expand our Scope, we see Address Leases.
So I can tell you that those will be replicated.
If I brought up a client2 machine,
it would pick up its lease from server 1, dc1, and almost immediately, I
mean I have gigabit connectivity between these servers, there may be some
latency if you're in a multisite environment with slower links. You'll see
that Reservations have come over,
Scope Options have come over, but you will find that if
I add a new scope option over here, which I'll do right now,
I'll add a time server address of 192.168.1.1, and then come over here,
that does not get updated automatically, unfortunately.
So with DHCP server,
although your leases, and I believe also your reservations will cascade
and be synchronized, any other meta that you add,
you're going to have to manually replicate. And you want to be careful
with this because when you replicate your scope,
it's immediately going to do an overwrite.
So it's going to see here that most of this is identical,
but we did change an option value, so that's gotten
replicated over to the failover partner.
So it's one way. We could also do it from localmem1‑to‑dc1.
It's not a synchronization, it's an overwrite.
So again, you want to be real careful about that.
So we've got our new time server on the primary, now let's go
to scope options on the secondary. You right‑click and
Refresh, and there's our time server.
Okay. So to finish out,
let's simulate a failover. I'm going to start by right‑clicking IPv4 and
going to Properties, and then we can go to Failover.
I've got my dc1‑to‑mem1, as you can see here, and I want you to see that the
failover status is normal and our partner is local dc1. I'm going to
right‑click my localdc1 and go to All Tasks, Stop, and that's going to
simulate a failure on the primary server. Of course the MMC can't locate the
server anymore, so now if I come down to localmem1 and again come back to
IPv4, Properties, Failover tab,
we see that we're in lost contact with partner status. Now,
how does that impact client connectivity?
Let's go back to our client, and I'm going to do an ipconfig
release, and now I'm going to do an ipconfig renew and see if
we're able to pick up an address.
Yeah, we picked up an address, and if I do an ipconfig all, we can
see that our DHCP server is 2. And notice that we have a 1‑minute
maximum client lead time for that duration. Now I set mine way too
low just for demonstration purposes.
At this point, the maximum client lead time should have expired.
Let's go back and check on localmem.
Let's right‑click, go to Properties, Failover, and it looks like we are
partner down. Now, when you edit the relationship here,
if we didn't have the state switchover interval set, then we
would have to switch the Relationship from Communication
interrupted to Partner down manually.
That's what this grayed out button is.
But the state switchover means that after that duration
completes and your maximum client lead time completes, the
state of the server will go to partner down.
So at this point, my backup server has formally taken control of
the pool. So to bring things back to normal, let's right‑click
our source server and click Start.
And if we right‑click IPv4, go to Failover, still showing
Partner down, but if we come up to the server,
the localdc server, and go to Properties, go to Failover, we're in
Recover wait status. Now while we're waiting for this, pun intended, you
can find appropriate messages in Event Viewer.
So let's look at localmem's Event Viewer, we'll go
into Applications and Services Logs, Microsoft,
Windows, DHCP Server, and we'll take a look at the DHCP Server Events Admin,
and we can see if we follow the track down here that at 9:23 AM, Server has
lost contact with failover partner server. Failover state went from normal
to communication interrupted, still showing that. Then we've got timeout,
warning, and then finally we have Servers transitioned to partner down
because the MCLT of 60 seconds has expired. And then we have some good news
showing up.
Server has established contact with partner server.
However,
we've got an error. It looks like I've got some reverse lookup zone errors.
I haven't actually configured a reverse lookup zone, so
those are actually to be expected.
So let's come back to localdc1 and look at the properties and
its failover situation. Still in Recover wait. I've seen
that. A good way to kickstart it, so to speak,
is to restart the service on that server.
So let me right‑click and do an All Tasks, Restart.
And then if we look at the properties one more time of IPv4 and go to Failover,
we're back to normal.
So at this point the server is operational,
it's taken over the scope formally, and if there's any residual
differences, that is if the primary was offline for a while and you
don't see those changes come back from localmem, remember that we
can always replicate scope and relationship details one way from the backup to the primary.