1
00:00:00,000 --> 00:00:03,400
Today's topic is one that almost everyone in IT has heard of,

2
00:00:03,400 --> 00:00:05,800
but most people can't explain what it actually is.

3
00:00:05,800 --> 00:00:09,640
As your automation, is it just a fancy name for running scripts in the cloud,

4
00:00:09,640 --> 00:00:12,600
or is it something much bigger? Imagine you're an IT admin.

5
00:00:12,600 --> 00:00:14,600
Every single day you repeat the same tasks.

6
00:00:14,600 --> 00:00:18,480
Start a VM, stop another one, patch servers, clean up old files,

7
00:00:18,480 --> 00:00:22,000
maybe you run a script manually, maybe you set up a schedule task on one machine,

8
00:00:22,000 --> 00:00:24,200
it works, but it's fragile, it doesn't scale,

9
00:00:24,200 --> 00:00:27,200
and when you have 50 servers instead of five, it breaks completely.

10
00:00:27,200 --> 00:00:28,800
Most people just keep doing this manually,

11
00:00:28,800 --> 00:00:31,800
they log in, click around, run their scripts, it feels productive

12
00:00:31,800 --> 00:00:34,400
because you're getting things done, but here's the problem.

13
00:00:34,400 --> 00:00:37,000
You're wasting hours on work that a machine could do for you,

14
00:00:37,000 --> 00:00:40,600
and worse, every manual step introduces the chance of human error.

15
00:00:40,600 --> 00:00:43,800
You forget to patch one server, you stop the wrong VM, it happens.

16
00:00:43,800 --> 00:00:48,600
As your automation is like hiring a 24/7 assistant who never sleeps,

17
00:00:48,600 --> 00:00:51,000
you tell it what to do once and it handles the rest.

18
00:00:51,000 --> 00:00:54,200
On schedule, every time, no mistakes, no forgetting.

19
00:00:54,200 --> 00:00:57,800
In this episode, I'll show you what as your automation really is

20
00:00:57,800 --> 00:01:01,800
and break down the key building blocks, runbooks, schedules, hybrid workers,

21
00:01:01,800 --> 00:01:03,000
state configuration.

22
00:01:03,000 --> 00:01:07,000
By the end, you'll understand how all these pieces fit together to make your job easier.

23
00:01:07,000 --> 00:01:09,000
Let's start with why you even need this.

24
00:01:09,000 --> 00:01:10,000
Why automation?

25
00:01:10,000 --> 00:01:12,000
The problem of repetitive manual work.

26
00:01:12,000 --> 00:01:14,600
20 years ago, if you wanted to automate something,

27
00:01:14,600 --> 00:01:16,400
you logged into each server individually,

28
00:01:16,400 --> 00:01:18,600
you wrote a script, ran it on that one machine,

29
00:01:18,600 --> 00:01:20,600
and set up a schedule task locally.

30
00:01:20,600 --> 00:01:23,200
If you had five servers, you repeated the process five times.

31
00:01:23,200 --> 00:01:26,400
If you had 20, you did it 20 times, it was slow, it was boring,

32
00:01:26,400 --> 00:01:28,400
and it was incredibly easy to mess up.

33
00:01:28,400 --> 00:01:30,800
Here's the real cost. First, the wasted hours.

34
00:01:30,800 --> 00:01:33,600
Every time you manually run a task that could be automated,

35
00:01:33,600 --> 00:01:36,600
your burning time you could spend on something more valuable.

36
00:01:36,600 --> 00:01:37,800
Second, human errors.

37
00:01:37,800 --> 00:01:38,600
You forget a step.

38
00:01:38,600 --> 00:01:40,400
You run the wrong script on the wrong server.

39
00:01:40,400 --> 00:01:41,800
You miss a server entirely.

40
00:01:41,800 --> 00:01:43,000
Third, inconsistency.

41
00:01:43,000 --> 00:01:46,000
One server gets patched on Tuesday, another on Thursday.

42
00:01:46,000 --> 00:01:48,000
One has the right config, another doesn't.

43
00:01:48,000 --> 00:01:50,200
Over time, your environment drifts apart

44
00:01:50,200 --> 00:01:52,600
and that's when weird problems start showing up.

45
00:01:52,600 --> 00:01:55,600
The breaking point comes when you have tens or hundreds of VMs.

46
00:01:55,600 --> 00:01:58,200
At that scale, manual work just doesn't work anymore.

47
00:01:58,200 --> 00:02:00,600
You can't log into 100 servers one by one.

48
00:02:00,600 --> 00:02:04,200
You can't trust that every schedule task on every machine is running correctly.

49
00:02:04,200 --> 00:02:06,800
Something will break and you won't notice until it's too late.

50
00:02:06,800 --> 00:02:10,200
As your automation solves this by centralizing everything in one place,

51
00:02:10,200 --> 00:02:13,000
instead of having scripts scattered across individual machines,

52
00:02:13,000 --> 00:02:15,200
you store them in a single automation account.

53
00:02:15,200 --> 00:02:17,600
Instead of setting up schedule tasks on each server,

54
00:02:17,600 --> 00:02:19,600
you define one schedule in Azure.

55
00:02:19,600 --> 00:02:21,400
Instead of hoping everything runs correctly,

56
00:02:21,400 --> 00:02:23,200
you get logs, alerts, and reports.

57
00:02:23,200 --> 00:02:24,800
It runs your scripts on a schedule.

