>> Today I'm really excited to talk to you
about Azure Arc enabled servers.
When we think about customers today,
we have customers who are going and beginning
or already far along their IT modernization journeys.
They've started taking their old on-premises applications
and packaging them up in containers or moving to Serverless,
taking those stuff that was on-prem and moving it to
co-loads data centers or other Clouds,
perhaps even multiple Clouds.
As these applications continue to diversify
and the different frameworks in which we're
using to go and deploy and manage them continue to multiply.
Governing and keeping an eye on
all of these resources becomes very difficult.
At Microsoft, we're trying to take
a look at this problem and figure out
what can we do to help bring some control back.
You've got stuff running in multiple Clouds,
some stuff that's going to stay on-prem because of
compliance reasons or just capital expenditure.
You already spent it, let's just keep it there.
How do we go and bring that all
together in one view so that we actually
continue to have a good idea
of all the applications we're running and how they're managed.
Let's talk about how we solve this problem in Azure.
If you've deployed machines
or really any resource in Azure, today,
you're going to have a similar problem
because your company may have a
subscription or multiple subscriptions
and each team's going to go deploy resources.
You still got to figure out how to govern those centrally,
and that's where Azure Resource Manager comes in.
Resource Manager is the central control plane for Azure.
When you go through the portal or
command line and you're asking to go
create or change something about your resources.
Azure Resource Managers the component
responsible for actually accessing that request,
deciding what to do with it and handing it off.
It provides a common set of controls.
If you think about role-based access control to make sure that
only the right people can go and create
new resources and access existing ones.
Tagging an inventory to go keep track
of which departments own which resources,
templates to go and actually do
deployment of multiple things at a single time.
Because a lot of things at the Cloud-scale are going to
happen with multiple machines, and of course,
logs and policy to keep an eye on what did happen and
prevent bad things from happening.
That's a great story for Azure
because when you go and do things like
trying to onboard to Azure Monitor or Azure Security Center.
Azure Resource Manager has a view of all your resources,
so we can make that a one-click experience.
We know of your virtual machines,
we know which ones are not onboarded.
We can provide that information to you right upfront,
and help coordinate the installation of
the agent that's needed to onboard to those services.
What about the stuff that's not running in Azure, though?
The stuff you've got on-prem and in other Clouds.
Those resources today,
are running in your own environments that you control.
You got your own admin tools going and accessing them,
and they're entirely disconnected from the Azure infrastructure.
But we can fix that with Azure Arc.
Azure Arc as a whole,
is trying to connect things that are on-prem or in other Clouds
and project them into
Azure Resource Manager so that Azure is aware of them.
Once Azure is aware of them,
we can actually start providing a lot of
the same management and monitoring and governance
capabilities that you have in Azure
today for the things that are running outside of Azure.
Let's talk a little bit about what those scenarios could be.
First, inventory and just awareness of all those assets.
When you project resources into Azure Arc,
you get visibility into
their operating system and just the fact that they exist,
you can use tags to coordinate which department they belong to.
You know, we support Linux and Windows,
VMs and Bare Metal machines.
It doesn't really matter where the machine is running
as long as it has Internet connectivity.
We can project it up into Azure Arc.
Once it's there, we can do At scale management.
We can do things like deploy agents to your machines on-prem from
Azure At scale using our command line tools or arm templates.
Then lastly, we can start applying Azure Policy to these machines.
Previously, to get visibility into
the compliance status of a machine that's running in Azure,
you used Azure Policy that was not
available for things on-prem because they weren't in Azure.
We didn't have an understanding of what they were.
But with the Azure Arc agent,
we're now able to get visibility and start
auditing the settings of your machines running
on-prem and combine them up into
a dashboard in Azure for you to see in one single place.
Let's talk a little bit more about that scenario.
You're one of these customers on this journey towards multi-Cloud.
You got a ton of IT sprawled,
developers are using all kinds of new tools
and you just want to get an idea, are we compliant?
When the auditor comes by,
how did we prove to them that,
yes, this setting is as it should be?
That's very hard when you've got
a heterogeneous environment of Windows and Linux.
Different Clouds on which each of those machines is running,
probably different admins for managing them.
The idea here with Azure Arc is,
by projecting that machine up into Azure.
Allowing it to start being monitored by Azure Policy.
We can provide the central IT folks,
a single page where they can go see
the compliance status of all the machines,
whether they're in Azure or not.
We also provide benefits to the server admin.
Because now they can go to the portal and check,
with a very easy to use interface,
how they're doing for compliance
before the next audit and they can
start doing some management with
some other Azure tools on that machine as well,
all in a single place.
Unifying and simplifying the management experience
is really the goal here with Azure Arc.
Another good example is onboarding to Azure Monitor.
Azure Monitor is the stepping stone to a lot of
different Azure services like
Security Center and Sentinel for security purposes,
change in inventory, tracking for
keeping an idea of what software is installed in your enterprise.
All you got to do first,
is get your logs up into Azure.
You do that with the Azure Monitor agent.
You can use that with Hybrid machines today.
You just got to go and follow the agent
yourself using your own tools.
We want to make that a whole lot easier.
With Azure Arc and Azure Policy,
you can set up a policy on your subscription that says, "Hey,
every time someone goes and adds a new machine,
whether it's in Azure or not,
please make sure that we installed
the Azure Monitor agent and
make sure it sends its logs to the right spot.
We don't want to go anywhere. We want to go to a very
specific Log Analytics workspace."
When someone goes and installs Azure Arc,
simply an agent installation,
Azure Policy will find that new machine and
go and automatically deploy the agent to it.
We'll take care of downloading the latest version of the agent,
configuring it and reporting
backup to Azure whether that was successful or not.
So super easy, At scale deployment of
that Azure Monitor agent with
zero touch from the admin to that machine,
plus you get the benefit of
Azure Policy where you can then go and quickly
see the status of the deployment across your enterprise.
That's just one example of how taking
an on-prem machine and projecting it up into Azure
makes it a whole lot easier to manage
those machines without actually
changing anything about how that server was previously managed.
Let's go and actually take a look
at how we get started with Azure Arc.
Arc itself is just an agent,
so long as you have access to a machine,
you can go and install the agent on Linux or Windows,
and you just have to connect it up to your Azure subscription.
All we need from you is
just authorization to go and project it up.
Then all the other capabilities we just
discussed start being available for that machine.
Let's walk through a demo of how this happens.
All right, to onboard your machine to Azure Arc.
We'll get started here in the Azure portal,
we'll go to servers Azure Arc.
You can also search for this up at the top.
Here you'll see a list of all your Arc Servers,
but we'll go ahead and add a new one.
When you add a server, you're generating
a script that will run on the machine,
so we'll select the subscription and resource group where
we want to project the Arc enabled server.
We'll pick the region where we want metadata to be
stored and the operating system we're installing on.
It's important to note that region
does not dictate where your machine is physically running,
it's just where your metadata will be stored.
Next up, we'll work on some tags.
I mentioned earlier Azure Resource Manager
supports tagging your Arc machines.
You can choose automatically assign
tags as soon as the machine is onboarded right here.
You'll see that I marked this machine as having me as the owner,
its role as a file server and
its physical locations in our Boston Data Center.
With all that in place, we'll go ahead and review
the new script which is generated.
We can go and download or copy this to our machine.
From there we can start onboarding.
Let's head on over to
Linux machine that we want to project up into Azure.
We've got the script downloaded,
now we just need to run it.
We'll go here and execute that.
Behind the scenes, this is really just downloading and
installing our agent on this machine.
It will then configure it and project it
into the resource group we selected.
As part of that, it has to authenticate.
By default, it's going to ask for me to
login using my phone and a device code.
But when you get to At scale
onboarding and you're going to bring on multiple machines,
you can use the service principle from AAD
for a non-interactive automatable experience.
Now, this machine's online.
Let's go and query the agent
and just double-check that everything's all in order.
Here, we can see in the middle,
agent's status is connected.
That is all we need to see to know that
this machine has Internet connectivity.
It's been able to reach Azure,
and when we go into the portal,
we'll now see projected reference
of this on-premises Linux server.
All right. We just saw how we were able to go
and easily onboard that Linux machine up into Azure Arc.
It's now going to go start evaluating
those Azure Policies and install
the Azure Monitor agent so that we can get
visibility into what's going on on that machine.
But while it does that, let's take a look at
an existing machine I onboarded previously to Azure Arc,
to see what kind of data we're able to see about
it and what we can do to manage it from the Azure portal.
We'll go to ARCDEMO-WIN-01,
and we'll see that this machine looks just like an Azure VM.
We have information about the computer name,
it's operating system.
You'll see I've tagged it, we're ready to identify where it runs,
and it's in the HR department.
This is all great tools to let
you get a quick view into the machine.
But let's drill into policy
because that's one of the unique features you
get when you're running an Azure Arc enabled server.
Here is the server admin view of all the policies in scope for
their machine and their current compliance status.
Compliance status is reevaluated
regularly and updated here in the portal.
This server admin knows that whatever
this policy is, they're non-compliant.
Let's drill in. This policy is checking,
is this machine joined to the corporate domain?
Very important to ensure that
the group policy is actually applied correctly,
including all the security settings and intended configurations.
But this machine's not joined to the right domain.
Either it's work group joined or joined to some other domain.
This machine's out of compliance.
As a server admin, I now know this is something I
need to take care of and go address.
It's really easy for the server admin to
understand what all is going on.
From the central IT perspective,
Azure policies also are very
powerful because they can see the view for all the machines.
We'll see here overall,
under my 108 assets and my subscriptions,
only 23 percent are fully compliant. Let's drill in.
Through the Compliance tab,
we can go and see
all the policies which we have non-compliant assets.
You'll see here, we have all kinds of different types of policy.
Some of them are for Azure machine,
some of them are for both Azure and Hybrid machines.
Let's go take a look at, for example,
the time zone policy here.
We asked all of our Windows machines to be
set to the Eastern time zone.
You'll see here that out of our 25 resources that are Windows VMs,
13 of them are not compliant,
and I can go here on this page and find a full list of them.
You'll see it's a mix of both Azure Virtual Machines
and Hybrid Virtual Machines,
so we know, "Hey,
we got to go through here and address these problems."
Azure Policies are very flexible.
We got to a ton built-in policies for you to start with,
but you can also write your own custom policies to match
whatever your internal or regulatory requirements may be.
This is just the beginning.
We definitely hope you get a chance to go and
deploy Azure Policy and really get
a great view into how you're doing compliance
wise for all of your assets, no matter where they're running.
Back over to the Arc Server.
I just want to show a few more things.
First here on the Insights tab,
when you upload your logs to Azure,
you can also opt into Insights for Azure Arc.
Insights shows you things that might be useful to
an app developer like: What are
the network connections my machine is making?
You can track down here the ports it's reaching and
the actual individual servers it's been talking to.
Then the Performance tab of course,
you can also see how the resource utilization has been.
If there's been any spikes, you can drill down into
this data and figure out maybe that's why the app had crashed.
But really powerful feature of Azure Monitor is you can
actually go and take that broad view again and say,
"Across all my machines in this resource group, how am I doing?"
You'll see here that we had a spike on ARCDEMO-WIN-01,
but the other machines weren't spiking quite as much.
That's one of those things you might want to look into.
That's really showing again,
once you onboard a machine to Arc,
there's a lot of grouped tooling and
capabilities for the server admin,
but the data is flowing elsewhere in Azure to go and
provide those broad At scale management experiences as well.
Let's head back and check
one more thing and that is Update Management.
Update Management has been available for
Hybrid machines for quite some time now.
But with Azure Arc, we can pull the view right
here for the server admin to take a look at.
You see we're missing quite a few updates.
Right from this page, we can go and
schedule those updates to be deployed.
I can give an update deployment name,
so I'll say "Night updates" and we can go pick a schedule.
We'll do this on Sunday so we don't disrupt anyone today.
I'll go pick that on the calendar.
You can choose exactly which updates you want to install and
configure any scripts that need to run before
or after to keep your app running.
Then we'll go ahead and schedule that.
Now, on Sunday this machine will go
ahead and get the updates it's missing,
and we'll be able to see it right here on
the History tab once the update run has gone through.
Really nice and powerful way to go and see how
our AI machines are doing without actually
having to sign into the individual machine.
Lastly, let's take a look at the Extensions.
Extensions, I mentioned earlier,
are a great way to get the monitoring agent
deployed down to a machine.
You'll see here we've got a couple of
different extensions already pushed down.
First two are by policy,
third one was done custom.
Let's take a look at what that experience is like.
If I want to go push a script down onto this machine,
we can do Custom Script Extension.
Go ahead and create, we'll browse to
a file that goes and configures
a website in iOS. It's all it has to do.
Then we'll go ahead and
ask Azure to go and download that script to the machine,
and it will go and configure it.
Nice and easy way to go push down single scripts.
There's also a DSC Configuration option,
as well as the monitoring agent deployment,
which you can coordinate all of these At
scale through the Azure Command Line,
Arm Templates or Azure Policy.
You just saw a great demo of how easy it
is to go get started with Azure Arc
enabled servers and use some of
the features that it enables in the Azure portal.
Again, all of this stuff is also available through
our command line and rest APIs.
So when you start thinking about
your At scale deployment, we're there for you.
We'll make it really easy to do whatever you need to
onboard your machines to Azure Arc.
If you're ready to get started,
we've got a great documentation available on
our site at aka.ms/arc/server.
If you also want to try one of our Jumpstart scenarios,
we have a GitHub repo full of ready to use
Azure Arc scenarios that fit very common customer use cases.
For example, if you've got a couple of machines
running on another Cloud and you want to figure out
how do I onboard those At scale using that
Cloud's tooling to Azure Arc.
The Jumpstart repo has a solution for that already,
and you can play around with that and get an idea of
how to instrument that for your own environment.
Definitely a great place to look for
some examples of how to get started with Azure Arc.
Lastly, we post regularly to the Azure Arc blogs,
so definitely keep an eye there.
We've got plenty good content plan
for the rest of the year to help
you get started and get using
all of the various Azure Arc features.
Thanks again for listening.
This is Ryan Puffer from
the Azure Management team. Hope you enjoyed it.