1
00:00:00,740 --> 00:00:01,100
Alright.

2
00:00:01,100 --> 00:00:03,060
Now, as far as using your workspace,

3
00:00:03,060 --> 00:00:05,650
the idea is once your Windows Server machines,

4
00:00:05,650 --> 00:00:09,340
no matter where they are, are onboarded into log analytics,

5
00:00:09,340 --> 00:00:14,140
the question then is going to be how can you then surface that log data?

6
00:00:14,140 --> 00:00:16,610
And once again, there are lots of different options,

7
00:00:16,610 --> 00:00:20,030
but it just occurred to me there is one more alternative I wanted

8
00:00:20,030 --> 00:00:24,210
to make sure to cover before we go on to that final step and that

9
00:00:24,210 --> 00:00:29,360
is something else we can do with our off‑cloud Windows servers is

10
00:00:29,360 --> 00:00:32,240
enroll them in Azure Arc,

11
00:00:32,240 --> 00:00:36,230
and this is going to give you better Azure‑based management and

12
00:00:36,230 --> 00:00:40,240
governance of your off‑cloud Windows server machines.

13
00:00:40,240 --> 00:00:42,490
So we can, for instance, add in a server,

14
00:00:42,490 --> 00:00:45,600
and I'm just going to generate a script for a single server,

15
00:00:45,600 --> 00:00:47,910
and what Azure Arc for servers does here,

16
00:00:47,910 --> 00:00:50,770
it's going to create a PowerShell script and it's going to create a

17
00:00:50,770 --> 00:00:54,140
resource for those off‑cloud virtual machines.

18
00:00:54,140 --> 00:00:57,500
We'll place them in a resource group, a region,

19
00:00:57,500 --> 00:01:00,210
an operating system, a connectivity method.

20
00:01:00,210 --> 00:01:03,340
I'm going to just go over the internet on the public endpoint.

21
00:01:03,340 --> 00:01:06,540
We can adjust taxonomic tags,

22
00:01:06,540 --> 00:01:11,240
and then we have the script which I'm going to download to my local system here.

23
00:01:11,240 --> 00:01:14,350
SmartScreen wants to delete it, but I'm going to say no.

24
00:01:14,350 --> 00:01:15,640
I want you to keep it.

25
00:01:15,640 --> 00:01:17,380
And just as easy as that.

26
00:01:17,380 --> 00:01:18,790
Now what is this going to get us?

27
00:01:18,790 --> 00:01:21,640
What is the Azure Arc for servers going to get us?

28
00:01:21,640 --> 00:01:25,800
Well, it's yet another way to onboard an off‑cloud Windows Server VM,

29
00:01:25,800 --> 00:01:28,790
although it handles Linux as well into Log Analytics,

30
00:01:28,790 --> 00:01:33,440
but you can also do things like Azure policy and evaluate compliance.

31
00:01:33,440 --> 00:01:35,300
The Azure Arc service is pretty neat.

32
00:01:35,300 --> 00:01:39,630
The idea is that you can do your governance and your management from Azure and

33
00:01:39,630 --> 00:01:43,040
touch machines that are outside of Azure as simple as that.

34
00:01:43,040 --> 00:01:48,240
So let me open up an elevated PowerShell console here on this server,

35
00:01:48,240 --> 00:01:49,490
and let me, while I'm here,

36
00:01:49,490 --> 00:01:54,460
just quickly adjust the font and size so we can see what we're doing here,

37
00:01:54,460 --> 00:02:00,940
and let me CD into downloads and get the name of that script file.

38
00:02:00,940 --> 00:02:02,040
There it is.

39
00:02:02,040 --> 00:02:07,470
So as long as I've got a good execution policy minus set to bypass,

40
00:02:07,470 --> 00:02:11,760
I can just run that onboarding script as‑is,

41
00:02:11,760 --> 00:02:14,270
and what that will do is go over the internet and

42
00:02:14,270 --> 00:02:17,340
download the Azure connected machine agent,

43
00:02:17,340 --> 00:02:18,140
extract it,

