Aug. 10, 2026
Azure Image Builder - Simply Explained
Azure Image Builder solves a problem that becomes increasingly difficult as environments grow: manually creating and maintaining standardized virtual machine images. The traditional process often starts with a clean VM. An administrator installs Windows updates, applications, monitoring agents, security tools, certificates, and configuration changes. The VM is tested, generalized, and finally captured as an image. That approach can work, but it depends heavily on people remembering every step. When updates or requirements change, the process has to be repeated, and small differences can quickly appear between supposedly identical images. Azure Image Builder replaces that manual routine with a repeatable Azure-based process.
ㅤ
WHAT IS AZURE IMAGE BUILDER?
Azure Image Builder is an Azure service that creates customized virtual machine images from instructions you define. You begin with a known source image, define the changes that should be made, and Azure produces a new customized image. The result becomes a standardized starting point for future virtual machines rather than requiring administrators to configure every new VM manually.
ㅤ
START WITH A KNOWN SOURCE IMAGE
Azure Image Builder can begin with Windows or Linux images from Azure Marketplace. That could include Windows Server, Windows 11, Ubuntu, or another supported operating system. Organizations can also start with images they have already created, including existing company images or images stored in Azure Compute Gallery. This means you don't necessarily need to rebuild everything from scratch whenever the image changes.
ㅤ
IMAGE BUILDER DOES NOT CREATE YOUR PRODUCTION VMS
The name can create some confusion. Azure Image Builder isn't primarily responsible for creating the production VMs that users or applications eventually consume. It creates the prepared image first. Afterward, organizations can create one VM, ten VMs, or potentially much larger deployments from that finished image. Think of Image Builder as creating the approved master copy from which future machines are deployed.
ㅤ
PACKER BEHIND THE SCENES
Azure Image Builder uses HashiCorp Packer behind the scenes. Packer is widely used for automating machine-image creation. Azure Image Builder provides an Azure-managed layer around that process, meaning organizations don't need to operate their own Packer infrastructure simply to automate Azure image builds. You define what the image should contain while Azure manages much of the temporary infrastructure required to create it.
ㅤ
WHY AUTOMATE VM IMAGES?
Imagine that every Windows Server in your organization should begin with the same Windows updates, browser, monitoring agent, security software, certificates, and configuration baseline. With a manual process, administrators need to reproduce those requirements correctly every time. With Azure Image Builder, those requirements become part of the image-building instructions. When something changes, you update the instructions and produce another image version. This replaces administrator memory and manual checklists with a repeatable process.
ㅤ
THE FIVE BUILDING BLOCKS
A useful way to understand Azure Image Builder is through five major components: Source. Customization. Validation. Distribution. Versioning. Together, these components describe where the image starts, what Azure changes, how the result is tested, where the finished image is published, and how different releases are managed.
ㅤ
SOURCE
The source image provides the operating system and initial configuration. A web-server team might begin with Ubuntu. An application team could use Windows Server. An Azure Virtual Desktop environment might begin with Windows 11. The source should match the workload the future VMs are expected to run.
ㅤ
CUSTOMIZATION
Customization defines what Azure Image Builder should change. Scripts can install applications, apply Windows updates, add language packs, install monitoring and security agents, configure certificates, remove unwanted software, or apply security settings. Azure Image Builder executes these customizations in the order you define. That order matters because applications and configuration changes can depend on earlier steps completing successfully.
ㅤ
KEEP CUSTOMIZATIONS SMALL
One enormous customization script can become difficult to troubleshoot. Smaller scripts make the process easier to understand and maintain. One script might install the monitoring agent. Another could configure security settings. Another might verify that a required application exists. When something fails, administrators can identify the problematic stage instead of investigating hundreds of unrelated lines in one script.
ㅤ
VALIDATION
A successful installation doesn't automatically mean the image works correctly. Validation allows organizations to check the finished configuration before publishing the image. You might verify that an application exists, confirm that an important service starts correctly, or check whether a security setting has the expected value. The objective is to discover problems during the image build rather than after dozens or hundreds of VMs have already been deployed.
ㅤ
DISTRIBUTION
After an image passes validation, Azure Image Builder can publish the result. Possible destinations include Azure Compute Gallery, a managed image, or a VHD file. For organizations managing reusable Azure VM images at scale, Azure Compute Gallery provides additional capabilities for organizing, versioning, replicating, and distributing those images.
ㅤ
VERSIONING
Each successful image build can create a new version. For example, an April image might contain one set of Windows updates and version 4.2 of a company agent. The May image could contain newer patches and version 4.3. Keeping these versions separate makes it possible to identify exactly which image produced a VM and provides a controlled way to return to an earlier known-good release if a newer image introduces problems.
ㅤ
THE IMAGE TEMPLATE
The image template acts as the instruction sheet for the entire build. It defines the source image, customizations, build configuration, networking requirements, destination, and identity used during the process. Instead of manually repeating the preparation process, the template describes what Azure should do every time the image is rebuilt.
ㅤ
MANAGED IDENTITY
Azure needs permission to interact with resources during the image build. A managed identity can provide those permissions without requiring usernames and passwords to be embedded inside scripts. The identity might need permission to read installation files, access storage, create temporary resources, use required networking, and publish the completed image. The principle of least privilege still applies: the build identity should receive only the permissions required to complete its job.
ㅤ
THE TEMPORARY BUILD VM
When a build begins, Azure creates temporary resources. One of the most important is a temporary virtual machine. This isn't a production server. It's the temporary workshop where Azure installs software, runs updates, applies settings, and prepares the final image. Supporting disks, networking, and storage resources can also appear during the build process.
ㅤ
WHY TEMPORARY RESOURCES APPEAR
Administrators may notice additional resources appearing in a staging resource group while Image Builder runs. This is expected. Azure needs actual compute and supporting infrastructure to execute the image-building process. The temporary VM allows Azure to customize a copy without modifying the original source image.
ㅤ
RUNNING THE CUSTOMIZATION SCRIPTS
Azure executes customization scripts according to the order defined in the template. A typical build might install a browser, add a security agent, install operating system updates, remove unwanted applications, and apply company security settings. Dependencies need to be considered carefully. If an application requires a Windows update before installation, the update needs to happen first. If an installer requires a restart, later steps need to account for that restart.
ㅤ
EVERYTHING MUST BE AUTOMATIC
Image-building scripts need to operate without human interaction. An installer that opens a dialog and waits for someone to click Next can stop the build. Applications should therefore support silent installation. Scripts should also wait for commands to complete and return meaningful success or failure codes. The temporary VM doesn't have an administrator sitting in front of it waiting to answer installation prompts.
ㅤ
BUILD ONCE, DEPLOY MANY TIMES
Consider a monthly Windows Server image. Image Builder starts with the current Windows Server source, installs the latest approved Windows updates, updates the browser, installs the company's security agent, and applies standard configuration. Once that image is created, every VM deployed from it already contains those changes. Instead of 100 new VMs individually downloading and installing the same software and patches, the preparation occurs once during image creation.
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
1
00:00:00,000 --> 00:00:02,860
So let's say your company needs a standard Windows server image.
2
00:00:02,860 --> 00:00:05,320
The old way usually starts with a fresh virtual machine.
3
00:00:05,320 --> 00:00:07,160
You install Windows updates.
4
00:00:07,160 --> 00:00:08,480
You add the apps people expect.
5
00:00:08,480 --> 00:00:11,000
You drop in a monitoring agent, tweak a few settings,
6
00:00:11,000 --> 00:00:13,560
apply security rules, test everything, run CISPRIP,
7
00:00:13,560 --> 00:00:15,280
and then capture the machine as an image.
8
00:00:15,280 --> 00:00:16,400
That can work.
9
00:00:16,400 --> 00:00:19,440
But it depends on someone remembering every single step.
10
00:00:19,440 --> 00:00:21,560
A month later, new Windows updates show up.
11
00:00:21,560 --> 00:00:22,920
A team asks for a different app.
12
00:00:22,920 --> 00:00:25,880
Security wants one registry setting changed.
13
00:00:25,880 --> 00:00:28,360
So somebody starts over, often from a set of notes
14
00:00:28,360 --> 00:00:30,880
that might be outdated, a script that only half works,
15
00:00:30,880 --> 00:00:33,040
and a few steps that live in one admin's head.
16
00:00:33,040 --> 00:00:34,240
You know how this ends?
17
00:00:34,240 --> 00:00:36,440
Two images with the same name can have different apps,
18
00:00:36,440 --> 00:00:38,320
different patches, and different settings.
19
00:00:38,320 --> 00:00:40,360
One person tests before capturing another
20
00:00:40,360 --> 00:00:42,120
skips a step because the deadline is tight.
21
00:00:42,120 --> 00:00:43,160
That's not a people problem.
22
00:00:43,160 --> 00:00:44,240
It's a process problem.
23
00:00:44,240 --> 00:00:47,240
I'm Mirko Peters from M365FM, and this knowledge nugget
24
00:00:47,240 --> 00:00:48,800
is about turning that hand-built routine
25
00:00:48,800 --> 00:00:50,480
into a repeatable Azure process.
26
00:00:50,480 --> 00:00:52,960
By the end, you'll know what Azure Image Builder does,
27
00:00:52,960 --> 00:00:55,120
what it doesn't do, and why it helps you create
28
00:00:55,120 --> 00:00:57,120
the same approved starting point every time.
29
00:00:57,120 --> 00:00:59,240
So what exactly is Azure Image Builder?
30
00:00:59,240 --> 00:01:01,480
What Azure Image Builder actually is?
31
00:01:01,480 --> 00:01:03,240
Azure Image Builder is an Azure service
32
00:01:03,240 --> 00:01:05,280
that creates customized virtual machine images
33
00:01:05,280 --> 00:01:07,160
from a set of instructions you define.
34
00:01:07,160 --> 00:01:09,320
That's the plain English definition.
35
00:01:09,320 --> 00:01:12,120
Think about a company laptop that IT has already prepped.
36
00:01:12,120 --> 00:01:14,520
It has Windows installed, the right security setting
37
00:01:14,520 --> 00:01:16,600
supplied, the approved tools added,
38
00:01:16,600 --> 00:01:18,560
and the unwanted software removed.
39
00:01:18,560 --> 00:01:20,360
Instead of preparing every laptop by hand,
40
00:01:20,360 --> 00:01:23,040
you create one master copy you can use again and again.
41
00:01:23,040 --> 00:01:24,840
A virtual machine image works the same way.
42
00:01:24,840 --> 00:01:27,920
It's a prepared starting copy for new virtual machines.
43
00:01:27,920 --> 00:01:30,080
You can start with a clean Windows or Linux image
44
00:01:30,080 --> 00:01:31,520
from Azure Marketplace.
45
00:01:31,520 --> 00:01:34,280
That might be Windows Server, Windows 11, Ubuntu,
46
00:01:34,280 --> 00:01:36,600
or another supported operating system.
47
00:01:36,600 --> 00:01:39,440
You can also begin with an image your company already created
48
00:01:39,440 --> 00:01:42,320
like a managed image or one stored in Azure Compute Gallery.
49
00:01:42,320 --> 00:01:43,920
So you don't always start from zero.
50
00:01:43,920 --> 00:01:46,640
Maybe your organization already has a secure Windows Server
51
00:01:46,640 --> 00:01:47,720
based image.
52
00:01:47,720 --> 00:01:49,880
Azure Image Builder can begin there,
53
00:01:49,880 --> 00:01:51,800
apply the next set of approved changes,
54
00:01:51,800 --> 00:01:53,120
and create a newer version.
55
00:01:53,120 --> 00:01:56,240
Or maybe you start with Microsoft's latest Windows 11 image
56
00:01:56,240 --> 00:01:58,640
and add your company's standard tools and settings.
57
00:01:58,640 --> 00:02:00,720
Either way, the idea stays simple.
58
00:02:00,720 --> 00:02:01,880
You start with a known source.
59
00:02:01,880 --> 00:02:03,480
You define what should change.
60
00:02:03,480 --> 00:02:04,960
Azure creates a new image.
61
00:02:04,960 --> 00:02:06,720
Now many people hear the word builder
62
00:02:06,720 --> 00:02:09,920
and assume it creates virtual machines for users or applications.
63
00:02:09,920 --> 00:02:10,920
It doesn't work that way.
64
00:02:10,920 --> 00:02:13,320
Azure Image Builder creates the image first.
65
00:02:13,320 --> 00:02:15,280
Later you create 1vm, 10vm,
66
00:02:15,280 --> 00:02:17,800
or a much larger group from that finished image.
67
00:02:17,800 --> 00:02:20,080
So it belongs earlier in the process,
68
00:02:20,080 --> 00:02:21,560
like preparing the master copy
69
00:02:21,560 --> 00:02:23,600
before anyone starts handing out copies.
70
00:02:23,600 --> 00:02:25,600
That distinction saves a lot of confusion.
71
00:02:25,600 --> 00:02:26,960
Azure Image Builder also uses
72
00:02:26,960 --> 00:02:28,760
HashieCork Packer behind the scenes.
73
00:02:28,760 --> 00:02:31,160
Packer is a tool that automates image creation,
74
00:02:31,160 --> 00:02:33,840
but Azure Image Builder puts an Azure managed layer
75
00:02:33,840 --> 00:02:34,920
around that work.
76
00:02:34,920 --> 00:02:37,400
You don't need to run and maintain your own Packer Server
77
00:02:37,400 --> 00:02:38,680
just to use the service.
78
00:02:38,680 --> 00:02:41,080
As your handles, most of the temporary build work,
79
00:02:41,080 --> 00:02:43,280
while you focus on the instructions for your image,
80
00:02:43,280 --> 00:02:45,200
you still need to define what you want.
81
00:02:45,200 --> 00:02:46,960
For example, you might want an image
82
00:02:46,960 --> 00:02:48,240
with current Windows updates,
83
00:02:48,240 --> 00:02:50,800
a browser, a monitoring agent, a security agent,
84
00:02:50,800 --> 00:02:52,080
and a few company settings.
85
00:02:52,080 --> 00:02:54,680
Instead of logging in and doing that work by hand every month,
86
00:02:54,680 --> 00:02:56,600
you write down those requirements once
87
00:02:56,600 --> 00:02:57,880
as part of the image build.
88
00:02:57,880 --> 00:03:00,560
Then the same instructions run again on the next build.
89
00:03:00,560 --> 00:03:03,080
That means every new vm starts with the same apps,
90
00:03:03,080 --> 00:03:04,520
the same patches, the same settings,
91
00:03:04,520 --> 00:03:06,440
and the same security baseline.
92
00:03:06,440 --> 00:03:07,440
If something needs to change,
93
00:03:07,440 --> 00:03:09,680
you update the instructions and build a new image.
94
00:03:09,680 --> 00:03:12,040
Instead of hoping every administrator follows the same list,
95
00:03:12,040 --> 00:03:13,800
that's the real reason to automate images.
96
00:03:13,800 --> 00:03:15,640
You're not just saving time during setup.
97
00:03:15,640 --> 00:03:17,640
You're replacing memory and manual work
98
00:03:17,640 --> 00:03:19,440
with a process you can repeat.
99
00:03:19,440 --> 00:03:23,080
The definition helps, but the next part makes the whole service easier to see.
100
00:03:23,080 --> 00:03:25,280
An image build has a few simple building blocks,
101
00:03:25,280 --> 00:03:27,280
and each one has a clear job.
102
00:03:27,280 --> 00:03:29,440
The five building blocks of an image build,
103
00:03:29,440 --> 00:03:31,680
let's picture the image build as preparing a new office
104
00:03:31,680 --> 00:03:33,040
before a team moves in.
105
00:03:33,040 --> 00:03:34,760
First, you need the empty office.
106
00:03:34,760 --> 00:03:35,960
That's your source image.
107
00:03:35,960 --> 00:03:37,520
The source is the clean starting point
108
00:03:37,520 --> 00:03:39,480
as your image builder uses for the build.
109
00:03:39,480 --> 00:03:41,720
Maybe it's Windows Server for an application server.
110
00:03:41,720 --> 00:03:43,880
Maybe it's Windows 11 for a desktop environment,
111
00:03:43,880 --> 00:03:46,000
or maybe it's Ubuntu for Linux Workload.
112
00:03:46,000 --> 00:03:47,480
You choose the source based on the job
113
00:03:47,480 --> 00:03:49,000
the future vm's need to do.
114
00:03:49,000 --> 00:03:51,640
For example, a web server team might start with Ubuntu.
115
00:03:51,640 --> 00:03:54,520
A finance application that usually needs Windows Server.
116
00:03:54,520 --> 00:03:56,360
And an Azure Virtual Desktop team
117
00:03:56,360 --> 00:03:58,200
will likely choose Windows 11.
118
00:03:58,200 --> 00:04:00,000
The source gives you the operating system,
119
00:04:00,000 --> 00:04:02,360
but it doesn't yet contain your company's setup.
120
00:04:02,360 --> 00:04:05,080
Think of it as an empty office with the walls, doors, power,
121
00:04:05,080 --> 00:04:06,880
and network already in place.
122
00:04:06,880 --> 00:04:08,760
The next building block is customization.
123
00:04:08,760 --> 00:04:10,280
This is where the setup crew comes in.
124
00:04:10,280 --> 00:04:12,440
You give Azure Image Builder scripts and instructions
125
00:04:12,440 --> 00:04:15,120
that describe what belongs in the office before people arrive.
126
00:04:15,120 --> 00:04:16,800
A script can install an application.
127
00:04:16,800 --> 00:04:18,320
Another can apply Windows updates.
128
00:04:18,320 --> 00:04:21,600
One might add a language pack for users in a certain country.
129
00:04:21,600 --> 00:04:23,400
You can also install a monitoring agent
130
00:04:23,400 --> 00:04:26,080
so your operations team can see whether the vm is healthy.
131
00:04:26,080 --> 00:04:28,400
You might add a security agent that checks for threats,
132
00:04:28,400 --> 00:04:30,160
or you might apply security settings,
133
00:04:30,160 --> 00:04:31,720
such as turning off an old protocol,
134
00:04:31,720 --> 00:04:33,200
setting a company time zone,
135
00:04:33,200 --> 00:04:34,800
removing unwanted software,
136
00:04:34,800 --> 00:04:36,600
or adding a required certificate.
137
00:04:36,600 --> 00:04:37,680
The order matters.
138
00:04:37,680 --> 00:04:39,840
If an application needs a certain Windows feature,
139
00:04:39,840 --> 00:04:41,320
install the feature first.
140
00:04:41,320 --> 00:04:43,760
If a security setting would block an installer,
141
00:04:43,760 --> 00:04:46,320
add the application before applying that setting.
142
00:04:46,320 --> 00:04:49,520
Azure Image Builder runs your customizations in the order you define.
143
00:04:49,520 --> 00:04:52,680
So the image instructions should read like a sensible work list.
144
00:04:52,680 --> 00:04:56,040
And here's where people often try to put everything into one giant script.
145
00:04:56,040 --> 00:04:58,480
That usually becomes hard to test and harder to fix.
146
00:04:58,480 --> 00:05:01,560
Smaller scripts work better because each script has one clear job.
147
00:05:01,560 --> 00:05:03,040
One installs the monitoring agent,
148
00:05:03,040 --> 00:05:04,640
another applies security settings.
149
00:05:04,640 --> 00:05:06,880
A third checks that a required app exists.
150
00:05:06,880 --> 00:05:09,480
When something fails, you can see which part needs attention
151
00:05:09,480 --> 00:05:12,600
without reading through hundreds of lines of unrelated code.
152
00:05:12,600 --> 00:05:15,120
After the setup crew finishes, you need an inspection.
153
00:05:15,120 --> 00:05:16,160
That is validation.
154
00:05:16,160 --> 00:05:18,320
Validation means checking the completed image
155
00:05:18,320 --> 00:05:20,240
before other teams begin using it.
156
00:05:20,240 --> 00:05:22,880
Maybe you test that an application installed successfully,
157
00:05:22,880 --> 00:05:24,680
or you confirm that a server starts.
158
00:05:24,680 --> 00:05:27,680
Perhaps you check that a security setting has the expected value.
159
00:05:27,680 --> 00:05:28,760
The point is simple.
160
00:05:28,760 --> 00:05:32,200
Don't publish an image just because the installation did not report an error.
161
00:05:32,200 --> 00:05:34,880
An installer can finish while the app still fails to open.
162
00:05:34,880 --> 00:05:36,480
An update can require a restart.
163
00:05:36,480 --> 00:05:39,240
A setting can apply differently than you expected.
164
00:05:39,240 --> 00:05:41,400
Validation gives you a place to catch those problems
165
00:05:41,400 --> 00:05:42,840
while you still have one build,
166
00:05:42,840 --> 00:05:46,120
rather than discovering them after many new VMs start from that image.
167
00:05:46,120 --> 00:05:47,600
Picture a new office again.
168
00:05:47,600 --> 00:05:51,000
The furniture is in place, the computers are connected and the doors lock.
169
00:05:51,000 --> 00:05:53,280
Before employees move in, someone checks the lights,
170
00:05:53,280 --> 00:05:55,400
the meeting room screen and the access cards.
171
00:05:55,400 --> 00:05:57,920
That check avoids a poor first day for everyone else.
172
00:05:57,920 --> 00:06:01,080
Once the image passes validation, it needs a home.
173
00:06:01,080 --> 00:06:02,440
That is distribution.
174
00:06:02,440 --> 00:06:04,760
As your image builder can publish the finished image
175
00:06:04,760 --> 00:06:07,280
to as your compute gallery, as a managed image,
176
00:06:07,280 --> 00:06:11,000
or as a VHD file, a VHD is a virtual hard disk file
177
00:06:11,000 --> 00:06:13,840
useful when you need an image file for another supported use.
178
00:06:13,840 --> 00:06:17,040
For most teams building images for regular Azure VM deployments,
179
00:06:17,040 --> 00:06:19,160
as your compute gallery is the usual home,
180
00:06:19,160 --> 00:06:22,800
think of it as the filing room that holds approved office blueprints.
181
00:06:22,800 --> 00:06:25,560
People don't walk in and grab a random sketch from someone's desk.
182
00:06:25,560 --> 00:06:27,720
They use the approved blueprint from the filing room.
183
00:06:27,720 --> 00:06:30,320
A managed image can still work for simpler cases.
184
00:06:30,320 --> 00:06:32,480
But the gallery gives you a more organized place
185
00:06:32,480 --> 00:06:34,560
to keep image families and their releases.
186
00:06:34,560 --> 00:06:36,600
We'll spend more time on that shortly because it changes
187
00:06:36,600 --> 00:06:39,200
how teams share images across regions and workloads.
188
00:06:39,200 --> 00:06:41,080
The last building block is versioning.
189
00:06:41,080 --> 00:06:42,800
Every new build should create a new version.
190
00:06:42,800 --> 00:06:45,360
That sounds small, but it changes how you manage risk.
191
00:06:45,360 --> 00:06:48,000
Suppose your image from April contains Windows updates,
192
00:06:48,000 --> 00:06:51,600
a browser update, and version 4.2 of a company agent.
193
00:06:51,600 --> 00:06:53,640
Your may image includes the next patch set
194
00:06:53,640 --> 00:06:55,560
and version 4.3 of that agent.
195
00:06:55,560 --> 00:06:58,200
With versions, you can tell which release a VM came from
196
00:06:58,200 --> 00:06:59,560
and when it entered use.
197
00:06:59,560 --> 00:07:01,040
You also keep a clear record of change.
198
00:07:01,040 --> 00:07:02,920
If a new app update causes trouble,
199
00:07:02,920 --> 00:07:05,800
you can choose the earlier approved version while you investigate.
200
00:07:05,800 --> 00:07:08,560
Without versions, teams often override the only image they have
201
00:07:08,560 --> 00:07:10,320
then struggle to work out what changed.
202
00:07:10,320 --> 00:07:12,040
So the full process looks like this.
203
00:07:12,040 --> 00:07:14,120
Choose the empty office, send in the setup crew,
204
00:07:14,120 --> 00:07:16,560
inspect the finished space, file the approved blueprint
205
00:07:16,560 --> 00:07:19,280
where people can use it, then label every approved revision.
206
00:07:19,280 --> 00:07:21,240
That's a repeatable image build.
207
00:07:21,240 --> 00:07:24,600
Next, let's follow one image from a clean Microsoft starting point
208
00:07:24,600 --> 00:07:27,600
to a company standard that can be used again and again.
209
00:07:27,600 --> 00:07:29,440
What happens behind the scenes?
210
00:07:29,440 --> 00:07:31,920
So far, we've looked at the parts of an image build.
211
00:07:31,920 --> 00:07:34,800
Now let's look at what Azure actually does when you press build.
212
00:07:34,800 --> 00:07:36,400
Everything starts with an image template.
213
00:07:36,400 --> 00:07:39,360
Think of the template as the instruction sheet for one repeatable job.
214
00:07:39,360 --> 00:07:40,880
It tells Azure where to begin,
215
00:07:40,880 --> 00:07:43,240
what work to do, where the finished image should go,
216
00:07:43,240 --> 00:07:46,000
and who is allowed to access the resources needed along the way.
217
00:07:46,000 --> 00:07:47,600
The template includes the source image,
218
00:07:47,600 --> 00:07:50,840
it also lists the customizations such as power shell scripts for windows
219
00:07:50,840 --> 00:07:52,240
or shell scripts for Linux.
220
00:07:52,240 --> 00:07:54,720
It can include build settings like the location and network
221
00:07:54,720 --> 00:07:56,840
Azure should use while it creates the image.
222
00:07:56,840 --> 00:07:58,160
Then it names the destination,
223
00:07:58,160 --> 00:08:00,720
perhaps an Azure compute gallery image version.
224
00:08:00,720 --> 00:08:02,880
There's also an identity attached to the template.
225
00:08:02,880 --> 00:08:05,360
This part can sound technical, but the idea is simple.
226
00:08:05,360 --> 00:08:08,000
Azure needs permission to do work in your environment.
227
00:08:08,000 --> 00:08:09,800
It needs to read files from storage,
228
00:08:09,800 --> 00:08:11,600
create temporary build resources,
229
00:08:11,600 --> 00:08:13,280
use a network when you provide one,
230
00:08:13,280 --> 00:08:15,840
and write the finished image to its destination.
231
00:08:15,840 --> 00:08:17,760
That identity controls those permissions.
232
00:08:17,760 --> 00:08:21,160
Think of managed identity as the reception desk for the build process.
233
00:08:21,160 --> 00:08:23,640
A person arrives and asks to enter the building,
234
00:08:23,640 --> 00:08:26,600
collect a package, or access a restricted room.
235
00:08:26,600 --> 00:08:29,400
The reception desk checks who they are and what they're allowed to do.
236
00:08:29,400 --> 00:08:32,600
I managed identity does the same job for Azure resources.
237
00:08:32,600 --> 00:08:35,240
Instead of putting a username and password inside your scripts,
238
00:08:35,240 --> 00:08:38,240
you give the managed identity the right access through Azure roles.
239
00:08:38,240 --> 00:08:40,240
It can read the installer files it needs.
240
00:08:40,240 --> 00:08:42,440
It can create the temporary resources for the build,
241
00:08:42,440 --> 00:08:44,480
and it can publish the result to the gallery.
242
00:08:44,480 --> 00:08:46,400
It should only have the access it needs.
243
00:08:46,400 --> 00:08:49,840
That limits the damage if a script is wrong or an account is misused.
244
00:08:49,840 --> 00:08:53,600
The image build doesn't need permission to control every resource in the subscription.
245
00:08:53,600 --> 00:08:56,240
It needs enough permission to complete its assigned work.
246
00:08:56,240 --> 00:08:58,080
After Azure accepts the template,
247
00:08:58,080 --> 00:09:00,480
it creates temporary resources for the build.
248
00:09:00,480 --> 00:09:02,400
One of them is a temporary virtual machine.
249
00:09:02,400 --> 00:09:05,280
This VM is not the server your users will run later.
250
00:09:05,280 --> 00:09:08,000
It is the workshop where Azure prepares the image.
251
00:09:08,000 --> 00:09:11,360
Azure also creates supporting resources such as disks,
252
00:09:11,360 --> 00:09:14,320
network parts, and storage used during the build.
253
00:09:14,320 --> 00:09:17,360
You may see these resources appear in a staging resource group
254
00:09:17,360 --> 00:09:19,120
that can surprise people the first time.
255
00:09:19,120 --> 00:09:22,080
They create one image template, then suddenly see a VM,
256
00:09:22,080 --> 00:09:25,200
a disk, network resources, and a storage account.
257
00:09:25,200 --> 00:09:26,320
Nothing has gone wrong.
258
00:09:26,320 --> 00:09:28,960
Azure needs a real VM to install software, run updates,
259
00:09:28,960 --> 00:09:30,240
and apply your settings.
260
00:09:30,240 --> 00:09:34,320
The temporary VM gives Azure a place to do that work without changing your source image.
261
00:09:34,320 --> 00:09:36,160
Then the instructions begin to run.
262
00:09:36,160 --> 00:09:39,040
Azure runs your scripts in the order you put them in the template.
263
00:09:39,040 --> 00:09:41,680
A first script might install a company browser.
264
00:09:41,680 --> 00:09:43,680
The next one might install the security agent.
265
00:09:43,680 --> 00:09:45,280
Another might run Windows update.
266
00:09:45,280 --> 00:09:48,400
A later script could remove a built-in app your company doesn't want.
267
00:09:48,400 --> 00:09:51,120
Or apply a setting that blocks an older security protocol.
268
00:09:51,120 --> 00:09:52,480
The order is part of the design.
269
00:09:52,480 --> 00:09:56,080
Suppose a security agent needs the latest Windows update before it installs correctly.
270
00:09:56,080 --> 00:09:57,760
Your update script needs to run first.
271
00:09:57,760 --> 00:09:59,920
Or perhaps an installer forces a restart.
272
00:09:59,920 --> 00:10:02,480
Your next script needs to wait until the machine comes back
273
00:10:02,480 --> 00:10:04,320
and confirms the earlier step finished.
274
00:10:04,320 --> 00:10:07,360
This is why image scripts should be predictable and fully automatic.
275
00:10:07,360 --> 00:10:09,600
A script that opens a window and waits for someone to click.
276
00:10:09,600 --> 00:10:11,840
Next can stop the whole build.
277
00:10:11,840 --> 00:10:14,160
The temporary VM has nobody sitting in front of it.
278
00:10:14,160 --> 00:10:16,480
Use silent install options, wait for commands to finish,
279
00:10:16,480 --> 00:10:18,400
and return clear success or failure results.
280
00:10:18,400 --> 00:10:20,000
Picture a simple monthly build.
281
00:10:20,000 --> 00:10:23,040
You begin with the current Windows server source image.
282
00:10:23,040 --> 00:10:25,200
The build installs the month's Windows updates,
283
00:10:25,200 --> 00:10:26,640
updates the approved browser,
284
00:10:26,640 --> 00:10:29,520
and installs or updates the company security agent.
285
00:10:29,520 --> 00:10:32,320
It then applies the company settings that belong on every server.
286
00:10:32,320 --> 00:10:36,320
You build that once after that every new VM created from the image starts
287
00:10:36,320 --> 00:10:37,920
with those changes already in place.
288
00:10:37,920 --> 00:10:40,560
You don't wait for each VM to download the same updates.
289
00:10:40,560 --> 00:10:44,480
You don't repeat the security agent installation 10 times or 100 times.
290
00:10:44,480 --> 00:10:46,960
The preparation happened before the VMs existed.
291
00:10:46,960 --> 00:10:50,720
Once the script's finished, Azure prepares the completed VM to become an image.
292
00:10:50,720 --> 00:10:53,120
For Windows, that process includes generalization,
293
00:10:53,120 --> 00:10:54,400
often called CISPrep.
294
00:10:54,400 --> 00:10:58,080
Generalization removes details that belong to that one temporary machine.
295
00:10:58,080 --> 00:11:01,200
A VM name, machine specific identity and similar local details
296
00:11:01,200 --> 00:11:03,120
should not be copied into every future VM.
297
00:11:03,120 --> 00:11:04,240
You want a clean starting point.
298
00:11:04,240 --> 00:11:08,720
Otherwise, new VMs could arrive with pieces of the temporary build machine still attached.
299
00:11:08,720 --> 00:11:12,240
Generalization lets each new VM form its own identity when it starts.
300
00:11:12,240 --> 00:11:15,040
When that work succeeds, Azure captures the prepared VM
301
00:11:15,040 --> 00:11:18,240
and publishes the finished copy to the destination you selected.
302
00:11:18,240 --> 00:11:21,920
Then the temporary build VM and most supporting resources are removed.
303
00:11:21,920 --> 00:11:24,560
The build workspace disappears because you no longer need it.
304
00:11:24,560 --> 00:11:25,680
The image remains.
305
00:11:25,680 --> 00:11:29,120
Azure also keeps build information you can review, including logs.
306
00:11:29,120 --> 00:11:32,640
If an application installs a fails or a validation step reports a problem,
307
00:11:32,640 --> 00:11:35,520
those logs show where the build stopped and what the script reported
308
00:11:35,520 --> 00:11:38,880
that makes image building easier to investigate than a manual process
309
00:11:38,880 --> 00:11:41,600
where someone only remembers that it worked last month.
310
00:11:41,600 --> 00:11:43,360
So, the template describes the work.
311
00:11:43,360 --> 00:11:45,360
Azure creates a temporary workshop.
312
00:11:45,360 --> 00:11:48,320
The managed identity opens only the doors the build needs.
313
00:11:48,320 --> 00:11:49,840
Scripts prepare the machine,
314
00:11:49,840 --> 00:11:51,280
Azure generalizes it,
315
00:11:51,280 --> 00:11:53,120
and the finished image gets published.
316
00:11:53,120 --> 00:11:56,240
But a finished image only helps when people can find the correct release,
317
00:11:56,240 --> 00:11:59,360
use it in the right Azure region and return to an earlier release
318
00:11:59,360 --> 00:12:00,640
when a newer one causes trouble.
319
00:12:00,640 --> 00:12:04,320
Azure compute gallery, the image library.
320
00:12:04,320 --> 00:12:06,400
So once Azure image builder finishes its work,
321
00:12:06,400 --> 00:12:07,840
you need a place to keep the result.
322
00:12:07,840 --> 00:12:09,920
That places Azure compute gallery.
323
00:12:09,920 --> 00:12:13,200
Now, many people treat it like a storage folder for VM images,
324
00:12:13,200 --> 00:12:14,880
but it's actually much more than that.
325
00:12:14,880 --> 00:12:17,520
Think of it as a company library for approved images,
326
00:12:17,520 --> 00:12:19,600
complete with names, releases, regional copies,
327
00:12:19,600 --> 00:12:22,240
and a clear history of what people should deploy.
328
00:12:22,240 --> 00:12:24,160
Let's talk about the difference between a folder called
329
00:12:24,160 --> 00:12:26,480
Final Images and a proper library system.
330
00:12:26,480 --> 00:12:28,400
In a folder, you might find files named
331
00:12:28,400 --> 00:12:30,800
Final Final 2, Final New and Really Final,
332
00:12:30,800 --> 00:12:32,560
and nobody feels confident choosing one.
333
00:12:32,560 --> 00:12:34,880
A library gives each item a clear label
334
00:12:34,880 --> 00:12:36,560
and keeps different additions together.
335
00:12:36,560 --> 00:12:39,920
An Azure compute gallery works the same way for your VM images.
336
00:12:39,920 --> 00:12:41,600
The first part is the image definition,
337
00:12:41,600 --> 00:12:43,360
which is like the name for an image family.
338
00:12:43,360 --> 00:12:45,200
It describes the type of image you're managing,
339
00:12:45,200 --> 00:12:46,800
not one specific build.
340
00:12:46,800 --> 00:12:49,200
For example, you might create an image definition
341
00:12:49,200 --> 00:12:51,360
called approved Windows 11 desktop,
342
00:12:51,360 --> 00:12:52,880
and that definition tells people
343
00:12:52,880 --> 00:12:54,720
what kind of image they're looking at.
344
00:12:54,720 --> 00:12:56,400
It might describe a Windows 11 image
345
00:12:56,400 --> 00:12:57,760
for Azure Virtual Desktop,
346
00:12:57,760 --> 00:13:00,240
or a Windows Server image for internal application servers.
347
00:13:00,240 --> 00:13:01,040
Here's the thing,
348
00:13:01,040 --> 00:13:02,880
the definition stays in place over time,
349
00:13:02,880 --> 00:13:04,720
even as you release newer builds.
350
00:13:04,720 --> 00:13:06,960
Under that definition, you create image versions,
351
00:13:06,960 --> 00:13:09,360
where each version is one exact release.
352
00:13:09,360 --> 00:13:12,400
Your April build might include that month's Windows updates,
353
00:13:12,400 --> 00:13:13,840
the current browser version,
354
00:13:13,840 --> 00:13:15,040
and the approved company agent,
355
00:13:15,040 --> 00:13:16,640
and that becomes one version.
356
00:13:16,640 --> 00:13:18,320
Your May build becomes another version
357
00:13:18,320 --> 00:13:20,080
under the same image definition,
358
00:13:20,080 --> 00:13:21,680
so the definition is the family name.
359
00:13:21,680 --> 00:13:23,760
The version is the specific copy you deploy.
360
00:13:23,760 --> 00:13:25,200
This separation keeps things clear
361
00:13:25,200 --> 00:13:26,880
when someone asks a simple question,
362
00:13:26,880 --> 00:13:28,480
which image are we using?
363
00:13:28,480 --> 00:13:29,920
You can answer with the image definition
364
00:13:29,920 --> 00:13:32,320
and the exact version, which is much better than saying,
365
00:13:32,320 --> 00:13:33,520
we use the latest one,
366
00:13:33,520 --> 00:13:35,280
especially when a problem appears later.
367
00:13:35,280 --> 00:13:37,840
Now, a gallery also helps when your VMs live
368
00:13:37,840 --> 00:13:39,520
in more than one Azure region.
369
00:13:39,520 --> 00:13:42,160
Imagine your main team deploys VMs in West Europe,
370
00:13:42,160 --> 00:13:45,120
while another team deploys the same standard image in North Europe.
371
00:13:45,120 --> 00:13:46,720
You don't want to wait for a large image
372
00:13:46,720 --> 00:13:48,320
to travel across regions at the moment
373
00:13:48,320 --> 00:13:49,680
you need to build many VMs.
374
00:13:49,680 --> 00:13:52,640
Instead, Azure Compute Gallery can replicate image versions
375
00:13:52,640 --> 00:13:54,560
to the regions where you expect to use them,
376
00:13:54,560 --> 00:13:57,680
meaning Azure places copies of that approved image version
377
00:13:57,680 --> 00:13:59,600
closer to the workloads that need it.
378
00:13:59,600 --> 00:14:01,840
That helps with speed, but it also helps with planning.
379
00:14:01,840 --> 00:14:04,080
If you know a large deployment is coming in another region,
380
00:14:04,080 --> 00:14:06,560
you can make sure the image version already exists there,
381
00:14:06,560 --> 00:14:08,720
so the deployment process can use a local copy
382
00:14:08,720 --> 00:14:10,640
rather than depend on the last minute transfer.
383
00:14:10,640 --> 00:14:12,720
Rapplica Count matters too.
384
00:14:12,720 --> 00:14:14,400
A Rapplica is another available copy
385
00:14:14,400 --> 00:14:16,400
of the image version within a region.
386
00:14:16,400 --> 00:14:18,720
When you deploy many VMs at the same time,
387
00:14:18,720 --> 00:14:21,440
Azure needs enough image capacity to supply them.
388
00:14:21,440 --> 00:14:23,120
A small deployment may need very little,
389
00:14:23,120 --> 00:14:25,200
but a large host pool, a scale-out event,
390
00:14:25,200 --> 00:14:27,600
or a recovery exercise may need more.
391
00:14:27,600 --> 00:14:30,000
So you choose the number of replicas based on
392
00:14:30,000 --> 00:14:32,320
how many VMs you expect to create at once.
393
00:14:32,320 --> 00:14:34,160
This is one of those details people don't notice
394
00:14:34,160 --> 00:14:35,840
until a deployment slows down.
395
00:14:35,840 --> 00:14:37,920
There is another reason image versions matter.
396
00:14:37,920 --> 00:14:38,720
Rollback.
397
00:14:38,720 --> 00:14:41,760
Let's say you publish a new image version with a browser update.
398
00:14:41,760 --> 00:14:43,840
Testing looked fine, but users later find
399
00:14:43,840 --> 00:14:46,240
that a business app no longer works with that browser release
400
00:14:46,240 --> 00:14:48,640
and you don't need to rebuild the old image from memory.
401
00:14:48,640 --> 00:14:50,880
You can select the earlier known good image version
402
00:14:50,880 --> 00:14:53,440
for the next deployment while you investigate the newer one,
403
00:14:53,440 --> 00:14:56,000
giving teams a controlled way back instead of a rushed repair.
404
00:14:56,000 --> 00:15:00,080
A managed image can still be useful for a simple local use case,
405
00:15:00,080 --> 00:15:02,080
but Azure Compute Gallery adds the parts
406
00:15:02,080 --> 00:15:04,560
that become important as usage grows,
407
00:15:04,560 --> 00:15:07,440
image families versions, regional replication,
408
00:15:07,440 --> 00:15:10,080
and wider reuse across teams and deployments.
409
00:15:10,080 --> 00:15:12,960
It turns a finished image into something people can identify,
410
00:15:12,960 --> 00:15:14,640
share, and use with confidence.
411
00:15:14,640 --> 00:15:16,640
The process sounds tidy on paper,
412
00:15:16,640 --> 00:15:19,920
but in real environments the failures usually happen around permissions,
413
00:15:19,920 --> 00:15:23,120
networks, policies, and scripts rather than the image itself,
414
00:15:23,120 --> 00:15:24,880
the parts that usually break.
415
00:15:24,880 --> 00:15:28,560
Most Azure image builder problems don't come from the image idea itself.
416
00:15:28,560 --> 00:15:30,400
They come from the connections around it.
417
00:15:30,400 --> 00:15:32,240
Permissions are usually first on the list.
418
00:15:32,240 --> 00:15:36,800
The managed identity needs permission to create the temporary resources used during the build,
419
00:15:36,800 --> 00:15:39,200
and it also needs permission to read the files it needs
420
00:15:39,200 --> 00:15:42,240
and publish the finished image to the destination you selected.
421
00:15:42,240 --> 00:15:45,040
But don't give it broad access just because of build fails.
422
00:15:45,040 --> 00:15:47,840
Give it the access required for its job and no more.
423
00:15:47,840 --> 00:15:50,240
If it needs to publish to an Azure Compute Gallery,
424
00:15:50,240 --> 00:15:51,520
give it the right access there.
425
00:15:51,520 --> 00:15:54,480
If it needs to read in-stallers from a storage account,
426
00:15:54,480 --> 00:15:56,800
give it read access to that storage location.
427
00:15:56,800 --> 00:16:00,560
A build identity shouldn't become an all-access account for your subscription.
428
00:16:00,560 --> 00:16:02,480
Network access is another common issue.
429
00:16:02,480 --> 00:16:06,160
The temporary build VM needs to reach the things your instructions depend on,
430
00:16:06,160 --> 00:16:08,720
including a script location and application installer,
431
00:16:08,720 --> 00:16:10,960
Windows Update Linux Package Sources,
432
00:16:10,960 --> 00:16:13,360
or Azure Services used during the build.
433
00:16:13,360 --> 00:16:15,840
A script can look perfect on paper and still fail
434
00:16:15,840 --> 00:16:18,400
because the VM cannot reach the download address.
435
00:16:18,400 --> 00:16:20,800
This often appears in locked-down environments.
436
00:16:20,800 --> 00:16:23,760
Your normal company VM may use a proxy, a private route,
437
00:16:23,760 --> 00:16:26,400
or a firewall rule that the build VM doesn't use.
438
00:16:26,400 --> 00:16:28,800
So before you start, ask a simple question.
439
00:16:28,800 --> 00:16:32,880
From the build network, can the temporary VM reach every place this image needs?
440
00:16:32,880 --> 00:16:34,720
Private storage needs a little more thought.
441
00:16:34,720 --> 00:16:38,720
You may keep installers, certificates, and scripts in a private Azure storage account,
442
00:16:38,720 --> 00:16:39,840
which is sensible.
443
00:16:39,840 --> 00:16:42,800
But the build still needs an approved way to reach those files.
444
00:16:42,800 --> 00:16:45,200
Don't solve that by making sensitive files public.
445
00:16:45,200 --> 00:16:47,040
Instead, set up the access path properly.
446
00:16:47,040 --> 00:16:49,520
The managed identity may need permission to read the files,
447
00:16:49,520 --> 00:16:53,280
and your network settings must allow the build VM to reach the storage account.
448
00:16:53,280 --> 00:16:55,120
Private doesn't mean unreachable.
449
00:16:55,120 --> 00:16:58,080
It means only approved identities and networks can get in.
450
00:16:58,080 --> 00:17:01,840
Security settings can also create a mismatch before customization even begins.
451
00:17:01,840 --> 00:17:05,440
For example, a source image may use a certain generation or security type,
452
00:17:05,440 --> 00:17:07,040
such as trusted launch support.
453
00:17:07,040 --> 00:17:11,120
The build setup and destination image settings need to match what that source supports.
454
00:17:11,120 --> 00:17:14,800
If they don't match, Azure can stop before your first script runs.
455
00:17:14,800 --> 00:17:17,760
So check the source image details early, check the image definition,
456
00:17:17,760 --> 00:17:19,440
and check the build VM settings.
457
00:17:19,440 --> 00:17:21,040
A secure source image is still usable,
458
00:17:21,040 --> 00:17:23,520
but the rest of the build needs to follow the same rules.
459
00:17:23,520 --> 00:17:25,760
Then there are the controls outside the template.
460
00:17:25,760 --> 00:17:28,240
Azure Policy can block a temporary disk type,
461
00:17:28,240 --> 00:17:32,160
network setting, or storage choice that as your image builder tries to create.
462
00:17:32,160 --> 00:17:36,400
And as your service provider that hasn't been registered can stop part of the build as well.
463
00:17:36,400 --> 00:17:38,960
This can feel confusing because your template may be correct,
464
00:17:38,960 --> 00:17:42,400
but the service simply can't create one of the resources it needs.
465
00:17:42,400 --> 00:17:44,720
Before spending hours changing scripts,
466
00:17:44,720 --> 00:17:48,080
check policy assignments and confirm the needed Azure resource providers
467
00:17:48,080 --> 00:17:49,760
are registered in the subscription.
468
00:17:49,760 --> 00:17:51,600
Scripts deserve their own discipline.
469
00:17:51,600 --> 00:17:55,040
Test every script on a normal VM before you add it to an image build.
470
00:17:55,040 --> 00:17:57,360
Make sure application installs run silently
471
00:17:57,360 --> 00:17:59,840
and make sure the script waits for installers to finish.
472
00:17:59,840 --> 00:18:02,720
Plan for restarts because updates and agents can require them.
473
00:18:02,720 --> 00:18:03,760
Also check exit codes,
474
00:18:03,760 --> 00:18:07,920
a script that reports success after an installer failed creates a bad image quietly.
475
00:18:07,920 --> 00:18:11,680
Your script should stop and report an error when a required step doesn't complete.
476
00:18:11,680 --> 00:18:14,560
When a build does fail, start with the last run status
477
00:18:14,560 --> 00:18:16,320
that tells you where Azure stopped.
478
00:18:16,320 --> 00:18:20,240
After that, look at the logs in the Packer Logs container in the staging storage account.
479
00:18:20,240 --> 00:18:22,640
Start with the customization log when a script failed
480
00:18:22,640 --> 00:18:25,520
and check the validation log when the build completed its changes
481
00:18:25,520 --> 00:18:26,800
but failed to check afterward.
482
00:18:26,800 --> 00:18:31,360
Those logs turn the image build failed into a specific answer.
483
00:18:31,360 --> 00:18:33,920
Start with one small image, one source image,
484
00:18:33,920 --> 00:18:36,240
one or two scripts and one output location.
485
00:18:36,880 --> 00:18:41,120
Prove that process first then let image updates become part of normal operations
486
00:18:41,120 --> 00:18:43,520
rather than an emergency project each month.
487
00:18:43,520 --> 00:18:45,600
A simple first image builder plan.
488
00:18:45,600 --> 00:18:49,040
So what's the simplest way to get started with Azure image builder?
489
00:18:49,040 --> 00:18:50,240
Think of it like a recipe.
490
00:18:50,240 --> 00:18:53,200
Start with one common VM type, one approved base image
491
00:18:53,200 --> 00:18:55,680
and a short list of changes you repeat every time.
492
00:18:55,680 --> 00:18:57,280
Keep that first template small.
493
00:18:57,280 --> 00:18:59,520
Just a source image, your customizations,
494
00:18:59,520 --> 00:19:01,840
one validation check as your compute gallery
495
00:19:01,840 --> 00:19:04,080
as the destination and a clear version number.
496
00:19:04,080 --> 00:19:06,560
Store your installers and scripts in a controlled location
497
00:19:06,560 --> 00:19:09,280
and use managed identity to read them when it makes sense.
498
00:19:09,280 --> 00:19:11,440
Managed identity is like a secure badge.
499
00:19:11,440 --> 00:19:13,680
It lets your scripts access resources
500
00:19:13,680 --> 00:19:15,360
without hard coding passwords.
501
00:19:15,360 --> 00:19:17,440
Choose a family name that makes sense to your team
502
00:19:17,440 --> 00:19:18,960
like Windows 11 standard
503
00:19:18,960 --> 00:19:22,160
and use a simple version pattern like 2026.07.
504
00:19:22,160 --> 00:19:23,760
One, before you go to production,
505
00:19:23,760 --> 00:19:26,160
create one test VM from that new version
506
00:19:26,160 --> 00:19:30,000
and check the app, agent updates and settings in a real environment.
507
00:19:30,000 --> 00:19:33,440
Once that works, put the build into Azure DevOps or another pipeline.
508
00:19:33,440 --> 00:19:35,120
Run it regularly for monthly patches
509
00:19:35,120 --> 00:19:38,240
and run it again whenever an urgent security update arrives.
510
00:19:38,240 --> 00:19:40,240
Bake the stable foundations into the image
511
00:19:40,240 --> 00:19:43,440
but deliver fast changing apps separately when that makes more sense.
512
00:19:43,440 --> 00:19:46,960
A repeatable image process doesn't just change how you build VMs.
513
00:19:46,960 --> 00:19:48,320
It changes your whole approach.
514
00:19:48,320 --> 00:19:50,960
So how do you put this process to work?
515
00:19:50,960 --> 00:19:53,760
Azure Image Builder replaces those hand-built golden images
516
00:19:53,760 --> 00:19:55,520
with a repeatable Azure process.
517
00:19:55,520 --> 00:19:56,720
Your next task is simple.
518
00:19:56,720 --> 00:19:58,640
List every app, setting, update,
519
00:19:58,640 --> 00:20:01,120
and check your team repeats when preparing a VM.
520
00:20:01,120 --> 00:20:02,560
Then choose one base image,
521
00:20:02,560 --> 00:20:04,960
publish one tested version to Azure Compute Gallery
522
00:20:04,960 --> 00:20:06,880
and start learning how Compute Gallery
523
00:20:06,880 --> 00:20:10,480
managed identities and image update pipelines all fit together.
00:00:00,000 --> 00:00:02,860
So let's say your company needs a standard Windows server image.
2
00:00:02,860 --> 00:00:05,320
The old way usually starts with a fresh virtual machine.
3
00:00:05,320 --> 00:00:07,160
You install Windows updates.
4
00:00:07,160 --> 00:00:08,480
You add the apps people expect.
5
00:00:08,480 --> 00:00:11,000
You drop in a monitoring agent, tweak a few settings,
6
00:00:11,000 --> 00:00:13,560
apply security rules, test everything, run CISPRIP,
7
00:00:13,560 --> 00:00:15,280
and then capture the machine as an image.
8
00:00:15,280 --> 00:00:16,400
That can work.
9
00:00:16,400 --> 00:00:19,440
But it depends on someone remembering every single step.
10
00:00:19,440 --> 00:00:21,560
A month later, new Windows updates show up.
11
00:00:21,560 --> 00:00:22,920
A team asks for a different app.
12
00:00:22,920 --> 00:00:25,880
Security wants one registry setting changed.
13
00:00:25,880 --> 00:00:28,360
So somebody starts over, often from a set of notes
14
00:00:28,360 --> 00:00:30,880
that might be outdated, a script that only half works,
15
00:00:30,880 --> 00:00:33,040
and a few steps that live in one admin's head.
16
00:00:33,040 --> 00:00:34,240
You know how this ends?
17
00:00:34,240 --> 00:00:36,440
Two images with the same name can have different apps,
18
00:00:36,440 --> 00:00:38,320
different patches, and different settings.
19
00:00:38,320 --> 00:00:40,360
One person tests before capturing another
20
00:00:40,360 --> 00:00:42,120
skips a step because the deadline is tight.
21
00:00:42,120 --> 00:00:43,160
That's not a people problem.
22
00:00:43,160 --> 00:00:44,240
It's a process problem.
23
00:00:44,240 --> 00:00:47,240
I'm Mirko Peters from M365FM, and this knowledge nugget
24
00:00:47,240 --> 00:00:48,800
is about turning that hand-built routine
25
00:00:48,800 --> 00:00:50,480
into a repeatable Azure process.
26
00:00:50,480 --> 00:00:52,960
By the end, you'll know what Azure Image Builder does,
27
00:00:52,960 --> 00:00:55,120
what it doesn't do, and why it helps you create
28
00:00:55,120 --> 00:00:57,120
the same approved starting point every time.
29
00:00:57,120 --> 00:00:59,240
So what exactly is Azure Image Builder?
30
00:00:59,240 --> 00:01:01,480
What Azure Image Builder actually is?
31
00:01:01,480 --> 00:01:03,240
Azure Image Builder is an Azure service
32
00:01:03,240 --> 00:01:05,280
that creates customized virtual machine images
33
00:01:05,280 --> 00:01:07,160
from a set of instructions you define.
34
00:01:07,160 --> 00:01:09,320
That's the plain English definition.
35
00:01:09,320 --> 00:01:12,120
Think about a company laptop that IT has already prepped.
36
00:01:12,120 --> 00:01:14,520
It has Windows installed, the right security setting
37
00:01:14,520 --> 00:01:16,600
supplied, the approved tools added,
38
00:01:16,600 --> 00:01:18,560
and the unwanted software removed.
39
00:01:18,560 --> 00:01:20,360
Instead of preparing every laptop by hand,
40
00:01:20,360 --> 00:01:23,040
you create one master copy you can use again and again.
41
00:01:23,040 --> 00:01:24,840
A virtual machine image works the same way.
42
00:01:24,840 --> 00:01:27,920
It's a prepared starting copy for new virtual machines.
43
00:01:27,920 --> 00:01:30,080
You can start with a clean Windows or Linux image
44
00:01:30,080 --> 00:01:31,520
from Azure Marketplace.
45
00:01:31,520 --> 00:01:34,280
That might be Windows Server, Windows 11, Ubuntu,
46
00:01:34,280 --> 00:01:36,600
or another supported operating system.
47
00:01:36,600 --> 00:01:39,440
You can also begin with an image your company already created
48
00:01:39,440 --> 00:01:42,320
like a managed image or one stored in Azure Compute Gallery.
49
00:01:42,320 --> 00:01:43,920
So you don't always start from zero.
50
00:01:43,920 --> 00:01:46,640
Maybe your organization already has a secure Windows Server
51
00:01:46,640 --> 00:01:47,720
based image.
52
00:01:47,720 --> 00:01:49,880
Azure Image Builder can begin there,
53
00:01:49,880 --> 00:01:51,800
apply the next set of approved changes,
54
00:01:51,800 --> 00:01:53,120
and create a newer version.
55
00:01:53,120 --> 00:01:56,240
Or maybe you start with Microsoft's latest Windows 11 image
56
00:01:56,240 --> 00:01:58,640
and add your company's standard tools and settings.
57
00:01:58,640 --> 00:02:00,720
Either way, the idea stays simple.
58
00:02:00,720 --> 00:02:01,880
You start with a known source.
59
00:02:01,880 --> 00:02:03,480
You define what should change.
60
00:02:03,480 --> 00:02:04,960
Azure creates a new image.
61
00:02:04,960 --> 00:02:06,720
Now many people hear the word builder
62
00:02:06,720 --> 00:02:09,920
and assume it creates virtual machines for users or applications.
63
00:02:09,920 --> 00:02:10,920
It doesn't work that way.
64
00:02:10,920 --> 00:02:13,320
Azure Image Builder creates the image first.
65
00:02:13,320 --> 00:02:15,280
Later you create 1vm, 10vm,
66
00:02:15,280 --> 00:02:17,800
or a much larger group from that finished image.
67
00:02:17,800 --> 00:02:20,080
So it belongs earlier in the process,
68
00:02:20,080 --> 00:02:21,560
like preparing the master copy
69
00:02:21,560 --> 00:02:23,600
before anyone starts handing out copies.
70
00:02:23,600 --> 00:02:25,600
That distinction saves a lot of confusion.
71
00:02:25,600 --> 00:02:26,960
Azure Image Builder also uses
72
00:02:26,960 --> 00:02:28,760
HashieCork Packer behind the scenes.
73
00:02:28,760 --> 00:02:31,160
Packer is a tool that automates image creation,
74
00:02:31,160 --> 00:02:33,840
but Azure Image Builder puts an Azure managed layer
75
00:02:33,840 --> 00:02:34,920
around that work.
76
00:02:34,920 --> 00:02:37,400
You don't need to run and maintain your own Packer Server
77
00:02:37,400 --> 00:02:38,680
just to use the service.
78
00:02:38,680 --> 00:02:41,080
As your handles, most of the temporary build work,
79
00:02:41,080 --> 00:02:43,280
while you focus on the instructions for your image,
80
00:02:43,280 --> 00:02:45,200
you still need to define what you want.
81
00:02:45,200 --> 00:02:46,960
For example, you might want an image
82
00:02:46,960 --> 00:02:48,240
with current Windows updates,
83
00:02:48,240 --> 00:02:50,800
a browser, a monitoring agent, a security agent,
84
00:02:50,800 --> 00:02:52,080
and a few company settings.
85
00:02:52,080 --> 00:02:54,680
Instead of logging in and doing that work by hand every month,
86
00:02:54,680 --> 00:02:56,600
you write down those requirements once
87
00:02:56,600 --> 00:02:57,880
as part of the image build.
88
00:02:57,880 --> 00:03:00,560
Then the same instructions run again on the next build.
89
00:03:00,560 --> 00:03:03,080
That means every new vm starts with the same apps,
90
00:03:03,080 --> 00:03:04,520
the same patches, the same settings,
91
00:03:04,520 --> 00:03:06,440
and the same security baseline.
92
00:03:06,440 --> 00:03:07,440
If something needs to change,
93
00:03:07,440 --> 00:03:09,680
you update the instructions and build a new image.
94
00:03:09,680 --> 00:03:12,040
Instead of hoping every administrator follows the same list,
95
00:03:12,040 --> 00:03:13,800
that's the real reason to automate images.
96
00:03:13,800 --> 00:03:15,640
You're not just saving time during setup.
97
00:03:15,640 --> 00:03:17,640
You're replacing memory and manual work
98
00:03:17,640 --> 00:03:19,440
with a process you can repeat.
99
00:03:19,440 --> 00:03:23,080
The definition helps, but the next part makes the whole service easier to see.
100
00:03:23,080 --> 00:03:25,280
An image build has a few simple building blocks,
101
00:03:25,280 --> 00:03:27,280
and each one has a clear job.
102
00:03:27,280 --> 00:03:29,440
The five building blocks of an image build,
103
00:03:29,440 --> 00:03:31,680
let's picture the image build as preparing a new office
104
00:03:31,680 --> 00:03:33,040
before a team moves in.
105
00:03:33,040 --> 00:03:34,760
First, you need the empty office.
106
00:03:34,760 --> 00:03:35,960
That's your source image.
107
00:03:35,960 --> 00:03:37,520
The source is the clean starting point
108
00:03:37,520 --> 00:03:39,480
as your image builder uses for the build.
109
00:03:39,480 --> 00:03:41,720
Maybe it's Windows Server for an application server.
110
00:03:41,720 --> 00:03:43,880
Maybe it's Windows 11 for a desktop environment,
111
00:03:43,880 --> 00:03:46,000
or maybe it's Ubuntu for Linux Workload.
112
00:03:46,000 --> 00:03:47,480
You choose the source based on the job
113
00:03:47,480 --> 00:03:49,000
the future vm's need to do.
114
00:03:49,000 --> 00:03:51,640
For example, a web server team might start with Ubuntu.
115
00:03:51,640 --> 00:03:54,520
A finance application that usually needs Windows Server.
116
00:03:54,520 --> 00:03:56,360
And an Azure Virtual Desktop team
117
00:03:56,360 --> 00:03:58,200
will likely choose Windows 11.
118
00:03:58,200 --> 00:04:00,000
The source gives you the operating system,
119
00:04:00,000 --> 00:04:02,360
but it doesn't yet contain your company's setup.
120
00:04:02,360 --> 00:04:05,080
Think of it as an empty office with the walls, doors, power,
121
00:04:05,080 --> 00:04:06,880
and network already in place.
122
00:04:06,880 --> 00:04:08,760
The next building block is customization.
123
00:04:08,760 --> 00:04:10,280
This is where the setup crew comes in.
124
00:04:10,280 --> 00:04:12,440
You give Azure Image Builder scripts and instructions
125
00:04:12,440 --> 00:04:15,120
that describe what belongs in the office before people arrive.
126
00:04:15,120 --> 00:04:16,800
A script can install an application.
127
00:04:16,800 --> 00:04:18,320
Another can apply Windows updates.
128
00:04:18,320 --> 00:04:21,600
One might add a language pack for users in a certain country.
129
00:04:21,600 --> 00:04:23,400
You can also install a monitoring agent
130
00:04:23,400 --> 00:04:26,080
so your operations team can see whether the vm is healthy.
131
00:04:26,080 --> 00:04:28,400
You might add a security agent that checks for threats,
132
00:04:28,400 --> 00:04:30,160
or you might apply security settings,
133
00:04:30,160 --> 00:04:31,720
such as turning off an old protocol,
134
00:04:31,720 --> 00:04:33,200
setting a company time zone,
135
00:04:33,200 --> 00:04:34,800
removing unwanted software,
136
00:04:34,800 --> 00:04:36,600
or adding a required certificate.
137
00:04:36,600 --> 00:04:37,680
The order matters.
138
00:04:37,680 --> 00:04:39,840
If an application needs a certain Windows feature,
139
00:04:39,840 --> 00:04:41,320
install the feature first.
140
00:04:41,320 --> 00:04:43,760
If a security setting would block an installer,
141
00:04:43,760 --> 00:04:46,320
add the application before applying that setting.
142
00:04:46,320 --> 00:04:49,520
Azure Image Builder runs your customizations in the order you define.
143
00:04:49,520 --> 00:04:52,680
So the image instructions should read like a sensible work list.
144
00:04:52,680 --> 00:04:56,040
And here's where people often try to put everything into one giant script.
145
00:04:56,040 --> 00:04:58,480
That usually becomes hard to test and harder to fix.
146
00:04:58,480 --> 00:05:01,560
Smaller scripts work better because each script has one clear job.
147
00:05:01,560 --> 00:05:03,040
One installs the monitoring agent,
148
00:05:03,040 --> 00:05:04,640
another applies security settings.
149
00:05:04,640 --> 00:05:06,880
A third checks that a required app exists.
150
00:05:06,880 --> 00:05:09,480
When something fails, you can see which part needs attention
151
00:05:09,480 --> 00:05:12,600
without reading through hundreds of lines of unrelated code.
152
00:05:12,600 --> 00:05:15,120
After the setup crew finishes, you need an inspection.
153
00:05:15,120 --> 00:05:16,160
That is validation.
154
00:05:16,160 --> 00:05:18,320
Validation means checking the completed image
155
00:05:18,320 --> 00:05:20,240
before other teams begin using it.
156
00:05:20,240 --> 00:05:22,880
Maybe you test that an application installed successfully,
157
00:05:22,880 --> 00:05:24,680
or you confirm that a server starts.
158
00:05:24,680 --> 00:05:27,680
Perhaps you check that a security setting has the expected value.
159
00:05:27,680 --> 00:05:28,760
The point is simple.
160
00:05:28,760 --> 00:05:32,200
Don't publish an image just because the installation did not report an error.
161
00:05:32,200 --> 00:05:34,880
An installer can finish while the app still fails to open.
162
00:05:34,880 --> 00:05:36,480
An update can require a restart.
163
00:05:36,480 --> 00:05:39,240
A setting can apply differently than you expected.
164
00:05:39,240 --> 00:05:41,400
Validation gives you a place to catch those problems
165
00:05:41,400 --> 00:05:42,840
while you still have one build,
166
00:05:42,840 --> 00:05:46,120
rather than discovering them after many new VMs start from that image.
167
00:05:46,120 --> 00:05:47,600
Picture a new office again.
168
00:05:47,600 --> 00:05:51,000
The furniture is in place, the computers are connected and the doors lock.
169
00:05:51,000 --> 00:05:53,280
Before employees move in, someone checks the lights,
170
00:05:53,280 --> 00:05:55,400
the meeting room screen and the access cards.
171
00:05:55,400 --> 00:05:57,920
That check avoids a poor first day for everyone else.
172
00:05:57,920 --> 00:06:01,080
Once the image passes validation, it needs a home.
173
00:06:01,080 --> 00:06:02,440
That is distribution.
174
00:06:02,440 --> 00:06:04,760
As your image builder can publish the finished image
175
00:06:04,760 --> 00:06:07,280
to as your compute gallery, as a managed image,
176
00:06:07,280 --> 00:06:11,000
or as a VHD file, a VHD is a virtual hard disk file
177
00:06:11,000 --> 00:06:13,840
useful when you need an image file for another supported use.
178
00:06:13,840 --> 00:06:17,040
For most teams building images for regular Azure VM deployments,
179
00:06:17,040 --> 00:06:19,160
as your compute gallery is the usual home,
180
00:06:19,160 --> 00:06:22,800
think of it as the filing room that holds approved office blueprints.
181
00:06:22,800 --> 00:06:25,560
People don't walk in and grab a random sketch from someone's desk.
182
00:06:25,560 --> 00:06:27,720
They use the approved blueprint from the filing room.
183
00:06:27,720 --> 00:06:30,320
A managed image can still work for simpler cases.
184
00:06:30,320 --> 00:06:32,480
But the gallery gives you a more organized place
185
00:06:32,480 --> 00:06:34,560
to keep image families and their releases.
186
00:06:34,560 --> 00:06:36,600
We'll spend more time on that shortly because it changes
187
00:06:36,600 --> 00:06:39,200
how teams share images across regions and workloads.
188
00:06:39,200 --> 00:06:41,080
The last building block is versioning.
189
00:06:41,080 --> 00:06:42,800
Every new build should create a new version.
190
00:06:42,800 --> 00:06:45,360
That sounds small, but it changes how you manage risk.
191
00:06:45,360 --> 00:06:48,000
Suppose your image from April contains Windows updates,
192
00:06:48,000 --> 00:06:51,600
a browser update, and version 4.2 of a company agent.
193
00:06:51,600 --> 00:06:53,640
Your may image includes the next patch set
194
00:06:53,640 --> 00:06:55,560
and version 4.3 of that agent.
195
00:06:55,560 --> 00:06:58,200
With versions, you can tell which release a VM came from
196
00:06:58,200 --> 00:06:59,560
and when it entered use.
197
00:06:59,560 --> 00:07:01,040
You also keep a clear record of change.
198
00:07:01,040 --> 00:07:02,920
If a new app update causes trouble,
199
00:07:02,920 --> 00:07:05,800
you can choose the earlier approved version while you investigate.
200
00:07:05,800 --> 00:07:08,560
Without versions, teams often override the only image they have
201
00:07:08,560 --> 00:07:10,320
then struggle to work out what changed.
202
00:07:10,320 --> 00:07:12,040
So the full process looks like this.
203
00:07:12,040 --> 00:07:14,120
Choose the empty office, send in the setup crew,
204
00:07:14,120 --> 00:07:16,560
inspect the finished space, file the approved blueprint
205
00:07:16,560 --> 00:07:19,280
where people can use it, then label every approved revision.
206
00:07:19,280 --> 00:07:21,240
That's a repeatable image build.
207
00:07:21,240 --> 00:07:24,600
Next, let's follow one image from a clean Microsoft starting point
208
00:07:24,600 --> 00:07:27,600
to a company standard that can be used again and again.
209
00:07:27,600 --> 00:07:29,440
What happens behind the scenes?
210
00:07:29,440 --> 00:07:31,920
So far, we've looked at the parts of an image build.
211
00:07:31,920 --> 00:07:34,800
Now let's look at what Azure actually does when you press build.
212
00:07:34,800 --> 00:07:36,400
Everything starts with an image template.
213
00:07:36,400 --> 00:07:39,360
Think of the template as the instruction sheet for one repeatable job.
214
00:07:39,360 --> 00:07:40,880
It tells Azure where to begin,
215
00:07:40,880 --> 00:07:43,240
what work to do, where the finished image should go,
216
00:07:43,240 --> 00:07:46,000
and who is allowed to access the resources needed along the way.
217
00:07:46,000 --> 00:07:47,600
The template includes the source image,
218
00:07:47,600 --> 00:07:50,840
it also lists the customizations such as power shell scripts for windows
219
00:07:50,840 --> 00:07:52,240
or shell scripts for Linux.
220
00:07:52,240 --> 00:07:54,720
It can include build settings like the location and network
221
00:07:54,720 --> 00:07:56,840
Azure should use while it creates the image.
222
00:07:56,840 --> 00:07:58,160
Then it names the destination,
223
00:07:58,160 --> 00:08:00,720
perhaps an Azure compute gallery image version.
224
00:08:00,720 --> 00:08:02,880
There's also an identity attached to the template.
225
00:08:02,880 --> 00:08:05,360
This part can sound technical, but the idea is simple.
226
00:08:05,360 --> 00:08:08,000
Azure needs permission to do work in your environment.
227
00:08:08,000 --> 00:08:09,800
It needs to read files from storage,
228
00:08:09,800 --> 00:08:11,600
create temporary build resources,
229
00:08:11,600 --> 00:08:13,280
use a network when you provide one,
230
00:08:13,280 --> 00:08:15,840
and write the finished image to its destination.
231
00:08:15,840 --> 00:08:17,760
That identity controls those permissions.
232
00:08:17,760 --> 00:08:21,160
Think of managed identity as the reception desk for the build process.
233
00:08:21,160 --> 00:08:23,640
A person arrives and asks to enter the building,
234
00:08:23,640 --> 00:08:26,600
collect a package, or access a restricted room.
235
00:08:26,600 --> 00:08:29,400
The reception desk checks who they are and what they're allowed to do.
236
00:08:29,400 --> 00:08:32,600
I managed identity does the same job for Azure resources.
237
00:08:32,600 --> 00:08:35,240
Instead of putting a username and password inside your scripts,
238
00:08:35,240 --> 00:08:38,240
you give the managed identity the right access through Azure roles.
239
00:08:38,240 --> 00:08:40,240
It can read the installer files it needs.
240
00:08:40,240 --> 00:08:42,440
It can create the temporary resources for the build,
241
00:08:42,440 --> 00:08:44,480
and it can publish the result to the gallery.
242
00:08:44,480 --> 00:08:46,400
It should only have the access it needs.
243
00:08:46,400 --> 00:08:49,840
That limits the damage if a script is wrong or an account is misused.
244
00:08:49,840 --> 00:08:53,600
The image build doesn't need permission to control every resource in the subscription.
245
00:08:53,600 --> 00:08:56,240
It needs enough permission to complete its assigned work.
246
00:08:56,240 --> 00:08:58,080
After Azure accepts the template,
247
00:08:58,080 --> 00:09:00,480
it creates temporary resources for the build.
248
00:09:00,480 --> 00:09:02,400
One of them is a temporary virtual machine.
249
00:09:02,400 --> 00:09:05,280
This VM is not the server your users will run later.
250
00:09:05,280 --> 00:09:08,000
It is the workshop where Azure prepares the image.
251
00:09:08,000 --> 00:09:11,360
Azure also creates supporting resources such as disks,
252
00:09:11,360 --> 00:09:14,320
network parts, and storage used during the build.
253
00:09:14,320 --> 00:09:17,360
You may see these resources appear in a staging resource group
254
00:09:17,360 --> 00:09:19,120
that can surprise people the first time.
255
00:09:19,120 --> 00:09:22,080
They create one image template, then suddenly see a VM,
256
00:09:22,080 --> 00:09:25,200
a disk, network resources, and a storage account.
257
00:09:25,200 --> 00:09:26,320
Nothing has gone wrong.
258
00:09:26,320 --> 00:09:28,960
Azure needs a real VM to install software, run updates,
259
00:09:28,960 --> 00:09:30,240
and apply your settings.
260
00:09:30,240 --> 00:09:34,320
The temporary VM gives Azure a place to do that work without changing your source image.
261
00:09:34,320 --> 00:09:36,160
Then the instructions begin to run.
262
00:09:36,160 --> 00:09:39,040
Azure runs your scripts in the order you put them in the template.
263
00:09:39,040 --> 00:09:41,680
A first script might install a company browser.
264
00:09:41,680 --> 00:09:43,680
The next one might install the security agent.
265
00:09:43,680 --> 00:09:45,280
Another might run Windows update.
266
00:09:45,280 --> 00:09:48,400
A later script could remove a built-in app your company doesn't want.
267
00:09:48,400 --> 00:09:51,120
Or apply a setting that blocks an older security protocol.
268
00:09:51,120 --> 00:09:52,480
The order is part of the design.
269
00:09:52,480 --> 00:09:56,080
Suppose a security agent needs the latest Windows update before it installs correctly.
270
00:09:56,080 --> 00:09:57,760
Your update script needs to run first.
271
00:09:57,760 --> 00:09:59,920
Or perhaps an installer forces a restart.
272
00:09:59,920 --> 00:10:02,480
Your next script needs to wait until the machine comes back
273
00:10:02,480 --> 00:10:04,320
and confirms the earlier step finished.
274
00:10:04,320 --> 00:10:07,360
This is why image scripts should be predictable and fully automatic.
275
00:10:07,360 --> 00:10:09,600
A script that opens a window and waits for someone to click.
276
00:10:09,600 --> 00:10:11,840
Next can stop the whole build.
277
00:10:11,840 --> 00:10:14,160
The temporary VM has nobody sitting in front of it.
278
00:10:14,160 --> 00:10:16,480
Use silent install options, wait for commands to finish,
279
00:10:16,480 --> 00:10:18,400
and return clear success or failure results.
280
00:10:18,400 --> 00:10:20,000
Picture a simple monthly build.
281
00:10:20,000 --> 00:10:23,040
You begin with the current Windows server source image.
282
00:10:23,040 --> 00:10:25,200
The build installs the month's Windows updates,
283
00:10:25,200 --> 00:10:26,640
updates the approved browser,
284
00:10:26,640 --> 00:10:29,520
and installs or updates the company security agent.
285
00:10:29,520 --> 00:10:32,320
It then applies the company settings that belong on every server.
286
00:10:32,320 --> 00:10:36,320
You build that once after that every new VM created from the image starts
287
00:10:36,320 --> 00:10:37,920
with those changes already in place.
288
00:10:37,920 --> 00:10:40,560
You don't wait for each VM to download the same updates.
289
00:10:40,560 --> 00:10:44,480
You don't repeat the security agent installation 10 times or 100 times.
290
00:10:44,480 --> 00:10:46,960
The preparation happened before the VMs existed.
291
00:10:46,960 --> 00:10:50,720
Once the script's finished, Azure prepares the completed VM to become an image.
292
00:10:50,720 --> 00:10:53,120
For Windows, that process includes generalization,
293
00:10:53,120 --> 00:10:54,400
often called CISPrep.
294
00:10:54,400 --> 00:10:58,080
Generalization removes details that belong to that one temporary machine.
295
00:10:58,080 --> 00:11:01,200
A VM name, machine specific identity and similar local details
296
00:11:01,200 --> 00:11:03,120
should not be copied into every future VM.
297
00:11:03,120 --> 00:11:04,240
You want a clean starting point.
298
00:11:04,240 --> 00:11:08,720
Otherwise, new VMs could arrive with pieces of the temporary build machine still attached.
299
00:11:08,720 --> 00:11:12,240
Generalization lets each new VM form its own identity when it starts.
300
00:11:12,240 --> 00:11:15,040
When that work succeeds, Azure captures the prepared VM
301
00:11:15,040 --> 00:11:18,240
and publishes the finished copy to the destination you selected.
302
00:11:18,240 --> 00:11:21,920
Then the temporary build VM and most supporting resources are removed.
303
00:11:21,920 --> 00:11:24,560
The build workspace disappears because you no longer need it.
304
00:11:24,560 --> 00:11:25,680
The image remains.
305
00:11:25,680 --> 00:11:29,120
Azure also keeps build information you can review, including logs.
306
00:11:29,120 --> 00:11:32,640
If an application installs a fails or a validation step reports a problem,
307
00:11:32,640 --> 00:11:35,520
those logs show where the build stopped and what the script reported
308
00:11:35,520 --> 00:11:38,880
that makes image building easier to investigate than a manual process
309
00:11:38,880 --> 00:11:41,600
where someone only remembers that it worked last month.
310
00:11:41,600 --> 00:11:43,360
So, the template describes the work.
311
00:11:43,360 --> 00:11:45,360
Azure creates a temporary workshop.
312
00:11:45,360 --> 00:11:48,320
The managed identity opens only the doors the build needs.
313
00:11:48,320 --> 00:11:49,840
Scripts prepare the machine,
314
00:11:49,840 --> 00:11:51,280
Azure generalizes it,
315
00:11:51,280 --> 00:11:53,120
and the finished image gets published.
316
00:11:53,120 --> 00:11:56,240
But a finished image only helps when people can find the correct release,
317
00:11:56,240 --> 00:11:59,360
use it in the right Azure region and return to an earlier release
318
00:11:59,360 --> 00:12:00,640
when a newer one causes trouble.
319
00:12:00,640 --> 00:12:04,320
Azure compute gallery, the image library.
320
00:12:04,320 --> 00:12:06,400
So once Azure image builder finishes its work,
321
00:12:06,400 --> 00:12:07,840
you need a place to keep the result.
322
00:12:07,840 --> 00:12:09,920
That places Azure compute gallery.
323
00:12:09,920 --> 00:12:13,200
Now, many people treat it like a storage folder for VM images,
324
00:12:13,200 --> 00:12:14,880
but it's actually much more than that.
325
00:12:14,880 --> 00:12:17,520
Think of it as a company library for approved images,
326
00:12:17,520 --> 00:12:19,600
complete with names, releases, regional copies,
327
00:12:19,600 --> 00:12:22,240
and a clear history of what people should deploy.
328
00:12:22,240 --> 00:12:24,160
Let's talk about the difference between a folder called
329
00:12:24,160 --> 00:12:26,480
Final Images and a proper library system.
330
00:12:26,480 --> 00:12:28,400
In a folder, you might find files named
331
00:12:28,400 --> 00:12:30,800
Final Final 2, Final New and Really Final,
332
00:12:30,800 --> 00:12:32,560
and nobody feels confident choosing one.
333
00:12:32,560 --> 00:12:34,880
A library gives each item a clear label
334
00:12:34,880 --> 00:12:36,560
and keeps different additions together.
335
00:12:36,560 --> 00:12:39,920
An Azure compute gallery works the same way for your VM images.
336
00:12:39,920 --> 00:12:41,600
The first part is the image definition,
337
00:12:41,600 --> 00:12:43,360
which is like the name for an image family.
338
00:12:43,360 --> 00:12:45,200
It describes the type of image you're managing,
339
00:12:45,200 --> 00:12:46,800
not one specific build.
340
00:12:46,800 --> 00:12:49,200
For example, you might create an image definition
341
00:12:49,200 --> 00:12:51,360
called approved Windows 11 desktop,
342
00:12:51,360 --> 00:12:52,880
and that definition tells people
343
00:12:52,880 --> 00:12:54,720
what kind of image they're looking at.
344
00:12:54,720 --> 00:12:56,400
It might describe a Windows 11 image
345
00:12:56,400 --> 00:12:57,760
for Azure Virtual Desktop,
346
00:12:57,760 --> 00:13:00,240
or a Windows Server image for internal application servers.
347
00:13:00,240 --> 00:13:01,040
Here's the thing,
348
00:13:01,040 --> 00:13:02,880
the definition stays in place over time,
349
00:13:02,880 --> 00:13:04,720
even as you release newer builds.
350
00:13:04,720 --> 00:13:06,960
Under that definition, you create image versions,
351
00:13:06,960 --> 00:13:09,360
where each version is one exact release.
352
00:13:09,360 --> 00:13:12,400
Your April build might include that month's Windows updates,
353
00:13:12,400 --> 00:13:13,840
the current browser version,
354
00:13:13,840 --> 00:13:15,040
and the approved company agent,
355
00:13:15,040 --> 00:13:16,640
and that becomes one version.
356
00:13:16,640 --> 00:13:18,320
Your May build becomes another version
357
00:13:18,320 --> 00:13:20,080
under the same image definition,
358
00:13:20,080 --> 00:13:21,680
so the definition is the family name.
359
00:13:21,680 --> 00:13:23,760
The version is the specific copy you deploy.
360
00:13:23,760 --> 00:13:25,200
This separation keeps things clear
361
00:13:25,200 --> 00:13:26,880
when someone asks a simple question,
362
00:13:26,880 --> 00:13:28,480
which image are we using?
363
00:13:28,480 --> 00:13:29,920
You can answer with the image definition
364
00:13:29,920 --> 00:13:32,320
and the exact version, which is much better than saying,
365
00:13:32,320 --> 00:13:33,520
we use the latest one,
366
00:13:33,520 --> 00:13:35,280
especially when a problem appears later.
367
00:13:35,280 --> 00:13:37,840
Now, a gallery also helps when your VMs live
368
00:13:37,840 --> 00:13:39,520
in more than one Azure region.
369
00:13:39,520 --> 00:13:42,160
Imagine your main team deploys VMs in West Europe,
370
00:13:42,160 --> 00:13:45,120
while another team deploys the same standard image in North Europe.
371
00:13:45,120 --> 00:13:46,720
You don't want to wait for a large image
372
00:13:46,720 --> 00:13:48,320
to travel across regions at the moment
373
00:13:48,320 --> 00:13:49,680
you need to build many VMs.
374
00:13:49,680 --> 00:13:52,640
Instead, Azure Compute Gallery can replicate image versions
375
00:13:52,640 --> 00:13:54,560
to the regions where you expect to use them,
376
00:13:54,560 --> 00:13:57,680
meaning Azure places copies of that approved image version
377
00:13:57,680 --> 00:13:59,600
closer to the workloads that need it.
378
00:13:59,600 --> 00:14:01,840
That helps with speed, but it also helps with planning.
379
00:14:01,840 --> 00:14:04,080
If you know a large deployment is coming in another region,
380
00:14:04,080 --> 00:14:06,560
you can make sure the image version already exists there,
381
00:14:06,560 --> 00:14:08,720
so the deployment process can use a local copy
382
00:14:08,720 --> 00:14:10,640
rather than depend on the last minute transfer.
383
00:14:10,640 --> 00:14:12,720
Rapplica Count matters too.
384
00:14:12,720 --> 00:14:14,400
A Rapplica is another available copy
385
00:14:14,400 --> 00:14:16,400
of the image version within a region.
386
00:14:16,400 --> 00:14:18,720
When you deploy many VMs at the same time,
387
00:14:18,720 --> 00:14:21,440
Azure needs enough image capacity to supply them.
388
00:14:21,440 --> 00:14:23,120
A small deployment may need very little,
389
00:14:23,120 --> 00:14:25,200
but a large host pool, a scale-out event,
390
00:14:25,200 --> 00:14:27,600
or a recovery exercise may need more.
391
00:14:27,600 --> 00:14:30,000
So you choose the number of replicas based on
392
00:14:30,000 --> 00:14:32,320
how many VMs you expect to create at once.
393
00:14:32,320 --> 00:14:34,160
This is one of those details people don't notice
394
00:14:34,160 --> 00:14:35,840
until a deployment slows down.
395
00:14:35,840 --> 00:14:37,920
There is another reason image versions matter.
396
00:14:37,920 --> 00:14:38,720
Rollback.
397
00:14:38,720 --> 00:14:41,760
Let's say you publish a new image version with a browser update.
398
00:14:41,760 --> 00:14:43,840
Testing looked fine, but users later find
399
00:14:43,840 --> 00:14:46,240
that a business app no longer works with that browser release
400
00:14:46,240 --> 00:14:48,640
and you don't need to rebuild the old image from memory.
401
00:14:48,640 --> 00:14:50,880
You can select the earlier known good image version
402
00:14:50,880 --> 00:14:53,440
for the next deployment while you investigate the newer one,
403
00:14:53,440 --> 00:14:56,000
giving teams a controlled way back instead of a rushed repair.
404
00:14:56,000 --> 00:15:00,080
A managed image can still be useful for a simple local use case,
405
00:15:00,080 --> 00:15:02,080
but Azure Compute Gallery adds the parts
406
00:15:02,080 --> 00:15:04,560
that become important as usage grows,
407
00:15:04,560 --> 00:15:07,440
image families versions, regional replication,
408
00:15:07,440 --> 00:15:10,080
and wider reuse across teams and deployments.
409
00:15:10,080 --> 00:15:12,960
It turns a finished image into something people can identify,
410
00:15:12,960 --> 00:15:14,640
share, and use with confidence.
411
00:15:14,640 --> 00:15:16,640
The process sounds tidy on paper,
412
00:15:16,640 --> 00:15:19,920
but in real environments the failures usually happen around permissions,
413
00:15:19,920 --> 00:15:23,120
networks, policies, and scripts rather than the image itself,
414
00:15:23,120 --> 00:15:24,880
the parts that usually break.
415
00:15:24,880 --> 00:15:28,560
Most Azure image builder problems don't come from the image idea itself.
416
00:15:28,560 --> 00:15:30,400
They come from the connections around it.
417
00:15:30,400 --> 00:15:32,240
Permissions are usually first on the list.
418
00:15:32,240 --> 00:15:36,800
The managed identity needs permission to create the temporary resources used during the build,
419
00:15:36,800 --> 00:15:39,200
and it also needs permission to read the files it needs
420
00:15:39,200 --> 00:15:42,240
and publish the finished image to the destination you selected.
421
00:15:42,240 --> 00:15:45,040
But don't give it broad access just because of build fails.
422
00:15:45,040 --> 00:15:47,840
Give it the access required for its job and no more.
423
00:15:47,840 --> 00:15:50,240
If it needs to publish to an Azure Compute Gallery,
424
00:15:50,240 --> 00:15:51,520
give it the right access there.
425
00:15:51,520 --> 00:15:54,480
If it needs to read in-stallers from a storage account,
426
00:15:54,480 --> 00:15:56,800
give it read access to that storage location.
427
00:15:56,800 --> 00:16:00,560
A build identity shouldn't become an all-access account for your subscription.
428
00:16:00,560 --> 00:16:02,480
Network access is another common issue.
429
00:16:02,480 --> 00:16:06,160
The temporary build VM needs to reach the things your instructions depend on,
430
00:16:06,160 --> 00:16:08,720
including a script location and application installer,
431
00:16:08,720 --> 00:16:10,960
Windows Update Linux Package Sources,
432
00:16:10,960 --> 00:16:13,360
or Azure Services used during the build.
433
00:16:13,360 --> 00:16:15,840
A script can look perfect on paper and still fail
434
00:16:15,840 --> 00:16:18,400
because the VM cannot reach the download address.
435
00:16:18,400 --> 00:16:20,800
This often appears in locked-down environments.
436
00:16:20,800 --> 00:16:23,760
Your normal company VM may use a proxy, a private route,
437
00:16:23,760 --> 00:16:26,400
or a firewall rule that the build VM doesn't use.
438
00:16:26,400 --> 00:16:28,800
So before you start, ask a simple question.
439
00:16:28,800 --> 00:16:32,880
From the build network, can the temporary VM reach every place this image needs?
440
00:16:32,880 --> 00:16:34,720
Private storage needs a little more thought.
441
00:16:34,720 --> 00:16:38,720
You may keep installers, certificates, and scripts in a private Azure storage account,
442
00:16:38,720 --> 00:16:39,840
which is sensible.
443
00:16:39,840 --> 00:16:42,800
But the build still needs an approved way to reach those files.
444
00:16:42,800 --> 00:16:45,200
Don't solve that by making sensitive files public.
445
00:16:45,200 --> 00:16:47,040
Instead, set up the access path properly.
446
00:16:47,040 --> 00:16:49,520
The managed identity may need permission to read the files,
447
00:16:49,520 --> 00:16:53,280
and your network settings must allow the build VM to reach the storage account.
448
00:16:53,280 --> 00:16:55,120
Private doesn't mean unreachable.
449
00:16:55,120 --> 00:16:58,080
It means only approved identities and networks can get in.
450
00:16:58,080 --> 00:17:01,840
Security settings can also create a mismatch before customization even begins.
451
00:17:01,840 --> 00:17:05,440
For example, a source image may use a certain generation or security type,
452
00:17:05,440 --> 00:17:07,040
such as trusted launch support.
453
00:17:07,040 --> 00:17:11,120
The build setup and destination image settings need to match what that source supports.
454
00:17:11,120 --> 00:17:14,800
If they don't match, Azure can stop before your first script runs.
455
00:17:14,800 --> 00:17:17,760
So check the source image details early, check the image definition,
456
00:17:17,760 --> 00:17:19,440
and check the build VM settings.
457
00:17:19,440 --> 00:17:21,040
A secure source image is still usable,
458
00:17:21,040 --> 00:17:23,520
but the rest of the build needs to follow the same rules.
459
00:17:23,520 --> 00:17:25,760
Then there are the controls outside the template.
460
00:17:25,760 --> 00:17:28,240
Azure Policy can block a temporary disk type,
461
00:17:28,240 --> 00:17:32,160
network setting, or storage choice that as your image builder tries to create.
462
00:17:32,160 --> 00:17:36,400
And as your service provider that hasn't been registered can stop part of the build as well.
463
00:17:36,400 --> 00:17:38,960
This can feel confusing because your template may be correct,
464
00:17:38,960 --> 00:17:42,400
but the service simply can't create one of the resources it needs.
465
00:17:42,400 --> 00:17:44,720
Before spending hours changing scripts,
466
00:17:44,720 --> 00:17:48,080
check policy assignments and confirm the needed Azure resource providers
467
00:17:48,080 --> 00:17:49,760
are registered in the subscription.
468
00:17:49,760 --> 00:17:51,600
Scripts deserve their own discipline.
469
00:17:51,600 --> 00:17:55,040
Test every script on a normal VM before you add it to an image build.
470
00:17:55,040 --> 00:17:57,360
Make sure application installs run silently
471
00:17:57,360 --> 00:17:59,840
and make sure the script waits for installers to finish.
472
00:17:59,840 --> 00:18:02,720
Plan for restarts because updates and agents can require them.
473
00:18:02,720 --> 00:18:03,760
Also check exit codes,
474
00:18:03,760 --> 00:18:07,920
a script that reports success after an installer failed creates a bad image quietly.
475
00:18:07,920 --> 00:18:11,680
Your script should stop and report an error when a required step doesn't complete.
476
00:18:11,680 --> 00:18:14,560
When a build does fail, start with the last run status
477
00:18:14,560 --> 00:18:16,320
that tells you where Azure stopped.
478
00:18:16,320 --> 00:18:20,240
After that, look at the logs in the Packer Logs container in the staging storage account.
479
00:18:20,240 --> 00:18:22,640
Start with the customization log when a script failed
480
00:18:22,640 --> 00:18:25,520
and check the validation log when the build completed its changes
481
00:18:25,520 --> 00:18:26,800
but failed to check afterward.
482
00:18:26,800 --> 00:18:31,360
Those logs turn the image build failed into a specific answer.
483
00:18:31,360 --> 00:18:33,920
Start with one small image, one source image,
484
00:18:33,920 --> 00:18:36,240
one or two scripts and one output location.
485
00:18:36,880 --> 00:18:41,120
Prove that process first then let image updates become part of normal operations
486
00:18:41,120 --> 00:18:43,520
rather than an emergency project each month.
487
00:18:43,520 --> 00:18:45,600
A simple first image builder plan.
488
00:18:45,600 --> 00:18:49,040
So what's the simplest way to get started with Azure image builder?
489
00:18:49,040 --> 00:18:50,240
Think of it like a recipe.
490
00:18:50,240 --> 00:18:53,200
Start with one common VM type, one approved base image
491
00:18:53,200 --> 00:18:55,680
and a short list of changes you repeat every time.
492
00:18:55,680 --> 00:18:57,280
Keep that first template small.
493
00:18:57,280 --> 00:18:59,520
Just a source image, your customizations,
494
00:18:59,520 --> 00:19:01,840
one validation check as your compute gallery
495
00:19:01,840 --> 00:19:04,080
as the destination and a clear version number.
496
00:19:04,080 --> 00:19:06,560
Store your installers and scripts in a controlled location
497
00:19:06,560 --> 00:19:09,280
and use managed identity to read them when it makes sense.
498
00:19:09,280 --> 00:19:11,440
Managed identity is like a secure badge.
499
00:19:11,440 --> 00:19:13,680
It lets your scripts access resources
500
00:19:13,680 --> 00:19:15,360
without hard coding passwords.
501
00:19:15,360 --> 00:19:17,440
Choose a family name that makes sense to your team
502
00:19:17,440 --> 00:19:18,960
like Windows 11 standard
503
00:19:18,960 --> 00:19:22,160
and use a simple version pattern like 2026.07.
504
00:19:22,160 --> 00:19:23,760
One, before you go to production,
505
00:19:23,760 --> 00:19:26,160
create one test VM from that new version
506
00:19:26,160 --> 00:19:30,000
and check the app, agent updates and settings in a real environment.
507
00:19:30,000 --> 00:19:33,440
Once that works, put the build into Azure DevOps or another pipeline.
508
00:19:33,440 --> 00:19:35,120
Run it regularly for monthly patches
509
00:19:35,120 --> 00:19:38,240
and run it again whenever an urgent security update arrives.
510
00:19:38,240 --> 00:19:40,240
Bake the stable foundations into the image
511
00:19:40,240 --> 00:19:43,440
but deliver fast changing apps separately when that makes more sense.
512
00:19:43,440 --> 00:19:46,960
A repeatable image process doesn't just change how you build VMs.
513
00:19:46,960 --> 00:19:48,320
It changes your whole approach.
514
00:19:48,320 --> 00:19:50,960
So how do you put this process to work?
515
00:19:50,960 --> 00:19:53,760
Azure Image Builder replaces those hand-built golden images
516
00:19:53,760 --> 00:19:55,520
with a repeatable Azure process.
517
00:19:55,520 --> 00:19:56,720
Your next task is simple.
518
00:19:56,720 --> 00:19:58,640
List every app, setting, update,
519
00:19:58,640 --> 00:20:01,120
and check your team repeats when preparing a VM.
520
00:20:01,120 --> 00:20:02,560
Then choose one base image,
521
00:20:02,560 --> 00:20:04,960
publish one tested version to Azure Compute Gallery
522
00:20:04,960 --> 00:20:06,880
and start learning how Compute Gallery
523
00:20:06,880 --> 00:20:10,480
managed identities and image update pipelines all fit together.