58
00:02:24,800 --> 00:02:27,000
It responds to alerts when something goes wrong.

59
00:02:27,000 --> 00:02:29,000
It can even fix problems before you notice them

60
00:02:29,000 --> 00:02:31,600
and it does all of this without you having to log into anything.

61
00:02:31,600 --> 00:02:33,400
So what's inside this automation tool?

62
00:02:33,400 --> 00:02:35,600
Let's look at the main building block, runbooks.

63
00:02:35,600 --> 00:02:37,600
Runbooks, the heart of automation.

64
00:02:37,600 --> 00:02:39,400
A runbook is just a script.

65
00:02:39,400 --> 00:02:41,600
Usually PowerShell, sometimes Python, that's it.

66
00:02:41,600 --> 00:02:42,600
There's no magic here.

67
00:02:42,600 --> 00:02:44,200
You write the steps you want to follow

68
00:02:44,200 --> 00:02:46,800
and Azure Automation follows them exactly every time.

69
00:02:46,800 --> 00:02:48,000
Think of it as a recipe.

70
00:02:48,000 --> 00:02:49,600
You write the instructions once.

71
00:02:49,600 --> 00:02:50,400
Start the VM.

72
00:02:50,400 --> 00:02:51,400
Wait for it to be ready.

73
00:02:51,400 --> 00:02:52,600
Run this command.

74
00:02:52,600 --> 00:02:54,200
Send an email when it's done.

75
00:02:54,200 --> 00:02:56,400
Then you hand that recipe to Azure Automation

76
00:02:56,400 --> 00:02:59,000
and it cooks the same meal every single time.

77
00:02:59,000 --> 00:03:00,000
No shortcuts.

78
00:03:00,000 --> 00:03:02,000
No forgetting ingredients.

79
00:03:02,000 --> 00:03:04,600
There are different types of runbooks.

80
00:03:04,600 --> 00:03:06,800
The most common are PowerShell and Python.

81
00:03:06,800 --> 00:03:08,400
These are text-based scripts

82
00:03:08,400 --> 00:03:11,000
that look exactly like what you'd write in your local editor.

83
00:03:11,000 --> 00:03:12,400
Then there's graphical runbooks.

84
00:03:12,400 --> 00:03:13,600
These let you build workflows

85
00:03:13,600 --> 00:03:16,000
by dragging and dropping activities on a canvas.

86
00:03:16,000 --> 00:03:17,000
They're designed for people

87
00:03:17,000 --> 00:03:19,200
who prefer visual tools over writing code.

88
00:03:19,200 --> 00:03:21,600
Personally, I'd stick with PowerShell or Python.

89
00:03:21,600 --> 00:03:23,200
They're easier to version control,

90
00:03:23,200 --> 00:03:25,400
easier to test and more flexible in the long run.

91
00:03:25,400 --> 00:03:28,000
Runbooks live inside your Automation account.

92
00:03:28,000 --> 00:03:29,800
That's the container that holds everything.

93
00:03:29,800 --> 00:03:31,600
Your runbooks, your schedules, your credentials,

94
00:03:31,600 --> 00:03:34,400
your variables, it's all stored centrally in Azure.

95
00:03:34,400 --> 00:03:36,800
Not scattered across individual servers.

96
00:03:36,800 --> 00:03:38,000
And here's the powerful part.

97
00:03:38,000 --> 00:03:39,600
Runbooks can do almost anything.

98
00:03:39,600 --> 00:03:41,000
Start and stop VMs.

99
00:03:41,000 --> 00:03:42,800
Copy files between storage accounts.

100
00:03:42,800 --> 00:03:43,800
Query databases.

101
00:03:43,800 --> 00:03:45,000
Call external APIs.

102
00:03:45,000 --> 00:03:46,400
Send notifications.

103
00:03:46,400 --> 00:03:48,000
If you can do it with PowerShell or Python,

104
00:03:48,000 --> 00:03:49,000
you can put it in a runbook.

105
00:03:49,000 --> 00:03:50,000
Here's a simple example.

106
00:03:50,000 --> 00:03:51,500
You have a set of development VMs

107
00:03:51,500 --> 00:03:53,600
that only need to run during business hours.

108
00:03:53,600 --> 00:03:54,600
At 7pm every day,

109
00:03:54,600 --> 00:03:56,400
you want them all shut down to save money.

110
00:03:56,400 --> 00:03:58,600
You write a runbook that loops through your dev VMs

111
00:03:58,600 --> 00:03:59,700
and stops each one.

112
00:03:59,700 --> 00:04:00,700
You test it once.

113
00:04:00,700 --> 00:04:01,200
It works.

114
00:04:01,200 --> 00:04:02,000
And from that point on,

115
00:04:02,000 --> 00:04:04,600
your 7pm shutdown happens automatically.

116
00:04:04,600 --> 00:04:06,500
But a runbook sitting idle is useless.

117
00:04:06,500 --> 00:04:08,300
You need to tell it when to run.

118
00:04:08,300 --> 00:04:11,100
Scheduling and triggers when the magic happens.

119
00:04:11,100 --> 00:04:12,500
The simplest way to start a runbook

120
00:04:12,500 --> 00:04:14,400
is to hit the run button in the portal.

121
00:04:14,400 --> 00:04:15,500
That's great for testing.

122
00:04:15,500 --> 00:04:18,300
You write your script, click start, and watch it execute.

