WEBVTT

00:00:00.000 --> 00:00:01.740
>> Hi my name is Thomas Maurer.

00:00:01.740 --> 00:00:04.770
I'm a Cloud Advocate at Microsoft
and I'm sitting here with

00:00:04.770 --> 00:00:06.645
Chang' from the Azure Management team

00:00:06.645 --> 00:00:08.635
to talk about Hybrid
Server Management.

00:00:08.635 --> 00:00:11.300
>> Yeah. Hi. I'm a
Program Manager in Azure.

00:00:11.300 --> 00:00:14.100
>> Hi. So I speak a lot with

00:00:14.100 --> 00:00:17.925
customers which are using the
Cloud for compute resources.

00:00:17.925 --> 00:00:20.610
But most of them or a
lot of them also have

00:00:20.610 --> 00:00:22.950
servers running in their
private data centers,

00:00:22.950 --> 00:00:24.495
in their branch offices,

00:00:24.495 --> 00:00:26.910
or even have other parts in
the organization which they

00:00:26.910 --> 00:00:30.195
use another Cloud provider or
another service providers.

00:00:30.195 --> 00:00:31.830
One of the main challenges with

00:00:31.830 --> 00:00:34.490
all these servers they
have is basically keeping

00:00:34.490 --> 00:00:36.400
control of all these
servers whenever they are

00:00:36.400 --> 00:00:38.620
running to make sure
that they are secure,

00:00:38.620 --> 00:00:42.085
that they are patch, that
they have the compliance.

00:00:42.085 --> 00:00:44.585
I heard that the Azure
team and especially you

00:00:44.585 --> 00:00:46.760
are working on something
which helps with that.

00:00:46.760 --> 00:00:49.940
>> Yeah. Absolutely,
I love to talk about

00:00:49.940 --> 00:00:53.240
it and I was actually echoing
what you just mentioned.

00:00:53.240 --> 00:00:55.835
It is indeed a huge challenge.

00:00:55.835 --> 00:00:59.990
So I had talked to a lot of customers
as well especially they need

00:00:59.990 --> 00:01:03.890
to manage these very like
Hybrid environments,

00:01:03.890 --> 00:01:05.345
so we're all over the place

00:01:05.345 --> 00:01:07.490
with Application team
trying to just go out,

00:01:07.490 --> 00:01:08.930
get all the resource they need to.

00:01:08.930 --> 00:01:10.010
It doesn't matter which Cloud,

00:01:10.010 --> 00:01:12.845
they just go in and
deploy things there.

00:01:12.845 --> 00:01:15.560
IT on the other hand is
trying to understand,

00:01:15.560 --> 00:01:17.540
oh my gosh, where are all the things?

00:01:17.540 --> 00:01:19.070
Where are all the data?

00:01:19.070 --> 00:01:21.650
What happens if
something got breached?

00:01:21.650 --> 00:01:24.545
Especially now you see the
news all over the place.

00:01:24.545 --> 00:01:29.210
So this is really something
Azure has always been thinking

00:01:29.210 --> 00:01:31.760
about and especially services

00:01:31.760 --> 00:01:34.970
today that already
managing on-prem service.

00:01:34.970 --> 00:01:36.470
But now with this service,

00:01:36.470 --> 00:01:39.620
we're really taking it
to the next step to

00:01:39.620 --> 00:01:43.160
integrate those servers
more natively into Azure.

00:01:43.160 --> 00:01:44.975
>> Okay. That sounds fantastic.

00:01:44.975 --> 00:01:46.640
So when you talk about integrating

00:01:46.640 --> 00:01:49.115
the service into Azure,
what do you mean by that?

00:01:49.115 --> 00:01:51.260
>> Yeah. I love to show
you a picture of it.

00:01:51.260 --> 00:01:52.070
>> Perfect. Thank you.

00:01:52.070 --> 00:01:56.630
>> Here is how services are
managing these environments.

00:01:56.630 --> 00:01:59.070
So these services actually,

00:01:59.070 --> 00:02:01.560
all managed on-prem service today.

00:02:01.560 --> 00:02:03.470
By the way, I'm calling
the on-prem server

