Alright.
Now, as far as using your workspace,
the idea is once your Windows Server machines,
no matter where they are, are onboarded into log analytics,
the question then is going to be how can you then surface that log data?
And once again, there are lots of different options,
but it just occurred to me there is one more alternative I wanted
to make sure to cover before we go on to that final step and that
is something else we can do with our off‑cloud Windows servers is
enroll them in Azure Arc,
and this is going to give you better Azure‑based management and
governance of your off‑cloud Windows server machines.
So we can, for instance, add in a server,
and I'm just going to generate a script for a single server,
and what Azure Arc for servers does here,
it's going to create a PowerShell script and it's going to create a
resource for those off‑cloud virtual machines.
We'll place them in a resource group, a region,
an operating system, a connectivity method.
I'm going to just go over the internet on the public endpoint.
We can adjust taxonomic tags,
and then we have the script which I'm going to download to my local system here.
SmartScreen wants to delete it, but I'm going to say no.
I want you to keep it.
And just as easy as that.
Now what is this going to get us?
What is the Azure Arc for servers going to get us?
Well, it's yet another way to onboard an off‑cloud Windows Server VM,
although it handles Linux as well into Log Analytics,
but you can also do things like Azure policy and evaluate compliance.
The Azure Arc service is pretty neat.
The idea is that you can do your governance and your management from Azure and
touch machines that are outside of Azure as simple as that.
So let me open up an elevated PowerShell console here on this server,
and let me, while I'm here,
just quickly adjust the font and size so we can see what we're doing here,
and let me CD into downloads and get the name of that script file.
There it is.
So as long as I've got a good execution policy minus set to bypass,
I can just run that onboarding script as‑is,
and what that will do is go over the internet and
download the Azure connected machine agent,
extract it,
and it will automate the handshaking or onboarding of
this machine into Azure Arc for Servers,
and we then can do a number of different things,
including using the native Azure virtual machine extension
model to service this off‑cloud server.
It's very convenient indeed.
Good.
So the agent completed successfully,
and it's now telling us that let's see we have to do a browser login here,
so let me come into the browser aka.ms/devicelogin.
So this is an authentication step to make sure that I have
privileges to onboard this machine into Azure Arc,
which I do.
Now let me verify my credentials here.
Yes, I'm trying to sign in to the connected machine agent,
and now close the window, and the script will finish momentarily,
and we'll then find a resource for my DC1 domain controller
that's available for management within Azure.
Okay, well it says successfully onboarded resource to Azure.
Good deal.
So if we come back to the portal one more time,
let me do a refresh, and now we have a connected external resource,
and as I was saying, we then can do extensions,
and in the available extensions list, we've got the Log Analytics Agent.
Making sense?
I'm doing all this very intentionally because I want to
make sure you're aware of these possibilities for your
AZ‑801 and AZ‑800 exam success, as well as for your career.
So let's go over to Monitor.
Now, Log Analytics uses a separate separate query language called Kusto,
K‑u‑s‑t‑o, and you'll need to learn that anyway.
But notice that under Insights here,
you can surface a lot of the Kusto log data in a more
user‑friendly way by making connections to these insights.
The first time you come in here,
you'll be asked to enable the insight for those services,
and notice again we've got integration between native Azure machines,
as well as Azure Arc for Server machines,
and basically, the insights are all Microsoft selected
visualizations that surface either numeric metric data or,
as I said,
Kusto query results to give you high impact monitoring
information on all these different workloads.
Now, you can always go into the log search interface,
and this allows you access to the Kusto language specifically.
And in Azure Monitor, you're asked to select a monitoring scope.
I'm going to just go all the way to my subscription scope,
make it as wide as possible,
and all of the logs that have been ingested into log analytics are
rationalized into these virtual tables as you can see down here,
and I would suggest as a newcomer, you might want to look under queries,
in particular, if we come down to virtual networks or virtual machines,
these are common queries that Microsoft has found
useful with their customer support.
So let's load up this chart CPU usage trends query here,
and the way the Kusto language works is that you reference
one or more of those virtual tables and then you separate
your clauses with a pipe character.
This query language is very familiar with the Splunk language
if you're familiar with Splunk Monitor,
also the AWS CloudTrail log search language.
It looks a bit like SQL, or structured query language.
Microsoft invented this,
they use it internally and they have now surfaced it to customers.
I'm going to change the time grain here and see if
we get any results back from VMs.
Yeah, we do,
and the idea is that this is a massively scalable log search platform,
and you can visualize your results very easily just by clicking Chart now.
You're going to need to model your query to support that.
This doesn't really lend itself to that,
this particular query looking at CPU usage,
unless we cut down the columns that we're getting back.
But I want to mention here that you can export your query results,
not only in CSV or Power BIM query syntax or Excel,
but you can actually raise alert rules based on a log query that
Azure will run over and over and over and over again.
Now in this case, I'm surprised that it did that.
Normally when you have a query up and running and you go to New alert rule,
the interface should fill there, there it is,
it filled in the query.
And so we could maybe modify this query to show only where
percent processor time is over a certain amount,
and then we can fire the alert whenever that log query returns results.
You see what I mean?
Good.
So with all that basis now, let's move into Microsoft Sentinel, the SIEM/SOAR platform in Azure.