123
00:04:18,300 --> 00:04:19,400
But that's not automation.

124
00:04:19,400 --> 00:04:21,800
That's just running a script manually from a web page.

125
00:04:21,800 --> 00:04:23,400
Real automation needs a trigger,

126
00:04:23,400 --> 00:04:25,200
something that tells your runbook when to run

127
00:04:25,200 --> 00:04:26,800
without you touching anything.

128
00:04:26,800 --> 00:04:28,300
The most common trigger is a schedule.

129
00:04:28,300 --> 00:04:29,300
You set a time,

130
00:04:29,300 --> 00:04:31,800
and as your automation runs the runbook at that time.

131
00:04:31,800 --> 00:04:33,300
Daily, weekly, one time.

132
00:04:33,300 --> 00:04:35,000
It works like an alarm clock for your runbook.

133
00:04:35,000 --> 00:04:36,800
You pick the time zone, the frequency,

134
00:04:36,800 --> 00:04:37,600
and you're done.

135
00:04:37,600 --> 00:04:38,400
From that point on,

136
00:04:38,400 --> 00:04:40,300
your runbook runs automatically.

137
00:04:40,300 --> 00:04:41,800
But schedules aren't the only way.

138
00:04:41,800 --> 00:04:43,700
You can also trigger runbooks from alerts.

139
00:04:43,700 --> 00:04:46,800
Imagine you have a VM that spikes to 95% CPU

140
00:04:46,800 --> 00:04:47,600
and alert fires,

141
00:04:47,600 --> 00:04:49,700
and that alert can automatically start a runbook

142
00:04:49,700 --> 00:04:50,800
that investigates the issue,

143
00:04:50,800 --> 00:04:51,800
maybe even fixes it,

144
00:04:51,800 --> 00:04:53,000
same with low disk space.

145
00:04:53,000 --> 00:04:54,700
Instead of waiting for someone to notice,

146
00:04:54,700 --> 00:04:56,300
the alert triggers a cleanup runbook

147
00:04:56,300 --> 00:04:57,600
before the disk fills up.

148
00:04:57,600 --> 00:04:59,200
Then there are web hooks.

149
00:04:59,200 --> 00:05:01,100
A web hook is basically a URL

150
00:05:01,100 --> 00:05:03,300
that when called starts your runbook.

151
00:05:03,300 --> 00:05:06,000
This is how you connect as your automation to other services.

152
00:05:06,000 --> 00:05:07,300
Logic apps can call it,

153
00:05:07,300 --> 00:05:08,700
third party tools can call it,

154
00:05:08,700 --> 00:05:10,200
and you can even trigger a runbook

155
00:05:10,200 --> 00:05:11,900
from a custom application.

156
00:05:11,900 --> 00:05:14,700
You just make an HTTP request to the web book URL

157
00:05:14,700 --> 00:05:16,100
and your runbook fires.

158
00:05:16,100 --> 00:05:17,500
One thing that's easy to miss,

159
00:05:17,500 --> 00:05:18,800
schedules are shared resources.

160
00:05:18,800 --> 00:05:20,000
You create one schedule,

161
00:05:20,000 --> 00:05:21,800
and you can link it to multiple runbooks.

162
00:05:21,800 --> 00:05:23,900
So you can have a 7 p.m. shutdown schedule

163
00:05:23,900 --> 00:05:25,500
that triggers your stop VM runbook

164
00:05:25,500 --> 00:05:27,500
and your cleanup runbook and your logging runbook.

165
00:05:27,500 --> 00:05:29,000
One schedule, multiple actions.

166
00:05:29,000 --> 00:05:30,200
Here's a real example.

167
00:05:30,200 --> 00:05:32,100
You have 10 development VMs.

168
00:05:32,100 --> 00:05:33,800
They cost money every hour they run.

169
00:05:33,800 --> 00:05:36,500
So you create a schedule that runs a stop VM runbook

170
00:05:36,500 --> 00:05:38,200
at 7 p.m. every weekday.

171
00:05:38,200 --> 00:05:39,300
Then you create another schedule

172
00:05:39,300 --> 00:05:41,600
that runs a start VM runbook at 6 a.m.

173
00:05:41,600 --> 00:05:42,100
That's it,

174
00:05:42,100 --> 00:05:43,600
your VMs run during business hours

175
00:05:43,600 --> 00:05:44,600
and shutdown at night,

176
00:05:44,600 --> 00:05:45,800
no manual intervention,

177
00:05:45,800 --> 00:05:46,900
no forgotten servers,

178
00:05:46,900 --> 00:05:48,100
just automatic savings.

179
00:05:48,100 --> 00:05:51,800
Now what of the machines you need to manage aren't

180
00:05:51,800 --> 00:05:52,800
in Azure?

181
00:05:52,800 --> 00:05:55,100
Hybrid workers automating outside the cloud.

182
00:05:55,100 --> 00:05:57,900
By default, your runbooks execute inside Azure Sandbox.

183
00:05:57,900 --> 00:05:59,500
That's Microsoft's compute environment.

184
00:05:59,500 --> 00:06:01,100
It's fast, it's managed,

185
00:06:01,100 --> 00:06:03,200
and it works great for anything that lives in Azure.

186
00:06:03,200 --> 00:06:05,100
But what about your on-premises servers,

187
00:06:05,100 --> 00:06:07,000
the ones sitting in your own data center?