00:02:03.470 --> 00:02:05.480
but it really doesn't
matter where they are.

00:02:05.480 --> 00:02:07.400
They can be on-prem in datacenters,

00:02:07.400 --> 00:02:10.580
private datacenters, or in
other hosts of the Cloud.

00:02:10.580 --> 00:02:11.975
But as you can see,

00:02:11.975 --> 00:02:15.170
all these servers managing the
Azure Virtual Machines through

00:02:15.170 --> 00:02:18.515
the something called Azure
Resource Manager, short for ARM,

00:02:18.515 --> 00:02:21.305
and where on the on-prem servers,

00:02:21.305 --> 00:02:24.485
they really need to figure
out a way to get their code

00:02:24.485 --> 00:02:28.220
deployed onto those on-prem
servers individually.

00:02:28.220 --> 00:02:29.840
So as you can see,

00:02:29.840 --> 00:02:32.180
there's some disparity between

00:02:32.180 --> 00:02:35.540
the tube panel and this

00:02:35.540 --> 00:02:39.320
is really what I mean by natively
integrated into your ARM.

00:02:39.320 --> 00:02:43.315
Now they get projected as
the ARM resource into Azure.

00:02:43.315 --> 00:02:45.295
The benefit will be huge.

00:02:45.295 --> 00:02:48.220
As you can see a lot of
investment went into ARM;

00:02:48.220 --> 00:02:50.710
like identity, like
RBAC, like policies.

00:02:50.710 --> 00:02:53.170
Most importantly a lot of
customers really care about

00:02:53.170 --> 00:02:57.460
compliance and also just regular
management like tag them,

00:02:57.460 --> 00:02:59.800
show what are my servers
are all in production,

00:02:59.800 --> 00:03:03.820
those kinds of simple things
are all capable through ARM.

00:03:03.820 --> 00:03:07.930
So now I have once project
these servers into ARM,

00:03:07.930 --> 00:03:09.520
I get all these benefit.

00:03:09.520 --> 00:03:12.160
In addition, all the
services now can be

00:03:12.160 --> 00:03:16.725
deployed onto Azure as well as
on-prem in the same fashion.

00:03:16.725 --> 00:03:18.000
So as you can see here,

00:03:18.000 --> 00:03:22.805
I labeled out this very important
component called Guest Agent.

00:03:22.805 --> 00:03:25.250
The purpose of this
agent is to manage

00:03:25.250 --> 00:03:28.430
the lifecycle of these
extensions and we're following

00:03:28.430 --> 00:03:30.635
the same model so that now

00:03:30.635 --> 00:03:34.630
all these extensions can be applied
to on-prem service as well.

00:03:34.630 --> 00:03:38.700
>> So that's great. So our servers
show up as Azure resources.

00:03:38.700 --> 00:03:41.480
They show up in the portal and also
in the Azure Resource Manager,

00:03:41.480 --> 00:03:44.330
and I can basically treat
them like machines,

00:03:44.330 --> 00:03:47.195
like I used to do with Azure
Virtual Machines, right?

00:03:47.195 --> 00:03:49.759
>> Yes. From a
management perspective,

00:03:49.759 --> 00:03:51.500
that is our central goal.

00:03:51.500 --> 00:03:54.170
We wanted all these
solutions to manage

00:03:54.170 --> 00:03:57.470
the servers the same way
for Azure as well as

00:03:57.470 --> 00:04:03.805
for on-prem and also they
get the same ARM benefit.

00:04:03.805 --> 00:04:05.360
>> Okay, that's awesome.

00:04:05.360 --> 00:04:07.850
So I want to now use that.

00:04:07.850 --> 00:04:11.215
So can you show me how we
on-board this service to Azure?

00:04:11.215 --> 00:04:13.460
>> Absolutely, let
me show you a demo.

00:04:13.460 --> 00:04:15.560
This is a page that we built to show

00:04:15.560 --> 00:04:19.960
all the on-prem servers that
has been on-boarded to Azure.

00:04:19.960 --> 00:04:23.890
Essentially to on-board,
the customer need to run

00:04:23.890 --> 00:04:27.790
a script on the server and to
help to build that script,

