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.