188
00:06:07,000 --> 00:06:08,500
The file server in the corner,

189
00:06:08,500 --> 00:06:09,600
the domain controller,

190
00:06:09,600 --> 00:06:11,900
the school server that can't be moved to the cloud,

191
00:06:11,900 --> 00:06:13,500
the sandbox can't reach those machines.

192
00:06:13,500 --> 00:06:14,900
It's inside Azure's network,

193
00:06:14,900 --> 00:06:15,500
not yours.

194
00:06:15,500 --> 00:06:17,300
That's where hybrid runbook workers come in.

195
00:06:17,300 --> 00:06:19,900
A hybrid runbook worker is exactly what it sounds like.

196
00:06:19,900 --> 00:06:21,700
You install the runbook worker software

197
00:06:21,700 --> 00:06:23,800
on any machine, Windows or Linux.

198
00:06:23,800 --> 00:06:25,500
That machine then becomes the robot

199
00:06:25,500 --> 00:06:27,000
that runs your runbooks locally.

200
00:06:27,000 --> 00:06:29,000
Instead of executing an Azure Sandbox,

201
00:06:29,000 --> 00:06:30,900
the runbook runs directly on that machine.

202
00:06:30,900 --> 00:06:31,900
Using its network,

203
00:06:31,900 --> 00:06:32,900
its permissions,

204
00:06:32,900 --> 00:06:33,900
its access to local resources.

205
00:06:33,900 --> 00:06:35,400
This is perfect for a few scenarios.

206
00:06:35,400 --> 00:06:36,200
On-premises,

207
00:06:36,200 --> 00:06:38,200
servers that can't leave your data center,

208
00:06:38,200 --> 00:06:39,700
machines behind private networks

209
00:06:39,700 --> 00:06:41,500
that don't have direct internet access,

210
00:06:41,500 --> 00:06:43,400
servers that need to reach local file shares,

211
00:06:43,400 --> 00:06:45,700
active directory or legacy applications.

212
00:06:45,700 --> 00:06:48,300
The modern way to set this up is through Azure Arc.

213
00:06:48,300 --> 00:06:51,100
You connect your on-premises machine to Azure using Arc

214
00:06:51,100 --> 00:06:53,400
and then you add it as a hybrid runbook worker.

215
00:06:53,400 --> 00:06:54,600
Arc handles the identity,

216
00:06:54,600 --> 00:06:56,300
the connectivity, the management.

217
00:06:56,300 --> 00:06:57,400
From Azure's perspective,

218
00:06:57,400 --> 00:07:00,300
that on-prem server looks just like an Azure resource.

219
00:07:00,300 --> 00:07:01,400
You can apply policies,

220
00:07:01,400 --> 00:07:03,700
assign roles and of course run runbooks on it.

221
00:07:03,700 --> 00:07:06,100
There are some real benefits to using hybrid workers.

222
00:07:06,100 --> 00:07:07,600
First, the three hour runtime limit

223
00:07:07,600 --> 00:07:08,900
that exists in the sandbox,

224
00:07:08,900 --> 00:07:10,300
that doesn't apply here.

225
00:07:10,300 --> 00:07:12,200
Your runbook can run for as long as it needs,

226
00:07:12,200 --> 00:07:13,900
hours, days, doesn't matter.

227
00:07:13,900 --> 00:07:16,100
Second, you have full access to local resources.

228
00:07:16,100 --> 00:07:18,100
You can read local files, run local commands,

229
00:07:18,100 --> 00:07:19,600
connect to local databases.

230
00:07:19,600 --> 00:07:22,800
Third, you control the execution environment completely.

231
00:07:22,800 --> 00:07:24,500
You install whatever modules you need,

232
00:07:24,500 --> 00:07:26,400
you configure the machine however you want.

233
00:07:26,400 --> 00:07:27,400
But there's a trade-off.

234
00:07:27,400 --> 00:07:29,000
You manage that worker machine.

235
00:07:29,000 --> 00:07:31,500
You're responsible for updates, security patches,

236
00:07:31,500 --> 00:07:32,600
keeping it running.

237
00:07:32,600 --> 00:07:34,300
It's not a managed service anymore.

238
00:07:34,300 --> 00:07:35,800
It's your machine doing the work.

239
00:07:35,800 --> 00:07:38,300
Still, for organizations with hybrid environments,

240
00:07:38,300 --> 00:07:39,600
hybrid workers are essential.

241
00:07:39,600 --> 00:07:40,800
They extend your automation reach

242
00:07:40,800 --> 00:07:42,700
from the cloud into your own data center,

243
00:07:42,700 --> 00:07:44,800
but automation isn't just about running scripts.

244
00:07:44,800 --> 00:07:47,000
It's also about keeping servers consistent.

245
00:07:47,000 --> 00:07:49,400
State configuration, keeping servers in line.

246
00:07:49,400 --> 00:07:51,700
Ever had a server drift from its intended setup?

247
00:07:51,700 --> 00:07:53,100
Someone changes a setting,

248
00:07:53,100 --> 00:07:54,700
installs something they shouldn't,

249
00:07:54,700 --> 00:07:56,800
or disables a service they needed to leave running,

250
00:07:56,800 --> 00:07:57,900
suddenly things break.

251
00:07:57,900 --> 00:08:00,200
And you spend hours trying to figure out what changed.

252
00:08:00,200 --> 00:08:03,400
That's the problem as your automation state configuration solves.

