1 00:00:00,000 --> 00:00:01,520 It's patch night. 2 00:00:01,520 --> 00:00:03,960 Dozens of servers need updates, but the work is scattered 3 00:00:03,960 --> 00:00:05,600 across different tools, different teams, 4 00:00:05,600 --> 00:00:07,240 and different lists that nobody fully owns. 5 00:00:07,240 --> 00:00:09,160 One server misses a security update. 6 00:00:09,160 --> 00:00:11,120 Maybe it's still running an old version. 7 00:00:11,120 --> 00:00:12,240 Maybe the update failed. 8 00:00:12,240 --> 00:00:14,040 Maybe somebody thought another team handled it. 9 00:00:14,040 --> 00:00:15,600 Either way, that one missed machine 10 00:00:15,600 --> 00:00:17,360 can turn a routine maintenance task 11 00:00:17,360 --> 00:00:18,840 into a real security problem. 12 00:00:18,840 --> 00:00:21,400 Welcome to another episode of Microsoft Knowledge Nuggets here 13 00:00:21,400 --> 00:00:22,560 on M365. 14 00:00:22,560 --> 00:00:24,200 FM, I'm Mirko Peters, and today we're 15 00:00:24,200 --> 00:00:26,080 talking about Azure Update Manager. 16 00:00:26,080 --> 00:00:27,120 What exactly is it? 17 00:00:27,120 --> 00:00:29,360 Is it just a button that tells Windows to update? 18 00:00:29,360 --> 00:00:30,560 Or is it something much bigger? 19 00:00:30,560 --> 00:00:31,920 By the end of this episode, you'll 20 00:00:31,920 --> 00:00:34,400 understand how Azure Update Manager helps you see missing 21 00:00:34,400 --> 00:00:36,680 updates, plan patching at the right time, 22 00:00:36,680 --> 00:00:39,600 install them across your servers, and check what actually happened 23 00:00:39,600 --> 00:00:40,360 afterward. 24 00:00:40,360 --> 00:00:43,040 We'll also clear up what changed from the older Azure Automation 25 00:00:43,040 --> 00:00:44,280 Update Management setup. 26 00:00:44,280 --> 00:00:46,240 Patching sounds boring until it goes wrong. 27 00:00:46,240 --> 00:00:47,960 Updates often fix security gaps. 28 00:00:47,960 --> 00:00:51,040 They can fix bugs that cause crashes or strange behavior. 29 00:00:51,040 --> 00:00:53,280 Some updates need a restart, and that restart 30 00:00:53,280 --> 00:00:55,360 has to happen when the people using the servers 31 00:00:55,360 --> 00:00:56,960 won't get caught by surprise. 32 00:00:56,960 --> 00:00:58,920 Then there's the question every IT team 33 00:00:58,920 --> 00:01:01,320 eventually gets asked, did the patching finish? 34 00:01:01,320 --> 00:01:02,720 Not, did we start it? 35 00:01:02,720 --> 00:01:03,320 Did it finish? 36 00:01:03,320 --> 00:01:06,280 Which machines failed and which server still needs attention? 37 00:01:06,280 --> 00:01:08,880 Think of your servers like rooms in a large office building. 38 00:01:08,880 --> 00:01:10,280 Each room has its own equipment. 39 00:01:10,280 --> 00:01:12,480 Some rooms run email, some run a business app, 40 00:01:12,480 --> 00:01:14,200 some hold files or databases. 41 00:01:14,200 --> 00:01:16,680 Updates are the repair work inside those rooms, 42 00:01:16,680 --> 00:01:19,160 and patch night needs one clear maintenance board 43 00:01:19,160 --> 00:01:22,280 that shows what work is waiting, who is responsible when 44 00:01:22,280 --> 00:01:25,720 repairs happen, and whether the work past inspection. 45 00:01:25,720 --> 00:01:28,640 Without that board, people leave notes in different places. 46 00:01:28,640 --> 00:01:30,520 Before Azure Update Manager, Azure Patching 47 00:01:30,520 --> 00:01:32,640 could involve Azure Automation Update Management, 48 00:01:32,640 --> 00:01:35,440 an automation account, and a log analytics workspace. 49 00:01:35,440 --> 00:01:37,240 Those services could do useful work, 50 00:01:37,240 --> 00:01:39,160 but you needed to connect several moving parts 51 00:01:39,160 --> 00:01:41,440 before you could run and report on patching. 52 00:01:41,440 --> 00:01:43,320 Azure Update Manager brings that patching work 53 00:01:43,320 --> 00:01:45,120 into one Azure native service. 54 00:01:45,120 --> 00:01:47,680 So let's start with the first building block, 55 00:01:47,680 --> 00:01:49,520 the machines you need to manage. 56 00:01:49,520 --> 00:01:51,840 One place to see every machine. 57 00:01:51,840 --> 00:01:54,960 Azure Update Manager is a service that checks, schedules, 58 00:01:54,960 --> 00:01:58,280 installs, and tracks operating system updates for your servers. 59 00:01:58,280 --> 00:02:00,120 That's the simple definition. 60 00:02:00,120 --> 00:02:02,000 It isn't there to manage every piece of software 61 00:02:02,000 --> 00:02:03,040 on every computer. 62 00:02:03,040 --> 00:02:05,440 Its job focuses on the operating system updates 63 00:02:05,440 --> 00:02:07,600 that keep Windows and Linux servers current, 64 00:02:07,600 --> 00:02:09,440 and it gives you one place to manage that work. 65 00:02:09,440 --> 00:02:10,760 Why does that matter? 66 00:02:10,760 --> 00:02:12,880 Because patching gets messy when your servers live 67 00:02:12,880 --> 00:02:15,560 in more than one place, you might have Azure Virtual Machines 68 00:02:15,560 --> 00:02:16,640 running an app. 69 00:02:16,640 --> 00:02:19,080 You might have another group of servers in your own server room. 70 00:02:19,080 --> 00:02:21,560 You may even have machines running in another cloud provider. 71 00:02:21,560 --> 00:02:23,560 If each group uses its own patching screen 72 00:02:23,560 --> 00:02:26,400 and its own reporting method, you spend time chasing answers 73 00:02:26,400 --> 00:02:28,320 instead of fixing the machines that need work. 74 00:02:28,320 --> 00:02:30,560 Azure Update Manager can manage Azure Virtual Machines 75 00:02:30,560 --> 00:02:32,040 running Windows or Linux. 76 00:02:32,040 --> 00:02:34,520 It can also work with virtual machine scale sets. 77 00:02:34,520 --> 00:02:36,520 A scale set is a group of similar virtual machines 78 00:02:36,520 --> 00:02:39,040 that Azure can add or remove as demand changes. 79 00:02:39,040 --> 00:02:41,760 So you don't want each machine treated like a separate mystery. 80 00:02:41,760 --> 00:02:43,960 You need a consistent way to see and manage updates 81 00:02:43,960 --> 00:02:44,960 across that group. 82 00:02:44,960 --> 00:02:46,400 But what about servers outside Azure? 83 00:02:46,400 --> 00:02:47,800 That's where Azure Arc comes in. 84 00:02:47,800 --> 00:02:49,680 Azure Arc connects an on-premises server 85 00:02:49,680 --> 00:02:52,360 or a server in another cloud to Azure for management. 86 00:02:52,360 --> 00:02:53,840 Think of it like a remote office, 87 00:02:53,840 --> 00:02:56,560 getting added to the same building directory as the main office. 88 00:02:56,560 --> 00:02:58,960 The remote office still sits in another location. 89 00:02:58,960 --> 00:03:01,120 Its rooms don't move into the main building, 90 00:03:01,120 --> 00:03:03,920 but the front desk can now see the office, recognize it, 91 00:03:03,920 --> 00:03:05,720 and include it in the same maintenance plan. 92 00:03:05,720 --> 00:03:07,840 Once a server connects through Azure Arc, 93 00:03:07,840 --> 00:03:10,680 Azure Update Manager can include it in the same patching view 94 00:03:10,680 --> 00:03:12,520 as your Azure Virtual Machines. 95 00:03:12,520 --> 00:03:14,040 This changes the daily experience. 96 00:03:14,040 --> 00:03:15,880 Instead of opening one tool for Azure, 97 00:03:15,880 --> 00:03:17,400 another tool for your server room, 98 00:03:17,400 --> 00:03:19,240 and perhaps a separate report for another cloud, 99 00:03:19,240 --> 00:03:20,840 you can look at a central dashboard. 100 00:03:20,840 --> 00:03:22,840 You can see machines with missing updates, 101 00:03:22,840 --> 00:03:25,000 their patch status, the history of update runs, 102 00:03:25,000 --> 00:03:27,600 and a view of which machines meet your patch rules 103 00:03:27,600 --> 00:03:28,600 and which ones don't. 104 00:03:28,600 --> 00:03:30,280 That central view doesn't remove the need 105 00:03:30,280 --> 00:03:31,640 for people to own their servers. 106 00:03:31,640 --> 00:03:33,080 It makes ownership clearer. 107 00:03:33,080 --> 00:03:36,280 When a machine appears with a failed update, 108 00:03:36,280 --> 00:03:38,720 you can see it in the same places the rest of the fleet. 109 00:03:38,720 --> 00:03:40,080 The right team can follow up faster 110 00:03:40,080 --> 00:03:41,680 because they aren't first trying to work out 111 00:03:41,680 --> 00:03:43,040 which system holds the answer. 112 00:03:43,040 --> 00:03:45,720 Imagine a company with 20 Azure Virtual Machines 113 00:03:45,720 --> 00:03:48,600 and 10 physical servers in its own server room. 114 00:03:48,600 --> 00:03:50,360 The Azure Machines run a customer website 115 00:03:50,360 --> 00:03:51,840 and some internal services. 116 00:03:51,840 --> 00:03:54,480 The on-premises servers run an older finance application 117 00:03:54,480 --> 00:03:55,600 that the company still needs. 118 00:03:55,600 --> 00:03:57,440 In the past, the cloud team might check 119 00:03:57,440 --> 00:03:59,120 Azure patching in one place 120 00:03:59,120 --> 00:04:00,800 while the local infrastructure team 121 00:04:00,800 --> 00:04:03,120 checks the server room through another tool. 122 00:04:03,120 --> 00:04:06,360 Now, the on-premises servers connect through Azure Arc. 123 00:04:06,360 --> 00:04:08,640 Azure Update Manager can show both sets of machines 124 00:04:08,640 --> 00:04:09,840 in one patch view. 125 00:04:09,840 --> 00:04:11,640 The company can see where updates are missing, 126 00:04:11,640 --> 00:04:12,800 what ran recently, 127 00:04:12,800 --> 00:04:14,800 and which machines need somebody to investigate. 128 00:04:14,800 --> 00:04:16,600 The machines remain in different locations 129 00:04:16,600 --> 00:04:19,000 but the patching picture stops being scattered. 130 00:04:19,000 --> 00:04:21,000 That's a much better starting point than guessing. 131 00:04:21,000 --> 00:04:23,760 Still, seeing a list of machines isn't enough. 132 00:04:23,760 --> 00:04:24,880 Before you install anything, 133 00:04:24,880 --> 00:04:28,360 you need a current checklist of what every machine actually needs. 134 00:04:28,360 --> 00:04:30,640 Assessment finds what needs attention. 135 00:04:30,640 --> 00:04:32,280 Before a technician starts repairs, 136 00:04:32,280 --> 00:04:33,640 they check the problem first. 137 00:04:33,640 --> 00:04:35,360 Server patching works the same way, 138 00:04:35,360 --> 00:04:37,360 but you don't want to send updates to a machine blindly 139 00:04:37,360 --> 00:04:38,920 then hope the right fix is installed 140 00:04:38,920 --> 00:04:40,640 and the wrong changes didn't cause trouble. 141 00:04:40,640 --> 00:04:42,560 First, you need to know what that machine is missing, 142 00:04:42,560 --> 00:04:43,960 what kind of updates those are 143 00:04:43,960 --> 00:04:46,160 and whether the machine has already reported a problem. 144 00:04:46,160 --> 00:04:47,600 That check is called an assessment. 145 00:04:47,600 --> 00:04:49,040 So here's the simple definition. 146 00:04:49,040 --> 00:04:51,040 Azure Update Manager can assess your machines 147 00:04:51,040 --> 00:04:54,160 and build a current picture of pending operating system updates. 148 00:04:54,160 --> 00:04:55,400 For most managed machines, 149 00:04:55,400 --> 00:04:58,080 it runs an automatic assessment every 24 hours. 150 00:04:58,080 --> 00:04:59,440 Why does that daily check matter? 151 00:04:59,440 --> 00:05:00,960 Because the update picture changes, 152 00:05:00,960 --> 00:05:02,640 a server that looked current yesterday 153 00:05:02,640 --> 00:05:04,640 might have new updates available today. 154 00:05:04,640 --> 00:05:06,440 Another machine may have installed some updates 155 00:05:06,440 --> 00:05:09,000 through a planned process and no longer need attention. 156 00:05:09,000 --> 00:05:11,560 Assessment keeps the list moving with the machines, 157 00:05:11,560 --> 00:05:13,160 instead of leaving you with a spreadsheet 158 00:05:13,160 --> 00:05:15,680 that was only accurate when someone last edited it. 159 00:05:15,680 --> 00:05:16,520 For Windows servers, 160 00:05:16,520 --> 00:05:18,600 the assessment looks for operating system updates 161 00:05:18,600 --> 00:05:20,040 that apply to that machine. 162 00:05:20,040 --> 00:05:22,640 For Linux servers, it checks the available package updates 163 00:05:22,640 --> 00:05:24,640 from the machines configured update sources. 164 00:05:24,640 --> 00:05:27,240 The operating systems work differently behind the scenes, 165 00:05:27,240 --> 00:05:29,760 but the question you need answered stays simple. 166 00:05:29,760 --> 00:05:31,960 What updates does this server still need? 167 00:05:31,960 --> 00:05:33,840 Not every update carries the same urgency. 168 00:05:33,840 --> 00:05:36,760 Security updates fix known security issues. 169 00:05:36,760 --> 00:05:38,560 Critical updates address serious problems 170 00:05:38,560 --> 00:05:39,840 that can affect the system. 171 00:05:39,840 --> 00:05:42,200 Think of those as repair tickets marked urgent. 172 00:05:42,200 --> 00:05:43,520 You usually want to spot them quickly 173 00:05:43,520 --> 00:05:45,760 because leaving them open can create risk 174 00:05:45,760 --> 00:05:47,360 but other updates need more thought. 175 00:05:47,360 --> 00:05:49,560 They can bring broader changes like new features 176 00:05:49,560 --> 00:05:52,320 or changes to a component your application depends on. 177 00:05:52,320 --> 00:05:53,720 That doesn't mean you should ignore them. 178 00:05:53,720 --> 00:05:56,280 It means your team should separate urgent security work 179 00:05:56,280 --> 00:05:59,160 from updates that need a longer test cycle. 180 00:05:59,160 --> 00:06:02,120 Now, Azure Update Manager gives you a compliance view 181 00:06:02,120 --> 00:06:03,840 for this you can look across your machines 182 00:06:03,840 --> 00:06:06,880 and find the servers missing security or critical updates. 183 00:06:06,880 --> 00:06:09,080 You can also see the result of past update work, 184 00:06:09,080 --> 00:06:11,120 including successful runs and failures. 185 00:06:11,120 --> 00:06:13,120 Instead of asking every server owner for an answer, 186 00:06:13,120 --> 00:06:15,320 you have a shared place to begin the conversation. 187 00:06:15,320 --> 00:06:17,640 But don't treat a dashboard number like a final verdict. 188 00:06:17,640 --> 00:06:19,560 The information is close to real time, 189 00:06:19,560 --> 00:06:21,040 yet it can take time for the portal 190 00:06:21,040 --> 00:06:23,360 to refresh after an assessment or installation. 191 00:06:23,360 --> 00:06:25,840 If you're responding to a serious security issue, 192 00:06:25,840 --> 00:06:27,480 confirm the machine's actual state 193 00:06:27,480 --> 00:06:28,920 before you close the incident. 194 00:06:28,920 --> 00:06:30,160 Check the update result. 195 00:06:30,160 --> 00:06:32,040 Check whether a restart is still waiting, 196 00:06:32,040 --> 00:06:34,040 check that the servers came back as expected. 197 00:06:34,040 --> 00:06:36,120 Imagine you manage 100 servers. 198 00:06:36,120 --> 00:06:39,000 The compliance view shows that 92 have the security updates 199 00:06:39,000 --> 00:06:40,040 you expected. 200 00:06:40,040 --> 00:06:41,680 8 still need attention. 201 00:06:41,680 --> 00:06:43,960 A percentage on the screen might look reassuring 202 00:06:43,960 --> 00:06:46,200 but those 8 machines are where the work begins. 203 00:06:46,200 --> 00:06:49,040 Maybe one failed because it couldn't reach its update source. 204 00:06:49,040 --> 00:06:52,120 Another might need a restart before it reports the final result. 205 00:06:52,120 --> 00:06:55,080 And a third could have an update that doesn't apply after all, 206 00:06:55,080 --> 00:06:57,520 or it may run an application that needs a closer check 207 00:06:57,520 --> 00:06:58,840 before anything changes. 208 00:06:58,840 --> 00:07:01,000 The dashboard helps you find the 8 machines. 209 00:07:01,000 --> 00:07:04,160 It doesn't remove the need to investigate why each one appears there. 210 00:07:04,160 --> 00:07:06,440 That's the difference between reporting and managing. 211 00:07:06,440 --> 00:07:09,440 Assessment tells you what needs work and where to look first. 212 00:07:09,440 --> 00:07:12,920 After that, you need to decide when those machines receive updates, 213 00:07:12,920 --> 00:07:16,480 which updates you allow, and what happens if a restart is required. 214 00:07:16,480 --> 00:07:18,520 Maintenance Windows put you in control. 215 00:07:18,520 --> 00:07:21,160 Knowing which updates are waiting is only half the job. 216 00:07:21,160 --> 00:07:23,320 The next question is when you can safely do the work. 217 00:07:23,320 --> 00:07:26,000 A maintenance window is booked repair time for a server. 218 00:07:26,000 --> 00:07:28,800 It tells Azure Update Manager when updates can install 219 00:07:28,800 --> 00:07:31,520 and when a restart can happen if that restart is part of the job. 220 00:07:31,520 --> 00:07:34,440 That matters because a server doesn't know your business calendar. 221 00:07:34,440 --> 00:07:36,080 If you let updates happen at random, 222 00:07:36,080 --> 00:07:38,360 a restart could interrupt people in the middle of work, 223 00:07:38,360 --> 00:07:40,320 stop an application during a busy period, 224 00:07:40,320 --> 00:07:43,040 or break a process that needs someone nearby to check it. 225 00:07:43,040 --> 00:07:45,840 A maintenance window puts a clear boundary around that risk. 226 00:07:45,840 --> 00:07:47,560 You can create a one time patching job 227 00:07:47,560 --> 00:07:49,680 when an urgent fix needs attention now. 228 00:07:49,680 --> 00:07:53,200 Maybe a security issue affects a small group of internet facing servers. 229 00:07:53,200 --> 00:07:55,000 You don't need to wait for the next monthly cycle. 230 00:07:55,000 --> 00:07:56,880 You choose the machines, choose the updates, 231 00:07:56,880 --> 00:08:00,800 set a window and run the patch job when the service owner is agree it's safe. 232 00:08:00,800 --> 00:08:03,320 For normal operations, you can create recurring schedules. 233 00:08:03,320 --> 00:08:08,240 That might mean a monthly window after Microsoft releases its regular Windows updates. 234 00:08:08,240 --> 00:08:12,280 The schedule repeats, so your team doesn't need to rebuild the same patch plan every month. 235 00:08:12,280 --> 00:08:15,640 You still review it of course, but the basic routine is already there. 236 00:08:15,640 --> 00:08:19,040 Inside that schedule, you choose which kinds of updates are allowed. 237 00:08:19,040 --> 00:08:22,000 Many teams start with security updates and critical updates 238 00:08:22,000 --> 00:08:24,560 because those usually deal with the most immediate risks. 239 00:08:24,560 --> 00:08:28,320 You can also allow other update types when your testing process supports them. 240 00:08:28,320 --> 00:08:30,920 The point isn't to select everything because it's available. 241 00:08:30,920 --> 00:08:33,560 The point is to decide what belongs in each patch cycle. 242 00:08:33,560 --> 00:08:35,400 Reboots need the same kind of decision. 243 00:08:35,400 --> 00:08:37,920 Some updates don't finish until the server restarts. 244 00:08:37,920 --> 00:08:41,200 For lower risk systems, you may allow a restart if it's required. 245 00:08:41,200 --> 00:08:43,720 As long as it happens inside the maintenance window. 246 00:08:43,720 --> 00:08:45,320 But other servers need tighter control. 247 00:08:45,320 --> 00:08:49,120 A database server, a business app or a system with a strict uptime promise 248 00:08:49,120 --> 00:08:51,760 may need its service owner to choose the restart time. 249 00:08:51,760 --> 00:08:55,240 In that case, you avoid an automatic reboot and plan it separately. 250 00:08:55,240 --> 00:08:59,520 The update can install, but the final restart waits for the right people and the right time. 251 00:08:59,520 --> 00:09:04,920 As your update manager also supports automatic VM guest patching for supported Azure Virtual Machines. 252 00:09:04,920 --> 00:09:08,920 In plain English, Azure can download and install updates inside the virtual machine 253 00:09:08,920 --> 00:09:10,320 under the rules you choose. 254 00:09:10,320 --> 00:09:14,520 You set the patching approach and Azure handles the routine work in the guest operating system. 255 00:09:14,520 --> 00:09:19,720 That can reduce manual effort, but it doesn't remove the need to test the application running on that machine. 256 00:09:19,720 --> 00:09:24,320 Then there's hot patching on supported Windows versions and supported Azure Virtual Machines. 257 00:09:24,320 --> 00:09:27,120 Some security updates can install without a reboot. 258 00:09:27,120 --> 00:09:29,720 That's useful when keeping a service online matters. 259 00:09:29,720 --> 00:09:33,120 But hot patching isn't a free pass to forget about maintenance Windows. 260 00:09:33,120 --> 00:09:36,120 It applies only to supported systems and selected updates. 261 00:09:36,120 --> 00:09:38,120 Some changes still need a normal restart. 262 00:09:38,120 --> 00:09:41,120 Treat hot patching as a way to reduce restarts in the right cases, 263 00:09:41,120 --> 00:09:44,120 not as a promise that every server can stay online forever. 264 00:09:44,120 --> 00:09:46,520 A safe patch plan usually moves in stages. 265 00:09:46,520 --> 00:09:48,520 Start with development and test servers. 266 00:09:48,520 --> 00:09:51,920 These are the machines where you learn whether an update affects your application, 267 00:09:51,920 --> 00:09:53,520 scripts or basic server behavior. 268 00:09:53,520 --> 00:09:56,720 After those checks pass, patch a small production pilot group. 269 00:09:56,720 --> 00:09:59,520 Choose machines that represent the wider environment, 270 00:09:59,520 --> 00:10:02,520 but don't put the whole business at risk if something goes wrong. 271 00:10:02,520 --> 00:10:06,320 Watch the application, confirm the servers restart cleanly when needed. 272 00:10:06,320 --> 00:10:08,520 Give the service owners time to spot problems. 273 00:10:08,520 --> 00:10:10,720 Only then do you patch the wider production group. 274 00:10:10,720 --> 00:10:14,520 This is why development, test and production should have separate maintenance Windows. 275 00:10:14,520 --> 00:10:18,320 You don't want one giant patch night where every machine changes at the same time. 276 00:10:18,320 --> 00:10:21,120 Separate Windows give you time to learn from the earlier group 277 00:10:21,120 --> 00:10:23,520 before the next group receives the same updates. 278 00:10:23,520 --> 00:10:25,520 A schedule prevents surprise outages. 279 00:10:25,520 --> 00:10:28,320 But a schedule only tells you what Azure intended to do. 280 00:10:28,320 --> 00:10:30,520 Next, you need proof that the work completed 281 00:10:30,520 --> 00:10:33,320 and you need a clear way to find the machines where it didn't. 282 00:10:33,320 --> 00:10:35,320 Compliance turns patching into evidence. 283 00:10:35,320 --> 00:10:36,920 So a patch schedule finishes on time, 284 00:10:36,920 --> 00:10:39,520 but that doesn't always mean every server is safe. 285 00:10:39,520 --> 00:10:41,120 One machine might fail halfway through, 286 00:10:41,120 --> 00:10:42,520 another waits for a reboot, 287 00:10:42,520 --> 00:10:44,920 and a third never even reaches the update source. 288 00:10:44,920 --> 00:10:47,720 If you only look at that green success message for the overall schedule 289 00:10:47,720 --> 00:10:50,720 that one failed server stays exposed long after patch night ends. 290 00:10:50,720 --> 00:10:53,220 Here's why update manager keeps update history. 291 00:10:53,220 --> 00:10:57,120 For each update run, you can review exactly what happened to the machines in scope. 292 00:10:57,120 --> 00:10:58,920 You'll see an installation that completed, 293 00:10:58,920 --> 00:11:01,720 one that failed, or a machine waiting for a restart, 294 00:11:01,720 --> 00:11:03,720 meaning the work isn't fully done yet. 295 00:11:03,720 --> 00:11:06,120 A failed result doesn't always mean the same thing. 296 00:11:06,120 --> 00:11:08,120 The server could have a disk space problem. 297 00:11:08,120 --> 00:11:09,920 Its update servers might not be working. 298 00:11:09,920 --> 00:11:12,120 A Linux server can't reach its package source 299 00:11:12,120 --> 00:11:14,920 or an update conflicts with something already installed. 300 00:11:14,920 --> 00:11:16,920 The history gives your team a starting point. 301 00:11:16,920 --> 00:11:19,320 Instead of telling an auditor or a service owner, 302 00:11:19,320 --> 00:11:20,620 we ran the patch job. 303 00:11:20,620 --> 00:11:22,520 You can answer the more useful question, 304 00:11:22,520 --> 00:11:24,720 which servers still miss security updates, 305 00:11:24,720 --> 00:11:26,520 and what are we doing about them? 306 00:11:26,520 --> 00:11:28,720 That turns patching into real evidence. 307 00:11:28,720 --> 00:11:30,520 Here's how you use the compliance view. 308 00:11:30,520 --> 00:11:33,320 Narrow the list to machines with missing security updates. 309 00:11:33,320 --> 00:11:36,120 Check the last assessment and the last installation result, 310 00:11:36,120 --> 00:11:40,120 then assign the follow-up work to the people who own that server or application. 311 00:11:40,120 --> 00:11:42,320 Behind the scenes, as your update manager uses 312 00:11:42,320 --> 00:11:44,720 as your resource graph for this compliance information. 313 00:11:44,720 --> 00:11:46,820 That name sounds technical, but the idea is simple. 314 00:11:46,820 --> 00:11:50,520 As your resource graph is a way for as you're to search across the resources you manage 315 00:11:50,520 --> 00:11:52,320 and return information about them. 316 00:11:52,320 --> 00:11:56,520 Update manager uses it to build a central view of update status and compliance. 317 00:11:56,520 --> 00:12:00,520 You don't need to create a log analytics workspace just to use the core update manager service. 318 00:12:00,520 --> 00:12:04,720 That's different from the older patching setup where log analytics was a required piece. 319 00:12:04,720 --> 00:12:07,920 You can still use Azure Monitor and log analytics if you want alerts, 320 00:12:07,920 --> 00:12:10,120 longer term records, or deeper investigation. 321 00:12:10,120 --> 00:12:13,920 There are useful tools when your team needs to connect patch failures with other events, 322 00:12:13,920 --> 00:12:16,920 but they are optional for the basic patching flow. 323 00:12:16,920 --> 00:12:18,320 Now let's talk about governance. 324 00:12:18,320 --> 00:12:22,720 Azure Policy lets an organization set rules for how Azure resources should be managed. 325 00:12:22,720 --> 00:12:27,120 For patching, that means checking whether machines have the expected update settings, 326 00:12:27,120 --> 00:12:30,720 it turns a team preference into a rule that can be checked across many resources. 327 00:12:30,720 --> 00:12:34,520 Our back, role-based access control, answers a different question, 328 00:12:34,520 --> 00:12:35,720 who is allowed to do what? 329 00:12:35,720 --> 00:12:39,120 One person may be allowed to view compliance, another may run an assessment. 330 00:12:39,120 --> 00:12:43,320 A smaller group may have permission to create or change production patch schedules. 331 00:12:43,320 --> 00:12:47,720 That separation matters because patching can restart servers and affect real services. 332 00:12:47,720 --> 00:12:51,920 Imagine a schedule deployment runs overnight and one production server reports a failure. 333 00:12:51,920 --> 00:12:54,720 An Azure Monitor alert sends the team a message. 334 00:12:54,720 --> 00:12:58,720 In Update Manager, they check the history and find the server couldn't complete the installation. 335 00:12:58,720 --> 00:13:03,120 They connect to the server, find the blocker, fix it, and run the update again during an approved window. 336 00:13:03,120 --> 00:13:05,920 The schedule ran, the evidence showed the work wasn't finished. 337 00:13:05,920 --> 00:13:10,320 This is where Azure Update Manager differs most from the older patch management setup. 338 00:13:10,320 --> 00:13:14,720 It moves patching, reporting, and control closer together inside, what replaced the old setup. 339 00:13:14,720 --> 00:13:18,520 So why does Azure Update Manager feel different from the older Azure patching setup? 340 00:13:18,520 --> 00:13:23,520 Azure Automation Update Management tied patching work to an automation account and a log analytics workspace. 341 00:13:23,520 --> 00:13:29,120 Before your team could manage updates and see results, those extra services needed to exist and connect correctly. 342 00:13:29,120 --> 00:13:34,720 They could work well, but they added setup, ownership questions, and more places where access or reporting could become confusing. 343 00:13:34,720 --> 00:13:38,320 The newer model puts Update Management inside Azure as a native service. 344 00:13:38,320 --> 00:13:43,520 It uses Azure Resource Manager, the standard way Azure handles resources, permissions, and changes. 345 00:13:43,520 --> 00:13:46,920 That also means access can sit closer to the machine itself. 346 00:13:46,920 --> 00:13:52,920 A team can receive permission for a specific virtual machine, a resource group, or a wider Azure area depending on what they own. 347 00:13:52,920 --> 00:13:58,520 You don't need to hand someone broad access to a shared automation account just because they need to manage a small set of servers. 348 00:13:58,520 --> 00:13:59,920 Think about the difference like this. 349 00:13:59,920 --> 00:14:03,720 The older setup asked you to visit extra rooms before the repair work could begin. 350 00:14:03,720 --> 00:14:07,520 You needed the control room, the records room, and the repair desk to work together. 351 00:14:07,520 --> 00:14:11,320 With Azure Update Manager, the repair desk sits where you manage the server. 352 00:14:11,320 --> 00:14:13,320 You still need people, process, and care. 353 00:14:13,320 --> 00:14:16,120 But there are fewer places to set up before the work can start. 354 00:14:16,120 --> 00:14:18,720 That doesn't change the parts that always need human judgment. 355 00:14:18,720 --> 00:14:20,720 Windows and Linux updates still need testing. 356 00:14:20,720 --> 00:14:24,520 Applications still need owners who can tell you whether they work after a change. 357 00:14:24,520 --> 00:14:31,320 Maintenance Windows still need to match the real needs of the business and reboot plans still need agreement before anyone touches a production service. 358 00:14:31,320 --> 00:14:33,520 The service improves the patching process. 359 00:14:33,520 --> 00:14:36,320 It doesn't remove responsibility from the people running it. 360 00:14:36,320 --> 00:14:38,320 What improves is the path into the service. 361 00:14:38,320 --> 00:14:44,320 Azure VMs can use Update Manager without setting up the old automation and log analytics foundation first. 362 00:14:44,320 --> 00:14:50,120 Azure Arc also lets you bring connected servers from your own server room or another cloud into the same management approach. 363 00:14:50,120 --> 00:14:53,320 You can run a plan schedule when the routine calls for it. 364 00:14:53,320 --> 00:14:56,920 Or start an update job when an urgent issue needs a faster response. 365 00:14:56,920 --> 00:14:58,920 Cost depends on where the server runs. 366 00:14:58,920 --> 00:15:02,320 Azure VMs don't carry a direct Azure Update Manager charge. 367 00:15:02,320 --> 00:15:05,720 Arc enabled servers can cost about $5 per server each month, 368 00:15:05,720 --> 00:15:09,120 although some cases like certain bundled services can change that cost. 369 00:15:09,120 --> 00:15:12,520 Always check the current as you are pricing for your own setup before you commit. 370 00:15:12,520 --> 00:15:15,920 And remember, a new tool isn't an automatic safety switch. 371 00:15:15,920 --> 00:15:16,920 Move in stages. 372 00:15:16,920 --> 00:15:25,120 Start with a small group, compare the results with your existing process and confirm that permissions, schedules, update sources and reporting all behave the way you expect. 373 00:15:25,120 --> 00:15:28,120 Only then should you move more servers into the new approach. 374 00:15:28,120 --> 00:15:31,720 With the system clear, you can begin with a patch plan your team can repeat. 375 00:15:31,720 --> 00:15:34,320 Here's how to put Azure Update Manager into practice. 376 00:15:34,320 --> 00:15:35,320 Start with assessment. 377 00:15:35,320 --> 00:15:38,520 Look at machines missing security updates before you schedule anything. 378 00:15:38,520 --> 00:15:43,520 Then build patch rings, use Dev and Test first, then a small production pilot, then the wider group. 379 00:15:43,520 --> 00:15:45,520 Each ring gets its own maintenance window. 380 00:15:45,520 --> 00:15:47,520 Agree on reboot rules with your service owners. 381 00:15:47,520 --> 00:15:53,120 Send alerts when a patch job fails if servers run outside Azure connect them through Azure Arc. 382 00:15:53,120 --> 00:15:55,120 That gives you the same patch view everywhere. 383 00:15:55,120 --> 00:15:57,120 One process beats scattered lists. 384 00:15:57,120 --> 00:16:03,120 Azure Update Manager brings assessment, scheduling, patching and proof into one connected Azure service. 385 00:16:03,120 --> 00:16:05,920 Start with one small server group, confirm it works. 386 00:16:05,920 --> 00:16:11,920 Then expand, subscribe on your favorite podcast platform and share this knowledge nugget with someone planning their next patch night.