00:04:27.790 --> 00:04:32.840
we actually build a flow in
Azure to generate that script.

00:04:33.260 --> 00:04:36.235
So this is option that they can

00:04:36.235 --> 00:04:39.100
click to generate the script
but at the same time,

00:04:39.100 --> 00:04:42.520
it also recognize is a challenge
for customers to on-board

00:04:42.520 --> 00:04:44.080
a scale if they have to connect to

00:04:44.080 --> 00:04:46.705
every single server individually
to run these scripts.

00:04:46.705 --> 00:04:49.240
So we're also trying
to understand what are

00:04:49.240 --> 00:04:53.140
some common on-prem server
management application so we can

00:04:53.140 --> 00:04:57.505
integrate to help customers to
on-board those machines at scale.

00:04:57.505 --> 00:05:00.295
For example, here, if
the server is already

00:05:00.295 --> 00:05:03.100
managed by the Azure updates service,

00:05:03.100 --> 00:05:05.120
we build actually the script

00:05:05.120 --> 00:05:07.640
or the runbooks to actually
deploy to on-board

00:05:07.640 --> 00:05:10.505
those machines onto Azure

00:05:10.505 --> 00:05:13.055
without actually customers
touching all those machines.

00:05:13.055 --> 00:05:15.770
But in the future, we're also
working with, for example,

00:05:15.770 --> 00:05:19.129
System Center Configuration Manager
and they're also integrating

00:05:19.129 --> 00:05:20.870
the on-boarding experience and

00:05:20.870 --> 00:05:22.580
in addition to Windows Admin Center.

00:05:22.580 --> 00:05:25.850
So we've just keep on
expanding on how customers can

00:05:25.850 --> 00:05:29.240
on-board to Azure in
a least effort way.

00:05:29.240 --> 00:05:32.630
But in this case, let me show
you how to generate the script.

00:05:32.630 --> 00:05:35.510
So as you can see these
are Azure resources.

00:05:35.510 --> 00:05:37.220
So they follow the same hierarchy

00:05:37.220 --> 00:05:39.140
as in subscriptions
and resource group.

00:05:39.140 --> 00:05:40.385
So now you can pick

00:05:40.385 --> 00:05:44.870
which subscription and resource
group they wanted to go and here

00:05:44.870 --> 00:05:46.790
the region indicates that

00:05:46.790 --> 00:05:48.950
which Azure region is running

00:05:48.950 --> 00:05:51.980
these servers managing
these on-prem resources.

00:05:51.980 --> 00:05:56.930
So you can see from compliance
or regulatory point perspective,

00:05:56.930 --> 00:05:59.635
we know where the metadata
is stored in Azure.

00:05:59.635 --> 00:06:03.620
Physical location is new specifically
for the on-prem servers.

00:06:03.620 --> 00:06:06.245
This allows customer
to tag the servers

00:06:06.245 --> 00:06:10.655
or specifically indicate
which datacenter they are in.

00:06:10.655 --> 00:06:13.940
This is really about
ease of management.

00:06:13.940 --> 00:06:15.440
>> Okay, that's pretty cool.

00:06:15.440 --> 00:06:18.650
So customers could not just add
a name over the datacenters.

00:06:18.650 --> 00:06:20.330
So they could even like, for example,

00:06:20.330 --> 00:06:22.460
also add a room of the location or

00:06:22.460 --> 00:06:25.520
even direct name or direct
number for the server?

00:06:25.520 --> 00:06:26.570
>> Yeah, absolutely.

00:06:26.570 --> 00:06:28.670
So this is really for the customer

00:06:28.670 --> 00:06:31.100
to easily identify
where that resource is.

00:06:31.100 --> 00:06:32.750
If something happens to that server,

00:06:32.750 --> 00:06:34.810
they can go if they need
to physically access,

00:06:34.810 --> 00:06:37.160
they know exactly
where they need to be.

00:06:37.160 --> 00:06:41.825
Here we also allow customer to
choose the operating systems.

00:06:41.825 --> 00:06:45.200
I didn't really specifically
spell it out but as always,