253
00:08:03,400 --> 00:08:05,400
It's built on something called PowerShell.dsc,

254
00:08:05,400 --> 00:08:06,700
desired state configuration.

255
00:08:06,700 --> 00:08:08,200
The name tells you exactly what it does.

256
00:08:08,200 --> 00:08:10,900
You define the state you want and a zero automation,

257
00:08:10,900 --> 00:08:13,300
make sure every machine stays in that state.

258
00:08:13,300 --> 00:08:14,100
Here's how it works.

259
00:08:14,100 --> 00:08:16,600
You define the golden state for your servers,

260
00:08:16,600 --> 00:08:18,600
which Windows features should be enabled,

261
00:08:18,600 --> 00:08:20,400
which registry keys need to be set,

262
00:08:20,400 --> 00:08:21,900
what services should be running,

263
00:08:21,900 --> 00:08:23,800
which security settings are required.

264
00:08:23,800 --> 00:08:25,800
You write all of this in a configuration file,

265
00:08:25,800 --> 00:08:27,900
and you upload it to your automation account.

266
00:08:27,900 --> 00:08:30,400
Then the DSC agent on each machine checks in.

267
00:08:30,400 --> 00:08:32,300
It looks at the configuration you defined,

268
00:08:32,300 --> 00:08:34,400
compares it to what's actually running on that server,

269
00:08:34,400 --> 00:08:35,300
and reports back.

270
00:08:35,300 --> 00:08:36,200
Is it compliant?

271
00:08:36,200 --> 00:08:37,100
Yes or no?

272
00:08:37,100 --> 00:08:38,500
You can see this in a dashboard,

273
00:08:38,500 --> 00:08:40,500
a list of all your machines green for compliant,

274
00:08:40,500 --> 00:08:41,300
red for not.

275
00:08:41,300 --> 00:08:42,700
But here's where it gets really useful.

276
00:08:42,700 --> 00:08:44,900
If a machine drifts from its desired state,

277
00:08:44,900 --> 00:08:46,300
it can auto correct itself.

278
00:08:46,300 --> 00:08:48,000
The agent doesn't just report the problem.

279
00:08:48,000 --> 00:08:48,700
It fixes it.

280
00:08:48,700 --> 00:08:49,600
A server gets stopped.

281
00:08:49,600 --> 00:08:50,600
It starts it again.

282
00:08:50,600 --> 00:08:51,900
A registry key gets changed.

283
00:08:51,900 --> 00:08:52,700
It sets it back.

284
00:08:52,700 --> 00:08:54,500
The machine pulls itself back into compliance

285
00:08:54,500 --> 00:08:55,700
without anyone touching it.

286
00:08:55,700 --> 00:08:58,700
This is also incredibly useful for initial server setup.

287
00:08:58,700 --> 00:09:01,300
Instead of configuring each new server by hand,

288
00:09:01,300 --> 00:09:02,800
you just assign it a configuration.

289
00:09:02,800 --> 00:09:05,700
The DSC agent pulls the configuration, applies it.

290
00:09:05,700 --> 00:09:08,400
And within minutes, the server is an exactly the state you want.

291
00:09:08,400 --> 00:09:10,100
Deployed to 100 servers at once.

292
00:09:10,100 --> 00:09:12,200
Same result every time, one thing to note.

293
00:09:12,200 --> 00:09:13,300
This feature is evolving.

294
00:09:13,300 --> 00:09:15,100
Microsoft is moving towards something called

295
00:09:15,100 --> 00:09:16,700
Azure machine configuration.

296
00:09:16,700 --> 00:09:18,400
It's the next generation of the same idea,

297
00:09:18,400 --> 00:09:20,000
more reporting, more flexibility,

298
00:09:20,000 --> 00:09:21,900
tighter integration with Azure policy,

299
00:09:21,900 --> 00:09:23,900
but the core concept stays the same.

300
00:09:23,900 --> 00:09:25,300
Define your desired state.

301
00:09:25,300 --> 00:09:26,600
Let automation keep it there.

302
00:09:26,600 --> 00:09:28,300
All these runbooks and configurations

303
00:09:28,300 --> 00:09:29,600
need certain things, though,

304
00:09:29,600 --> 00:09:32,100
credentials, variables, connections.

305
00:09:32,100 --> 00:09:33,800
Let's look at shared resources.

306
00:09:33,800 --> 00:09:35,900
Shared resources, the utility closet.

307
00:09:35,900 --> 00:09:37,800
Your runbooks often need secrets,

308
00:09:37,800 --> 00:09:39,700
passwords to connect to databases,

309
00:09:39,700 --> 00:09:41,900
API keys to call external services,

310
00:09:41,900 --> 00:09:43,900
connection strings to reach other systems.

311
00:09:43,900 --> 00:09:45,900
The worst thing you can do is hard code those secrets

312
00:09:45,900 --> 00:09:47,200
directly into your runbook.

313
00:09:47,200 --> 00:09:47,800
Why?

314
00:09:47,800 --> 00:09:49,600
Because now that secret lives in your script,

315
00:09:49,600 --> 00:09:50,600
it's in your source control.

316
00:09:50,600 --> 00:09:53,100
Anyone who can see the runbook can see the password.

317
00:09:53,100 --> 00:09:54,300
And when you need to rotate it,

318
00:09:54,300 --> 00:09:55,600
you have to edit the runbook,

