Azure Update Manager - Simply Explained

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.