[Autogenerated] Alright well let's keep on trucking here
next we've got update management to cover.
And I want to frame this discussion by going to log
analytics workspace because when we're talking about update
management and as your automation,
your step one is going to be to make sure you have a log analytics
workspace in scope and onboard and you create your workspace,
it runs at a free tier.
The free tier limits you to about a week's worth of data retention and you
are also kept on your data ingestion volume per month.
So you'll want to use one of the paid tiers pay as you go to make sure
that your log analytics workspace can scale properly.
There's a two year data retention on the paid tier and to make
sure that your virtual machines are all set up,
we can onboard them.
Actually, I'll leave that for the next module.
I'll do a demo on that at that time.
But anyway, once you've got your log analytics workspace online,
you're ready to proceed to look at update management and update
management is a feature of the Azure automation account.
So after you create your log analytics workspace,
you'll want to create an Azure automation account.
And the main things I want to show you there is how you're going to
authenticate to Azure from your run books and the recommended way to go is to
use a system assigned or user assigned managed identity.
The V one way to do automation account is with what's called a run as
account system assigned or user assigned managed identities I think are a
much cleaner way to go because as this says,
it doesn't require that you manage any credentials when you have a run as
account that run as account uses a digital certificate that's going to
expire and need to be renewed every so often.
Whereas if you have a managed identity that's going to have
an Azure managed password that's auto rotated and you never
have to worry about that.
So I'm going to create a system assigned managed identity and
then we can choose what kind of access.
If we're going to do private endpoint where we're
integrating the automation account into a virtual network
or if we're coming over the internet,
I'm going to be coming over the internet in this case like next we've
got our taxonomic tags and then that's the creation.
Now I haven't actually specified a name or a resource
group so that's why it failed validation.
I'm actually going to bail out of here because I have an
automation account already created.
If we come into that automation account we can see
under configuration management,
the different parts and pieces of the service and you'll find that
the first time you click into these you're going to be required to
point to your log analytics workspace.
I've already done that for these services so that I
have something for you to look at.
But just know that that's going to be a one time occurrence.
The first time you're in your automation account and you want to begin
to light up some of these configuration management,
update management and process automation features were
concerned specifically with update management.
So here's what the interface looks like after you've
connected to your log analytics workspace.
We can see up here in our news that four machines do not have
the update management feature enabled and we can click manage
machines to get a list here.
Now it says here that the machines will report to our log analytics workspace or
actually it looks like that they're currently reporting to the workspace but
they don't have update management enabled on them.
So I could just do a global enable on or I could do selected machines
notice that it's picked up arc one and arc too and I have VM two and VM
three as Azure native virtual machines.
So we're picking up your hybrid machines here all in one go.
I want to make sure to do this now because it says these machines
are reporting to the log analytics workspace,
we can reasonably and accurately assume that those machines must have
the log analytics agent already installed on them.
That's important.
Now, as far as onboarding machines manually,
as you can see on the toolbar,
we can add as your virtual machines by doing an enable update management.
Notice that if you do have a machine that is a candidate
for update management and it's stopped,
we're not going to be able to enable as you can see here
it's kind of faint But Mike Lee one Machine cannot be
enabled because the VM has stopped.
If I go to add non Azure machine, it's simply kicks us over into the docks.
Actually this is the article on the log analytics agent and
basically in order to have the machines show up is being able to
be on boarded to update management.
We simply need to install the log analytics agent
which we'll do in the next module.
The portal interface says wait at least 15 minutes for your newly on
boarded Azure and non Azure machines to begin to report the update
management and we can see that's the case down here.
So what we've got on the machines pages,
a roll up of all enrolled machines, their compliance status,
critical security, other missing updates where the update approval source is.
We can just filter on specific missing updates as you can see here and there's a
baby link to each of those as you can see over on the side.
We can adjust the view classification as such and then as far as scheduled
deployments in history we can filter on this view as well.
Of course we've got log search and I'll show you that I'll
actually finish this demo with a little bit of cake ul to show
you a better way to report on that.
So the idea is you report on your compliance status and then you
do your updates scheduling right over here.
Let me show you how to schedule an update deployment up here on the toolbar.
We can click and let's say this update is just going to be for our Azure VMS.
We'll do Windows and we can create dynamic groups that we can then reuse.
I'm going to filter this on my subscription and my 800 resource
groups click add and then if we click preview,
it'll show us what machines are in scope.
This is very similar to what you would do in Windows server update services.
And notice that you can define groups for Azure and non Azure systems.
We can then adjust the machines within those groups that we want to update
as well as what update classifications we're doing here.
We can do update include exclude filtering and then notice the asterisk,
we have to specify our schedule but I can specify that
this is going to take place on the 13th,
say at 1 45 AM central time and we can have this be
a recurring or once only event.
We can inject pre and post scripts.
These are from the Azure automation run book library.
Our maintenance window here is going to be a time interval
between 30 minutes and less than six hours.
And you would adjust this.
This is the time period in which Microsoft needs to complete those updates
and you would align this with your IT service management.
Platform maintenance window and then we can control reboots.
All right.
So it's not quite as robust as what you would have
with Windows server update services.
But wow,
the fact that you don't have to worry about w sauce high
availability and patch and back up those machines,
The fact that it's all automated here in the cloud is pretty compelling.
It seems to me,
and also we have the added benefit that we can manage Azure arc enabled
servers and we also can patch both Windows server and Linux. That's a really good deal.