319
00:09:55,600 --> 00:09:58,100
republish it, test it again, it's a mess.

320
00:09:58,100 --> 00:10:00,400
Azure automation solves this with shared resources.

321
00:10:00,400 --> 00:10:02,500
Think of it as a utility closet for your runbooks.

322
00:10:02,500 --> 00:10:04,100
All the things your scripts need,

323
00:10:04,100 --> 00:10:05,900
stored centrally and securely.

324
00:10:05,900 --> 00:10:07,100
First, variables.

325
00:10:07,100 --> 00:10:08,300
These store simple values,

326
00:10:08,300 --> 00:10:10,200
a VM name, a subscription ID,

327
00:10:10,200 --> 00:10:11,300
a region name.

328
00:10:11,300 --> 00:10:13,700
Instead of writing "Eastus" directly into your script,

329
00:10:13,700 --> 00:10:15,900
you create a variable called Azure Region

330
00:10:15,900 --> 00:10:17,600
and set it to "Eastus".

331
00:10:17,600 --> 00:10:19,100
When you need to change regions later,

332
00:10:19,100 --> 00:10:20,700
you update the variable once.

333
00:10:20,700 --> 00:10:24,400
Every runbook that uses it picks up the change automatically.

334
00:10:24,400 --> 00:10:25,700
Second, credentials.

335
00:10:25,700 --> 00:10:28,000
These store usernames and passwords securely.

336
00:10:28,000 --> 00:10:29,400
You create a credential asset,

337
00:10:29,400 --> 00:10:30,200
give it a name,

338
00:10:30,200 --> 00:10:32,300
and store the username and password inside.

339
00:10:32,300 --> 00:10:34,700
Your runbook references that credential by name.

340
00:10:34,700 --> 00:10:36,500
It never sees the actual password.

341
00:10:36,500 --> 00:10:38,200
Azure automation handles the decryption

342
00:10:38,200 --> 00:10:39,600
when the runbook runs.

343
00:10:39,600 --> 00:10:41,100
Third, certificates.

344
00:10:41,100 --> 00:10:43,100
For authentication to other services.

345
00:10:43,100 --> 00:10:43,900
Same idea.

346
00:10:43,900 --> 00:10:45,200
Upload the certificate once,

347
00:10:45,200 --> 00:10:47,100
reference it in your runbook.

348
00:10:47,100 --> 00:10:48,600
Fourth, connections.

349
00:10:48,600 --> 00:10:51,000
These are predefined links to Azure or other services.

350
00:10:51,000 --> 00:10:52,200
You set up the connection once

351
00:10:52,200 --> 00:10:53,600
with all the required parameters

352
00:10:53,600 --> 00:10:55,200
and your runbook just calls it.

353
00:10:55,200 --> 00:10:57,200
All of these resources are encrypted.

354
00:10:57,200 --> 00:10:58,900
Only your runbooks can access them.

355
00:10:58,900 --> 00:11:00,300
No hard-coded secrets,

356
00:11:00,300 --> 00:11:02,700
no password sitting in plain text files.

357
00:11:02,700 --> 00:11:04,100
Here's a simple example.

358
00:11:04,100 --> 00:11:06,600
You create a variable called OfficeHoursEnd

359
00:11:06,600 --> 00:11:08,500
and set it to 19Honetacorque.

360
00:11:08,500 --> 00:11:10,400
Your shutdown runbook reads that variable

361
00:11:10,400 --> 00:11:12,700
instead of having 19Honetacorque coded.

362
00:11:12,700 --> 00:11:14,700
When business hours change to 18Honetac,

363
00:11:14,700 --> 00:11:16,100
you update the variable.

364
00:11:16,100 --> 00:11:17,900
The runbook doesn't change one update,

365
00:11:17,900 --> 00:11:21,200
and every schedule that uses that variable adjusts automatically.

366
00:11:21,200 --> 00:11:22,300
But who runs the runbook?

367
00:11:22,300 --> 00:11:23,700
That's where identities come in.

368
00:11:23,700 --> 00:11:25,200
Managed identities.

369
00:11:25,200 --> 00:11:27,400
Secure authentication without passwords.

370
00:11:27,400 --> 00:11:29,700
Every runbook needs permission to do things,

371
00:11:29,700 --> 00:11:32,400
stopping a VM, reading a secret from Key Vault,

372
00:11:32,400 --> 00:11:33,600
querying a database.

373
00:11:33,600 --> 00:11:36,100
The runbook itself doesn't have inherent access to anything.

374
00:11:36,100 --> 00:11:37,500
You have to give it permission.

375
00:11:37,500 --> 00:11:39,300
The old way of doing this was painful.

376
00:11:39,300 --> 00:11:42,100
You'd create a service principle in Azure Active Directory.

377
00:11:42,100 --> 00:11:44,900
That's basically a digital identity for your application.

378
00:11:44,900 --> 00:11:47,500
Then you generate a password for that service principle,

379
00:11:47,500 --> 00:11:49,000
store it somewhere secure,

380
00:11:49,000 --> 00:11:50,900
and configure your runbook to use it.

381
00:11:50,900 --> 00:11:52,100
And then every year or so,

382
00:11:52,100 --> 00:11:53,500
you'd have to rotate that password.

383
00:11:53,500 --> 00:11:55,400
Generate a new one, update your runbook,

384
00:11:55,400 --> 00:11:56,900
test it, hope nothing broke.