00:06:45.200 --> 00:06:48.395
in Azure we are trying to embrace
Windows as well as Linux.

00:06:48.395 --> 00:06:50.570
Same for here that we build

00:06:50.570 --> 00:06:52.820
two packages for agent to

00:06:52.820 --> 00:06:56.460
on-board either Windows
Server or Linux server.

00:06:57.380 --> 00:07:01.200
Understand a lot of customers
for on-prem especially,

00:07:01.200 --> 00:07:03.520
they don't want to
expose their servers to

00:07:03.520 --> 00:07:06.805
the Internet directly and they
put it behind a proxy server.

00:07:06.805 --> 00:07:12.050
So here in this case our agent
does need to connect to the Azure.

00:07:14.280 --> 00:07:18.400
If these servers are not
connect to the Azure directly,

00:07:18.400 --> 00:07:21.610
they can configure the
proxy server here and then

00:07:21.610 --> 00:07:26.000
the agent will be able to communicate
through the proxy server.

00:07:26.880 --> 00:07:33.700
This is just an Azure resource
capability so they can tack

00:07:33.700 --> 00:07:36.220
the servers to indicate
maybe who owns

00:07:36.220 --> 00:07:39.805
them or whether they
are a part of a team.

00:07:39.805 --> 00:07:41.570
>> Yeah. This also
means that it's just

00:07:41.570 --> 00:07:43.670
like with other Azure
resources, right.

00:07:43.670 --> 00:07:46.100
So for example in my
environment I tag resources

00:07:46.100 --> 00:07:48.665
based on production,
development environment,

00:07:48.665 --> 00:07:50.375
demo environments, and so on;

00:07:50.375 --> 00:07:52.265
so they can use the same tagging

00:07:52.265 --> 00:07:53.870
for their basically on-prem servers?

00:07:53.870 --> 00:07:56.560
>> Yeah, exactly. You got that.

00:07:56.750 --> 00:07:59.340
In the end here,

00:07:59.340 --> 00:08:01.670
we generate this script.

00:08:01.670 --> 00:08:03.650
So now you can take a copy of

00:08:03.650 --> 00:08:06.110
the script and run it
on the target server.

00:08:06.110 --> 00:08:09.485
Let me show you exactly
the script content.

00:08:09.485 --> 00:08:11.585
So the first is really three steps.

00:08:11.585 --> 00:08:13.580
Once you download the package,

00:08:13.580 --> 00:08:17.270
but if you actually already
downloaded and put on a file share,

00:08:17.270 --> 00:08:20.105
you can just change that to copy
it off from that power share.

00:08:20.105 --> 00:08:23.195
The second command is to
install that package.

00:08:23.195 --> 00:08:25.100
The last one is the important one

00:08:25.100 --> 00:08:28.515
here which we're actually
during the on-boarding.

00:08:28.515 --> 00:08:30.480
This tool will actually

00:08:30.480 --> 00:08:33.170
create the ARM resource
and then link back to

00:08:33.170 --> 00:08:37.995
the agent so that at the end
of the on-boarding process,

00:08:37.995 --> 00:08:40.985
you will actually see these resource

00:08:40.985 --> 00:08:44.300
presenting that physical
server in the Azure portal.

00:08:44.300 --> 00:08:45.485
>> Oh, that's awesome.

00:08:45.485 --> 00:08:49.115
So we make it super easy basically
for customers to on-board the

00:08:49.115 --> 00:08:51.050
servers by basically creating

00:08:51.050 --> 00:08:53.315
them the script they
need and obviously,

00:08:53.315 --> 00:08:54.500
I think they can also run

00:08:54.500 --> 00:08:56.630
the scripts against
multiples of servers if they

00:08:56.630 --> 00:08:58.610
on-board like not just
one or two servers

00:08:58.610 --> 00:09:00.035
but maybe hundreds of servers?

00:09:00.035 --> 00:09:01.355
>> Oh yeah. Absolutely.

00:09:01.355 --> 00:09:04.340
>> Okay, that's great. So
now I have my server in

00:09:04.340 --> 00:09:05.870
the portal and I can see that and

00:09:05.870 --> 00:09:07.520
manage it using the
Azure Resource Manager,

