1
00:00:01,440 --> 00:00:06,370
Cluster‑Aware Updating, or CAU for short. It's not going to be too

2
00:00:06,370 --> 00:00:09,540
long in your life as a Windows Server failover cluster

3
00:00:09,540 --> 00:00:12,130
administrator that you're going to have questions like, wait a

4
00:00:12,130 --> 00:00:14,220
minute, what about Microsoft updates?

5
00:00:14,220 --> 00:00:18,230
How can we apply and patch our cluster nodes without

6
00:00:18,230 --> 00:00:21,040
interrupting the failover cluster? Well,

7
00:00:21,040 --> 00:00:25,180
cluster‑aware updating, or CAU, Microsoft already thought of this, it's a

8
00:00:25,180 --> 00:00:29,300
technology that's part of the failover clustering feature that maintains

9
00:00:29,300 --> 00:00:33,540
cluster high availability during the Microsoft Update patching cycle. The

10
00:00:33,540 --> 00:00:37,600
plug‑in model is actually extensible, so you can go beyond there if you

11
00:00:37,600 --> 00:00:38,760
want to or you need to.

12
00:00:38,760 --> 00:00:41,960
So, the question of uh‑oh, would I not be able to

13
00:00:41,960 --> 00:00:45,330
use my own patching solution? No, that's not necessarily true.

14
00:00:45,330 --> 00:00:46,290
You may very well,

15
00:00:46,290 --> 00:00:50,160
especially, of course, if you're using WSUS. You can integrate that

16
00:00:50,160 --> 00:00:54,040
patch management strategy with your failover clusters.

17
00:00:54,040 --> 00:00:58,400
Now there's two ways to do updating runs on your cluster using CAU.

18
00:00:58,400 --> 00:01:01,990
One would be, of course, manually triggering an update, and then

19
00:01:01,990 --> 00:01:05,940
there's configuring self‑updating via schedule.

20
00:01:05,940 --> 00:01:09,000
Let's have a look at the cluster‑aware updating update

21
00:01:09,000 --> 00:01:13,470
workflow. What happens when CAU runs is it's going to pick

22
00:01:13,470 --> 00:01:15,070
a node, hopefully it makes sense.

23
00:01:15,070 --> 00:01:17,800
You have to start somewhere. That node will go into

24
00:01:17,800 --> 00:01:20,900
maintenance mode. It will become paused, and of course,

25
00:01:20,900 --> 00:01:23,040
that's basically a failover event.

26
00:01:23,040 --> 00:01:28,340
So CAU will move any clustered roles for which that first node is active

27
00:01:28,340 --> 00:01:32,900
to another node. And we'll learn formally in this lesson a little bit

28
00:01:32,900 --> 00:01:37,220
later about the concept of the preferred owner. So you can make sure

29
00:01:37,220 --> 00:01:40,940
that if you have a designated second host that you want to nominate for

30
00:01:40,940 --> 00:01:41,970
those clustered roles,

31
00:01:41,970 --> 00:01:45,850
you can do that. Course three is installing the updates from

32
00:01:45,850 --> 00:01:50,600
Microsoft Update or WCUS. Restart is almost a given most of the

33
00:01:50,600 --> 00:01:53,240
time, unless it's a very slight update.

34
00:01:53,240 --> 00:01:57,460
The CAU process can handle automatically restarting and resuming the

35
00:01:57,460 --> 00:02:01,110
update process. Once the updates are complete,

36
00:02:01,110 --> 00:02:03,380
CAU will then unpause the node,

37
00:02:03,380 --> 00:02:07,600
restore clustered roles back to that node, and then move on to

38
00:02:07,600 --> 00:02:10,470
the next one until the process is finished.

39
00:02:10,470 --> 00:02:12,140
This is some nice engineering.

40
00:02:12,140 --> 00:02:17,860
It's basically a self‑contained, self‑operating rolling patch management

41
00:02:17,860 --> 00:02:21,740
solution for your Windows Server failover clusters.

42
00:02:21,740 --> 00:02:24,960
Cluster‑aware updating is actually a separate product

43
00:02:24,960 --> 00:02:27,140
from failover clustering specifically.

44
00:02:27,140 --> 00:02:30,230
And what I mean by that is you can see on this slide and you'll see in

45
00:02:30,230 --> 00:02:34,940
the demo, there's a separate user interface for cluster‑aware updating

46
00:02:34,940 --> 00:02:37,720
where you can connect to your clusters.

47
00:02:37,720 --> 00:02:38,940
If you have more than one,

48
00:02:38,940 --> 00:02:43,950
you can do some basic reporting. You can look at what updates are needed

49
00:02:43,950 --> 00:02:47,340
for your cluster and so on and so forth, so you really can manage the

50
00:02:47,340 --> 00:02:51,140
entire service graphically here if you want to.

51
00:02:51,140 --> 00:02:51,590
However,

52
00:02:51,590 --> 00:02:55,800
in 21st century IT and with DevOps, I would suggest that you

53
00:02:55,800 --> 00:02:59,340
automate and use programmatic methods. And here, we see a

54
00:02:59,340 --> 00:03:01,340
screenshot of a PowerShell console.

55
00:03:01,340 --> 00:03:04,200
We see that there's a separate PowerShell module called

56
00:03:04,200 --> 00:03:08,340
ClusterAwareUpdating. It contains 20 or so cmdlets.

57
00:03:08,340 --> 00:03:13,260
Here's an example of using Invoke‑CauRun to set up a

58
00:03:13,260 --> 00:03:16,340
scheduled self‑updating run for the cluster.

59
00:03:16,340 --> 00:03:19,200
So here we're doing ‑ClusterName. That makes sense.

60
00:03:19,200 --> 00:03:22,640
That's the client access point for the cluster itself.

61
00:03:22,640 --> 00:03:26,350
We specify which plugin we want to use. And then there's some additional

62
00:03:26,350 --> 00:03:29,620
logic in terms of parameters how you want that to work.

63
00:03:29,620 --> 00:03:30,320
And again,

64
00:03:30,320 --> 00:03:34,610
it's essentially an equivalent process, whether you're configuring

65
00:03:34,610 --> 00:03:41,000
self‑updating programmatically with Windows PowerShell versus using the GUI. It's largely a preference.