44
00:02:18,140 --> 00:02:21,090
and it will automate the handshaking or onboarding of

45
00:02:21,090 --> 00:02:23,930
this machine into Azure Arc for Servers,

46
00:02:23,930 --> 00:02:26,240
and we then can do a number of different things,

47
00:02:26,240 --> 00:02:30,000
including using the native Azure virtual machine extension

48
00:02:30,000 --> 00:02:33,120
model to service this off‑cloud server.

49
00:02:33,120 --> 00:02:35,740
It's very convenient indeed.

50
00:02:35,740 --> 00:02:36,020
Good.

51
00:02:36,020 --> 00:02:38,120
So the agent completed successfully,

52
00:02:38,120 --> 00:02:42,640
and it's now telling us that let's see we have to do a browser login here,

53
00:02:42,640 --> 00:02:50,040
so let me come into the browser aka.ms/devicelogin.

54
00:02:50,040 --> 00:02:53,150
So this is an authentication step to make sure that I have

55
00:02:53,150 --> 00:02:56,680
privileges to onboard this machine into Azure Arc,

56
00:02:56,680 --> 00:02:57,240
which I do.

57
00:02:57,240 --> 00:03:00,290
Now let me verify my credentials here.

58
00:03:00,290 --> 00:03:04,740
Yes, I'm trying to sign in to the connected machine agent,

59
00:03:04,740 --> 00:03:08,490
and now close the window, and the script will finish momentarily,

60
00:03:08,490 --> 00:03:13,760
and we'll then find a resource for my DC1 domain controller

61
00:03:13,760 --> 00:03:16,640
that's available for management within Azure.

62
00:03:16,640 --> 00:03:20,180
Okay, well it says successfully onboarded resource to Azure.

63
00:03:20,180 --> 00:03:21,340
Good deal.

64
00:03:21,340 --> 00:03:23,720
So if we come back to the portal one more time,

65
00:03:23,720 --> 00:03:29,190
let me do a refresh, and now we have a connected external resource,

66
00:03:29,190 --> 00:03:33,840
and as I was saying, we then can do extensions,

67
00:03:33,840 --> 00:03:39,840
and in the available extensions list, we've got the Log Analytics Agent.

68
00:03:39,840 --> 00:03:40,650
Making sense?

69
00:03:40,650 --> 00:03:43,880
I'm doing all this very intentionally because I want to

70
00:03:43,880 --> 00:03:46,440
make sure you're aware of these possibilities for your

71
00:03:46,440 --> 00:03:52,140
AZ‑801 and AZ‑800 exam success, as well as for your career.

72
00:03:52,140 --> 00:03:53,950
So let's go over to Monitor.

73
00:03:53,950 --> 00:03:58,320
Now, Log Analytics uses a separate separate query language called Kusto,

74
00:03:58,320 --> 00:04:02,540
K‑u‑s‑t‑o, and you'll need to learn that anyway.

75
00:04:02,540 --> 00:04:04,610
But notice that under Insights here,

76
00:04:04,610 --> 00:04:09,430
you can surface a lot of the Kusto log data in a more

77
00:04:09,430 --> 00:04:13,920
user‑friendly way by making connections to these insights.

78
00:04:13,920 --> 00:04:15,540
The first time you come in here,

79
00:04:15,540 --> 00:04:19,420
you'll be asked to enable the insight for those services,

80
00:04:19,420 --> 00:04:23,900
and notice again we've got integration between native Azure machines,

81
00:04:23,900 --> 00:04:26,940
as well as Azure Arc for Server machines,

82
00:04:26,940 --> 00:04:30,640
and basically, the insights are all Microsoft selected

83
00:04:30,640 --> 00:04:35,060
visualizations that surface either numeric metric data or,

84
00:04:35,060 --> 00:04:35,840
as I said,

85
00:04:35,840 --> 00:04:39,580
Kusto query results to give you high impact monitoring

86
00:04:39,580 --> 00:04:42,540
information on all these different workloads.

87
00:04:42,540 --> 00:04:46,640
Now, you can always go into the log search interface,