00:09:07.520 --> 00:09:10.250
which services can
I actually use now?

00:09:10.250 --> 00:09:12.110
>> Yeah, let me show you that.

00:09:12.110 --> 00:09:15.740
So if you click on one of the
resource, as you can see here,

00:09:15.740 --> 00:09:19.610
we really want to follow the
Azure Virtual Machine model.

00:09:19.610 --> 00:09:25.145
So you can see the list of
capabilities and as we move forward,

00:09:25.145 --> 00:09:28.655
we are going to expand on these
management and capabilities.

00:09:28.655 --> 00:09:33.320
Today we are enabling
two specific services.

00:09:33.320 --> 00:09:35.480
One we can integrate it with

00:09:35.480 --> 00:09:38.420
Log Analytics so that
you can actually get

00:09:38.420 --> 00:09:41.060
the logs added to the resource ID

00:09:41.060 --> 00:09:43.940
and you can query those
logs in one central place.

00:09:43.940 --> 00:09:47.630
So let me show you. If I click
on "Logs" I will be able

00:09:47.630 --> 00:09:52.470
to get all the logs
relevant to this server.

00:09:54.320 --> 00:09:59.910
Without this, if customer trying
to access a log for a server,

00:09:59.910 --> 00:10:01.790
they essentially need to go
to the server and figure

00:10:01.790 --> 00:10:03.980
out which workspace ID connects to,

00:10:03.980 --> 00:10:05.230
and then come to the portal,

00:10:05.230 --> 00:10:07.040
find that workspace, and then

00:10:07.040 --> 00:10:09.110
you can filter based
on the computer name.

00:10:09.110 --> 00:10:10.865
Now with this integration,

00:10:10.865 --> 00:10:13.130
you can simply just click here

00:10:13.130 --> 00:10:15.440
and then get all the logs
belong to the same server.

00:10:15.440 --> 00:10:16.700
>> Oh, that's fantastic.

00:10:16.700 --> 00:10:18.470
So this also helps me like,

00:10:18.470 --> 00:10:19.760
I see a lot of customers having

00:10:19.760 --> 00:10:21.560
a different organization parts

00:10:21.560 --> 00:10:24.590
and some of them are just
really application focused,

00:10:24.590 --> 00:10:28.040
so I can now just give access
to this specific team to

00:10:28.040 --> 00:10:30.410
a specific set of
servers and they can

00:10:30.410 --> 00:10:33.360
just access the locks for the serves?

00:10:33.360 --> 00:10:36.020
>> Yeah, that's actually a great
benefit you that mentioned there

00:10:36.020 --> 00:10:39.200
is in March the monitoring team has

00:10:39.200 --> 00:10:41.420
released this new capability
called the resource

00:10:41.420 --> 00:10:45.620
centric RBAC role
access for the logs,

00:10:45.620 --> 00:10:49.685
and they made it available for
Azure VMs, now with the Hybrid.

00:10:49.685 --> 00:10:52.705
Now you can also get it
for on-prem service.

00:10:52.705 --> 00:10:55.715
>> Oh, that's awesome. So
you also mentioned policies.

00:10:55.715 --> 00:10:59.285
>> Yeah. So Azure policy is

00:10:59.285 --> 00:11:01.700
the place where customers can define

00:11:01.700 --> 00:11:04.780
their compliance and can also
view their compliance status.

00:11:04.780 --> 00:11:06.860
There's this particular category of

00:11:06.860 --> 00:11:09.815
policies called Guest
Configuration policies.

00:11:09.815 --> 00:11:12.770
You can think of Guest
Configuration Policies almost like

00:11:12.770 --> 00:11:17.595
group policies but for
servers not domain joined.

00:11:17.595 --> 00:11:22.800
So there's a long list of the
Guest Configuration Policies.

00:11:22.800 --> 00:11:26.495
We made 18 built-in policies today.

00:11:26.495 --> 00:11:30.335
So you can actually deploy
them right out of the box.

00:11:30.335 --> 00:11:35.149
But also there is, if you have a
requirement that not built-in,