385
00:11:56,900 --> 00:11:57,700
It worked,

386
00:11:57,700 --> 00:11:59,600
but it was a constant maintenance burden.

387
00:11:59,600 --> 00:12:01,800
Managed identities solve this completely.

388
00:12:01,800 --> 00:12:04,300
A managed identity is exactly what it sounds like.

389
00:12:04,300 --> 00:12:05,800
Azure handles the identity for you.

390
00:12:05,800 --> 00:12:07,400
It creates it, manages it,

391
00:12:07,400 --> 00:12:09,600
and rotates the credentials automatically.

392
00:12:09,600 --> 00:12:11,000
You never see a password.

393
00:12:11,000 --> 00:12:12,300
You never have to update one.

394
00:12:12,300 --> 00:12:15,200
It's like a digital badge that your automation account wears.

395
00:12:15,200 --> 00:12:16,200
When the runbook runs,

396
00:12:16,200 --> 00:12:18,800
it presents that badge and Azure recognizes it.

397
00:12:18,800 --> 00:12:19,800
There are two types.

398
00:12:19,800 --> 00:12:22,400
System assigned managed identity is tied directly

399
00:12:22,400 --> 00:12:23,600
to your automation account.

400
00:12:23,600 --> 00:12:25,000
It lives and dies with that account.

401
00:12:25,000 --> 00:12:27,400
If you delete the account, the identity goes away.

402
00:12:27,400 --> 00:12:29,800
Simple, clean, one identity per account,

403
00:12:29,800 --> 00:12:32,100
user assigned managed identity is separate.

404
00:12:32,100 --> 00:12:34,300
You create it as its own resource in Azure,

405
00:12:34,300 --> 00:12:35,700
and then you can assign it

406
00:12:35,700 --> 00:12:37,100
to multiple automation accounts

407
00:12:37,100 --> 00:12:38,900
or even to other Azure services.

408
00:12:38,900 --> 00:12:40,700
This is useful when you want the same identity

409
00:12:40,700 --> 00:12:42,900
and permissions to be shared across different systems.

410
00:12:42,900 --> 00:12:44,700
More flexible, but slightly more set up.

411
00:12:44,700 --> 00:12:45,900
Here's how it works in practice.

412
00:12:45,900 --> 00:12:47,500
You go to your automation account,

413
00:12:47,500 --> 00:12:49,300
enable the managed identity.

414
00:12:49,300 --> 00:12:50,400
Then you go to the resource,

415
00:12:50,400 --> 00:12:51,600
you want your runbook to manage

416
00:12:51,600 --> 00:12:53,100
maybe a resource group full of VMs

417
00:12:53,100 --> 00:12:55,100
and you assign a role to that identity,

418
00:12:55,100 --> 00:12:56,100
contributor reader,

419
00:12:56,100 --> 00:12:56,900
whatever it needs.

420
00:12:56,900 --> 00:12:58,400
You do this once, that's it.

421
00:12:58,400 --> 00:12:59,900
Then inside your runbook,

422
00:12:59,900 --> 00:13:01,200
instead of storing a password

423
00:13:01,200 --> 00:13:02,700
or using a credential asset,

424
00:13:02,700 --> 00:13:03,900
you just call one line.

425
00:13:03,900 --> 00:13:05,300
Connect as account identity.

426
00:13:05,300 --> 00:13:06,600
That's the whole authentication.

427
00:13:06,600 --> 00:13:09,100
No passwords, no secrets, no rotation.

428
00:13:09,100 --> 00:13:10,800
The runbook runs as your recognizes

429
00:13:10,800 --> 00:13:11,800
the managed identity,

430
00:13:11,800 --> 00:13:13,500
checks the permissions you assigned,

431
00:13:13,500 --> 00:13:14,800
and lets it do its work.

432
00:13:14,800 --> 00:13:15,800
This is the best practice.

433
00:13:15,800 --> 00:13:17,800
Always use managed identities when you can.

434
00:13:17,800 --> 00:13:19,800
They're most secure because there's no password

435
00:13:19,800 --> 00:13:21,300
to leak, they're easier to maintain

436
00:13:21,300 --> 00:13:23,000
because there's nothing to rotate.

437
00:13:23,000 --> 00:13:24,100
And they're simpler to set up

438
00:13:24,100 --> 00:13:25,200
because you don't need to create

439
00:13:25,200 --> 00:13:26,800
and configure service principles.

440
00:13:26,800 --> 00:13:28,200
With all these pieces,

441
00:13:28,200 --> 00:13:30,100
let's see a real world example.

442
00:13:30,100 --> 00:13:31,300
Putting it all together,

443
00:13:31,300 --> 00:13:32,900
a simple start stop scenario.

444
00:13:32,900 --> 00:13:33,900
Let's make this concrete.

445
00:13:33,900 --> 00:13:35,300
You have 10 development VMs.

446
00:13:35,300 --> 00:13:37,200
They only need to run during business hours.

447
00:13:37,200 --> 00:13:39,400
From 6 a.m. to 7 p.m. Monday through Friday,

448
00:13:39,400 --> 00:13:40,200
the rest of the time,

449
00:13:40,200 --> 00:13:41,900
they're sitting there, burning money,

450
00:13:41,900 --> 00:13:42,800
not doing any work,

451
00:13:42,800 --> 00:13:44,800
but still costing you compute hours.