88
00:04:46,640 --> 00:04:51,340
and this allows you access to the Kusto language specifically.

89
00:04:51,340 --> 00:04:54,680
And in Azure Monitor, you're asked to select a monitoring scope.

90
00:04:54,680 --> 00:04:57,750
I'm going to just go all the way to my subscription scope,

91
00:04:57,750 --> 00:05:00,340
make it as wide as possible,

92
00:05:00,340 --> 00:05:03,960
and all of the logs that have been ingested into log analytics are

93
00:05:03,960 --> 00:05:08,040
rationalized into these virtual tables as you can see down here,

94
00:05:08,040 --> 00:05:12,840
and I would suggest as a newcomer, you might want to look under queries,

95
00:05:12,840 --> 00:05:16,670
in particular, if we come down to virtual networks or virtual machines,

96
00:05:16,670 --> 00:05:19,640
these are common queries that Microsoft has found

97
00:05:19,640 --> 00:05:22,050
useful with their customer support.

98
00:05:22,050 --> 00:05:26,540
So let's load up this chart CPU usage trends query here,

99
00:05:26,540 --> 00:05:29,610
and the way the Kusto language works is that you reference

100
00:05:29,610 --> 00:05:33,180
one or more of those virtual tables and then you separate

101
00:05:33,180 --> 00:05:35,480
your clauses with a pipe character.

102
00:05:35,480 --> 00:05:38,770
This query language is very familiar with the Splunk language

103
00:05:38,770 --> 00:05:41,140
if you're familiar with Splunk Monitor,

104
00:05:41,140 --> 00:05:45,440
also the AWS CloudTrail log search language.

105
00:05:45,440 --> 00:05:48,880
It looks a bit like SQL, or structured query language.

106
00:05:48,880 --> 00:05:50,560
Microsoft invented this,

107
00:05:50,560 --> 00:05:54,570
they use it internally and they have now surfaced it to customers.

108
00:05:54,570 --> 00:05:57,150
I'm going to change the time grain here and see if

109
00:05:57,150 --> 00:05:59,740
we get any results back from VMs.

110
00:05:59,740 --> 00:06:00,350
Yeah, we do,

111
00:06:00,350 --> 00:06:04,970
and the idea is that this is a massively scalable log search platform,

112
00:06:04,970 --> 00:06:10,030
and you can visualize your results very easily just by clicking Chart now.

113
00:06:10,030 --> 00:06:12,870
You're going to need to model your query to support that.

114
00:06:12,870 --> 00:06:15,030
This doesn't really lend itself to that,

115
00:06:15,030 --> 00:06:17,940
this particular query looking at CPU usage,

116
00:06:17,940 --> 00:06:21,040
unless we cut down the columns that we're getting back.

117
00:06:21,040 --> 00:06:24,960
But I want to mention here that you can export your query results,

118
00:06:24,960 --> 00:06:29,740
not only in CSV or Power BIM query syntax or Excel,

119
00:06:29,740 --> 00:06:34,280
but you can actually raise alert rules based on a log query that

120
00:06:34,280 --> 00:06:38,040
Azure will run over and over and over and over again.

121
00:06:38,040 --> 00:06:40,530
Now in this case, I'm surprised that it did that.

122
00:06:40,530 --> 00:06:45,240
Normally when you have a query up and running and you go to New alert rule,

123
00:06:45,240 --> 00:06:47,280
the interface should fill there, there it is,

124
00:06:47,280 --> 00:06:48,870
it filled in the query.

125
00:06:48,870 --> 00:06:53,120
And so we could maybe modify this query to show only where

126
00:06:53,120 --> 00:06:56,640
percent processor time is over a certain amount,

127
00:06:56,640 --> 00:07:00,790
and then we can fire the alert whenever that log query returns results.

128
00:07:00,790 --> 00:07:02,040
You see what I mean?

129
00:07:02,040 --> 00:07:02,740
Good.

130
00:07:02,740 --> 00:07:09,000
So with all that basis now, let's move into Microsoft Sentinel, the SIEM/SOAR platform in Azure.