00:11:35.149 --> 00:11:37.295
you can actually create
those custom policies

00:11:37.295 --> 00:11:40.055
and deploy them into
unique environment.

00:11:40.055 --> 00:11:42.440
With the Guest
Configuration policies,

00:11:42.440 --> 00:11:46.025
it actually works through
ARM for the Azure VMs.

00:11:46.025 --> 00:11:48.695
Now with the Hybrid, they can also be

00:11:48.695 --> 00:11:52.275
monitoring and governing
the on-prem servers.

00:11:52.275 --> 00:11:54.090
So as you can see, I deployed

00:11:54.090 --> 00:11:56.315
some of the Guest
Configuration Policies and

00:11:56.315 --> 00:12:00.755
in one view I can see all
these non-compliant status.

00:12:00.755 --> 00:12:04.865
If I drill down I notice
the password policy,

00:12:04.865 --> 00:12:07.610
I have a bunch of
non-compliant services.

00:12:07.610 --> 00:12:09.620
So let me come here, drill down,

00:12:09.620 --> 00:12:13.765
then I can see all the servers
that not in compliant.

00:12:13.765 --> 00:12:17.120
You can see which resource
group they belong to,

00:12:17.120 --> 00:12:19.475
so you can get an idea
what they are doing.

00:12:19.475 --> 00:12:22.145
But also here importantly is that,

00:12:22.145 --> 00:12:26.045
these are Azure Virtual Machines
and these are on-prem servers.

00:12:26.045 --> 00:12:27.440
So in one view, you get

00:12:27.440 --> 00:12:30.470
a full picture of all the servers
that are not in compliance.

00:12:30.470 --> 00:12:32.030
>> Wow, that's fantastic.

00:12:32.030 --> 00:12:34.179
So I see all my servers,

00:12:34.179 --> 00:12:35.730
doesn't matter where they're running;

00:12:35.730 --> 00:12:37.770
if they're running in Azure,
if they're running on-prem,

00:12:37.770 --> 00:12:40.225
in my datacenters, in
my branch offices,

00:12:40.225 --> 00:12:43.160
I can see them up one single view

00:12:43.160 --> 00:12:45.680
and I can manage them from Azure?

00:12:45.680 --> 00:12:48.830
>> Yeah, that's our purposes
of having Azure to be

00:12:48.830 --> 00:12:50.930
the one central place and we want to

00:12:50.930 --> 00:12:53.545
provide the consistent experience.

00:12:53.545 --> 00:12:55.230
>> So that's fantastic.

00:12:55.230 --> 00:12:56.685
So if I'm a customer today,

00:12:56.685 --> 00:12:57.930
how do I get my hands on this?

00:12:57.930 --> 00:13:01.505
>> Yes, so we are really
getting the public preview now.

00:13:01.505 --> 00:13:03.680
So if you follow the
link on the screen,

00:13:03.680 --> 00:13:05.990
you'll be able to see
our documentation and

00:13:05.990 --> 00:13:08.935
the process on how to
enroll with the service.

00:13:08.935 --> 00:13:10.275
>> Okay. That's fantastic,

00:13:10.275 --> 00:13:12.120
and what about the cost for this?

00:13:12.120 --> 00:13:13.805
>> Oh yeah. That's a great point.

00:13:13.805 --> 00:13:16.730
Get a lot of questions on
how much would I pay for

00:13:16.730 --> 00:13:20.135
it and the good news or
great news is, it's free.

00:13:20.135 --> 00:13:22.520
That means that you
don't actually pay

00:13:22.520 --> 00:13:25.070
to on-board your machines onto Azure,

00:13:25.070 --> 00:13:27.410
and you only will pay
for the solutions

00:13:27.410 --> 00:13:29.510
that you're going to
deploy onto those servers.

00:13:29.510 --> 00:13:31.070
>> Well, that's fantastic news.

00:13:31.070 --> 00:13:32.630
So thank you very much Chang'.

00:13:32.630 --> 00:13:34.370
Thank you for being here and showing

00:13:34.370 --> 00:13:36.245
us this Hybrid
management capabilities.

00:13:36.245 --> 00:13:38.130
>> Yeah, thank you