452
00:13:44,800 --> 00:13:45,900
Here's how you automate this

453
00:13:45,900 --> 00:13:47,800
with Azure Automation in five steps.

454
00:13:47,800 --> 00:13:49,700
Step one, create an automation account.

455
00:13:49,700 --> 00:13:50,600
This is your central hub.

456
00:13:50,600 --> 00:13:52,900
It takes about 30 seconds in the portal

457
00:13:52,900 --> 00:13:55,100
and the first 500 minutes of runbook execution

458
00:13:55,100 --> 00:13:56,000
each month are free.

459
00:13:56,000 --> 00:13:57,500
So for a simple start stop scenario,

460
00:13:57,500 --> 00:13:59,000
you might never pay a cent.

461
00:13:59,000 --> 00:14:00,700
Step two, import a runbook.

462
00:14:00,700 --> 00:14:02,500
You can write one from scratch if you want.

463
00:14:02,500 --> 00:14:05,300
A PowerShell script that gets all VMs in a resource group

464
00:14:05,300 --> 00:14:06,700
and starts or stops them.

465
00:14:06,700 --> 00:14:08,400
But you don't even have to write it yourself.

466
00:14:08,400 --> 00:14:11,200
Azure Automation has a gallery full of pre-built runbooks.

467
00:14:11,200 --> 00:14:13,400
There's one called start as your V2 VMs

468
00:14:13,400 --> 00:14:15,900
and another called stop as your V2 VMs.

469
00:14:15,900 --> 00:14:17,600
You import them and they're ready to go.

470
00:14:17,600 --> 00:14:18,900
Step three, create two schedules.

471
00:14:18,900 --> 00:14:21,500
One for started 6 a.m., one for stop at 7 p.m.

472
00:14:21,500 --> 00:14:23,200
Daily, Monday through Friday.

473
00:14:23,200 --> 00:14:25,500
Each schedule is just a time in a recurrence.

474
00:14:25,500 --> 00:14:26,900
Simple, step four.

475
00:14:26,900 --> 00:14:29,200
Give your automation accounts managed identity permission

476
00:14:29,200 --> 00:14:30,200
on those VMs.

477
00:14:30,200 --> 00:14:32,300
You go to the resource group, add a role assignment,

478
00:14:32,300 --> 00:14:34,600
select contributor, and pick your automation accounts

479
00:14:34,600 --> 00:14:35,600
managed identity.

480
00:14:35,600 --> 00:14:37,400
That's the permission your runbook needs to start

481
00:14:37,400 --> 00:14:38,600
and stop VMs.

482
00:14:38,600 --> 00:14:41,000
Step five, link the runbook to each schedule.

483
00:14:41,000 --> 00:14:42,800
You open the runbook, go to schedules,

484
00:14:42,800 --> 00:14:45,200
link the start schedule, then link the stop schedule.

485
00:14:45,200 --> 00:14:46,200
Done, that's it.

486
00:14:46,200 --> 00:14:48,400
From this point forward, every weekday at 6 a.m.

487
00:14:48,400 --> 00:14:50,300
your runbook starts all 10 VMs.

488
00:14:50,300 --> 00:14:52,700
At 7 p.m. it shuts them all down automatically.

489
00:14:52,700 --> 00:14:53,500
No one logs in.

490
00:14:53,500 --> 00:14:55,700
No one remembers to do it, it just happens.

491
00:14:55,700 --> 00:14:56,800
And the savings add up.

492
00:14:56,800 --> 00:15:00,000
10 VMs running 24 hours a day, 7 days a week costs a lot.

493
00:15:00,000 --> 00:15:03,300
10 VMs running only during business hours, 5 days a week,

494
00:15:03,300 --> 00:15:04,900
costs less than half.

495
00:15:04,900 --> 00:15:07,300
The few cents you pay for runbook execution minutes

496
00:15:07,300 --> 00:15:09,500
are nothing compared to the compute savings.

497
00:15:09,500 --> 00:15:10,500
That's the big picture.

498
00:15:10,500 --> 00:15:12,100
Let me wrap it up for you.

499
00:15:12,100 --> 00:15:13,100
So there you have it.

500
00:15:13,100 --> 00:15:14,500
Azure Automation in plain English.

501
00:15:14,500 --> 00:15:17,600
It's your 24/7 cloud assistant that runs, scripts,

502
00:15:17,600 --> 00:15:20,300
keeps servers consistent, and reaches anywhere.

503
00:15:20,300 --> 00:15:22,700
Even on-premises, the key building blocks,

504
00:15:22,700 --> 00:15:25,000
runbooks for the logic, schedules for timing,

505
00:15:25,000 --> 00:15:28,200
hybrid workers for reach, state configuration for consistency,

506
00:15:28,200 --> 00:15:31,500
and managed identities for secure access without passwords.

507
00:15:31,500 --> 00:15:34,000
If you're starting, pick one repetitive task.

508
00:15:34,000 --> 00:15:34,800
Just one.

509
00:15:34,800 --> 00:15:37,200
Maybe shutting down a VM at night, automate that.

510
00:15:37,200 --> 00:15:38,800
That's your first knowledge nugget.

511
00:15:38,800 --> 00:15:42,100
If this helped, subscribe for more plain English explanations,

512
00:15:42,100 --> 00:15:45,200
and share this with a colleague who's just starting their cloud journey.

513
00:15:45,200 --> 00:15:46,200
They'll thank you later.