1
00:00:01,340 --> 00:00:03,940
Next, we have DHCP high availability.

2
00:00:03,940 --> 00:00:08,310
Historically, in Windows Server, we've had two options for putting

3
00:00:08,310 --> 00:00:12,830
redundancy in place to ensure that if our DHCP server is offline,

4
00:00:12,830 --> 00:00:14,460
we don't have a denial of service.

5
00:00:14,460 --> 00:00:16,750
It's a terrible situation because, you know,

6
00:00:16,750 --> 00:00:20,290
you have your client devices that are leased, and you can adjust the

7
00:00:20,290 --> 00:00:24,360
lease durations. And there is a pattern that's built into Windows

8
00:00:24,360 --> 00:00:29,080
Server DHCP in terms of the lease. Once it reaches 50%, then the

9
00:00:29,080 --> 00:00:30,820
client will request an update.

10
00:00:30,820 --> 00:00:34,740
So, hopefully it's a rare occurrence where this would be a big problem.

11
00:00:34,740 --> 00:00:38,110
But at the same time, you want to avoid always the single point of

12
00:00:38,110 --> 00:00:42,230
failure, having a single server and relying on a single machine for

13
00:00:42,230 --> 00:00:44,630
a service so universal and important.

14
00:00:44,630 --> 00:00:48,490
So, one common pattern would be to use Windows Server failover

15
00:00:48,490 --> 00:00:53,850
clustering and to have the DHCP server role in that cluster such

16
00:00:53,850 --> 00:00:58,660
that if the primary for the DHCP server were to be unavailable

17
00:00:58,660 --> 00:01:03,010
either in a planned or unplanned way, we could switch over to another node.

18
00:01:03,010 --> 00:01:06,620
So that's still a good solution for DHCP if you have the

19
00:01:06,620 --> 00:01:09,350
shared storage and the infrastructure to do it.

20
00:01:09,350 --> 00:01:12,910
Another way for businesses that may not have the resources to

21
00:01:12,910 --> 00:01:16,710
do failover clustering is to do split scopes. And this, in my

22
00:01:16,710 --> 00:01:18,820
opinion, is much less optimal.

23
00:01:18,820 --> 00:01:23,380
It's where you decide on a percentage. Let's say you've got a /24 scope,

24
00:01:23,380 --> 00:01:28,050
which would be, what? 254 addresses. You might have your what you hope is your

25
00:01:28,050 --> 00:01:33,650
primary server serving 70% of those IP addresses, and then you'd stand up

26
00:01:33,650 --> 00:01:38,640
another authorized DHCP server elsewhere in your environment, and it would

27
00:01:38,640 --> 00:01:41,560
distribute addresses from the same range.

28
00:01:41,560 --> 00:01:43,570
It's just that it would be non overlapping.

29
00:01:43,570 --> 00:01:47,190
This really dramatically ramps up your management overhead.

30
00:01:47,190 --> 00:01:50,720
But at least it does have the benefit that if one of the two

31
00:01:50,720 --> 00:01:52,410
servers were to go offline,

32
00:01:52,410 --> 00:01:56,360
you would have a server still delivering the goods as it were.

33
00:01:56,360 --> 00:02:00,540
So those were the historical options. They're both still available today.

34
00:02:00,540 --> 00:02:03,430
However, we now have DHCP failover.

35
00:02:03,430 --> 00:02:06,740
This wasn't invented in Windows Server 2022,

36
00:02:06,740 --> 00:02:10,660
but it still exists as a feature in Windows Server 2022.

37
00:02:10,660 --> 00:02:13,830
And basically, what you've got here is a failover

38
00:02:13,830 --> 00:02:15,820
relationship between two servers.

39
00:02:15,820 --> 00:02:21,550
You can only do this between two DHCP servers where your primary DHCP server

40
00:02:21,550 --> 00:02:26,250
replicates IPv4 scope data to its configured partner server.

41
00:02:26,250 --> 00:02:28,610
Now, the wording here is very intentional.

42
00:02:28,610 --> 00:02:33,590
There is a one‑to‑one primary to secondary replication

43
00:02:33,590 --> 00:02:36,620
that doesn't overwrite on the secondary server, and I'll

44
00:02:36,620 --> 00:02:38,340
mention that again in a moment.

45
00:02:38,340 --> 00:02:43,440
Also, notice I'm mentioning IPv4. DHCP failover doesn't work.

46
00:02:43,440 --> 00:02:47,170
It's not available for IPv6, so this is going to provide high

47
00:02:47,170 --> 00:02:51,260
availability only for Internet Protocol version 4 scopes.

48
00:02:51,260 --> 00:02:54,740
Now those two servers in the replication relationship

49
00:02:54,740 --> 00:02:56,850
need to have persistent connectivity,

50
00:02:56,850 --> 00:03:02,860
particularly on TCP port 647. There are two modes of operation here for DHCP

51
00:03:02,860 --> 00:03:07,930
failover, depending upon your use case. There's hot standby in which the backup

52
00:03:07,930 --> 00:03:11,590
DHCP server is silent unless it's called into action.

53
00:03:11,590 --> 00:03:15,950
That is to say unless it detects a communication failure with the primary,

54
00:03:15,950 --> 00:03:19,940
then it will spring into action after an administrator configured interval.

55
00:03:19,940 --> 00:03:22,700
The second option is load balancing where you want both

56
00:03:22,700 --> 00:03:25,440
servers actively distributing leases.

57
00:03:25,440 --> 00:03:29,770
This in my experience can be a bit problematic due to what I see.

58
00:03:29,770 --> 00:03:31,810
And this is the world, according to Tim here,

59
00:03:31,810 --> 00:03:36,100
please understand. What I see is inconsistent synchronization. I've seen

60
00:03:36,100 --> 00:03:40,490
problems or maybe, frankly, it's by design, I can't imagine why it would be,

61
00:03:40,490 --> 00:03:45,170
where, for example, the leases on your primary partner synchronize to the

62
00:03:45,170 --> 00:03:50,610
secondary automatically, but any options that you adjust or make. So that

63
00:03:50,610 --> 00:03:55,360
brings up the fact that the actual replication is supposed to be automatic,

64
00:03:55,360 --> 00:04:00,110
but winds up in practice being at least partly manual. And it's bidirectional

65
00:04:00,110 --> 00:04:04,070
in terms of you can initiate replication from either partner, but you need to

66
00:04:04,070 --> 00:04:09,270
be careful because the source server's settings and configurations will be

67
00:04:09,270 --> 00:04:12,230
authoritative, and they will overwrite what's on the partner.

68
00:04:12,230 --> 00:04:16,760
Now what I've seen in the wild is administrators create PowerShell scripts to

69
00:04:16,760 --> 00:04:21,390
do periodic synchronization, especially of those settings and reservations, to

70
00:04:21,390 --> 00:04:24,270
make sure that both DHCP servers are current.

71
00:04:24,270 --> 00:04:27,670
Now I haven't explicitly mentioned authorization, but recall

72
00:04:27,670 --> 00:04:29,970
that in Active Directory domain services,

73
00:04:29,970 --> 00:04:33,240
your DHCP servers need to be authorized before they'll

74
00:04:33,240 --> 00:04:35,300
actually start distributing traffic.

75
00:04:35,300 --> 00:04:43,000
This is to directly mitigate the issue of an unauthorized DHCP server in your environment.